如同我一開始就說到，金融機構最在意就是上線的所有檢核，上線會有一些事項檢核這是一定的，但是這不代表那些該檢核的事項是在檢核的時候才應該被注意到。舉例來說，近期有個爭議就是新系統上線前要進行黑箱掃瞄，但是黑箱掃瞄這件事情需要手動申請。
因此校長兼撞鐘還澆花的開發人員，整天除了跟使用者來回溝通的專案管理事項，要抽出時間去分析使用者心目中系統希望實現的願望，且找到做法後還要實現，又有奇奇怪怪的日常庶務要進行外，居然還要另外看那份資安自己寫完，且沒有告知與協調的標準作業程序，預先在上線前開發人員要自動自發的去手動開一張工作單請，資安進行掃瞄。而且最痛苦的是，資安只會告訴贈送你一張pdf要修，卻不會告訴你要怎麼修(還把ChatGPT封鎖掉，沒人可問）。修完還不知道對不對，又要手動再開一張單。
這種事情，就是我說到的，這件事情的確很重要必須被檢核，但不該是這麼粗暴的劃一條停止點在上線前，而是要融入SDLC，讓開發人員能夠視資訊安全為他開發中的一環，列為他的日常開發必須被注意的事項。
筆者在近期也有上過資訊安全的課程，也有幸考過了張證照，在上課的過程中講師說的一句話我非常的同意並印在心中：資訊安全掃瞄這件事情很簡單，工具買來掃下去就好，但解讀那份報告以及評估哪些是真正關鍵風險才是最困難的。 那如何把那些關鍵風險，交給決策主管決定必須投入資源進行修補，這是需要有資訊安全合格評估者與開發人員不斷進行協作，才是最理想的。
這就是Shift Security Left ：應用程式開發，在最早的設計開發階段就必須要被設計進去的資訊安全各項作為。
那這次任務其實基本上僅圍繞在SDLC，並未為了Shift Security Left另外多做太多的安全性工具的自動串接，未來將會以Advanced security作為應用程式開發安全生命週期而進行設計，所以有跟先導團隊說明，這次就僅能請大家在規範的資訊安全項目，還是進行手動的申請。
從Day 2 開始進行專案管理以及分析、程式分析與撰寫、自動化管道的編譯、各項測試的進行以及一些應該注意的參數機密化的自動化管線設計，到了今天Day 28終於要開始討論要上線的事宜了。
上面的圖雖然是抄Agile Diagram，但是我認為也很適用在我們現在要討論的階段。實際上，我們前面的天數，就是不斷在步驟1~5之間循環，那循環多久要到6可以正式交付上線，這就很看各公司文化了。
筆者今年去過ithome 的DevOpsDay，非常羨慕那些一天可以做到數次甚至數十次上線的這些公司，這表示他們在整個devops flow不斷的演進到我手已經無法觸及的地方了。但沒關係，我們還是可以藉由現況任務的完成，來成就大家心中的那份小小成就感。
上圖可以清楚的看到，現在有兩個審核者的身分：
另外有一個要注意到的，就是兩位審核者手上都有一份同樣的V.1.0.0 的文件。我們其實內部在討論營運環境過版程序時，陷入了一個長考。上圖雖然可以看的出來，CI我們定義成程式碼品質確認，也就是可以從Pull Request的時候，將程式碼進行code review後，進行投票與核可，進而併入main分支，這裡在Pull Request其實很直觀。
而CD的部分，也就是落到了Operator的身上，這件事情讓我們進退維谷。其實這是因為在過往的上線程序中，我們要檢附的文件大致上如下：
那以前的做法是在最後上線前，一股腦把這堆東西上傳到工單系統上，然後由Operator進行每份文件的確認，然後才會協助開發人員把相關列在清冊上的程式，跑到版控系統下載下來後，手動放置到指定的伺服器中的指定目錄。
我原本在第一次內部流程設計的時候，我使用了release pipeline，讓operator來使用。大概設計的示意圖如下：
那如果一個release pipeline被觸發，然後指定的人要按下approve的時候，大概的圖如下：
另外還會收到一封信：
那時候我印象很深刻，我請operator要按下approve的時候，他回答我：一個按鈕是很方便，但我要看的那些文件在哪？稽核未來來查核那些上線項目以及相關紀錄，又該在哪裡看？
而我在另外的展示時，同時也邀請了稽核一同與會，他也問了我一模一樣的問題，我就知道這件事情可能真的有問題了。
我勢必要找一個方式，讓審核人員與查核人員可以知道那些曾經上線的紀錄，以及相關的文件在哪裡。
最後，我提出了release note的概念。
SDLC 一個循環最終目的是上線，上線前的審核，須根據不同公司文化滿足各角色的需求。
iThome鐵人賽
看影片追技術