SSDLC查檢表怎麼做？安全開發生命週期檢核項目與導入步驟

嗯...今天要來聊的，是 SSDLC。就是那個...安全軟體開發生命週期。很多人，真的，很多人一聽到這個就覺得頭很痛，覺得很複雜、很多文件。好像只有大公司或政府機關才需要搞這個。

但...老實說，我自己是覺得，這個觀念可以很複雜，也可以很簡單。今天，我不想講那些很空泛的理論...我想試著用一個比較...嗯，比較務實的角度，聊聊如果你是一個小團隊，或你們公司以前從來沒做過，那到底該怎麼「開始」。對，重點是「開始」，不是「完美」。

所以，結論是什麼？

一句話講完：就是先求有，再求好。你不用一開始就想弄一個完美的、包山包海的 SSDLC 查檢表。那樣...嗯...通常都會失敗。你應該先從每個開發階段，挑一、兩個最重要、最有感的事情開始做。這樣阻力最小，也最容易看到效果。

為什麼不直接用現成的範本就好？

這是一個很好的問題。網路上有很多查檢表，像法務部或是一些資安單位都有公開文件。那些都很有參考價值，真的。但問題是，每個團隊的狀況都不一樣。

我之前看過一個案子，他們就是...嗯，直接拿了一份很完整的官方查檢表來用。結果，開發團隊為了「填完」那份表單，花了很多時間，但很多項目他們根本不理解為什麼要做，就只是打勾。比如說，有一項是「威脅模型分析」，結果大家根本不知道那是什麼，就上網隨便找個圖貼上去交差。這...這就完全失去意義了，對吧？

所以，我覺得關鍵不是你用了多完整的範本，而是你的團隊是不是真的理解每個檢查項目的「為什麼」，然後把它變成一種...嗯，一種習慣。而不是一種負擔。

好，那...我們到底該怎麼開始？

OK，我們就來實際拆解一下。一個軟體開發，大概可以分成幾個階段：需求、設計、開發、測試、部署維護。我們就從這幾個階段， masing-masing（印尼語的「各自」）...嗯，各自挑一兩件事來做。

階段一：需求與規劃

這個階段，你不用搞得太複雜。就問一個問題：「我們這次做的功能，有沒有碰到錢？或是有沒有碰到很敏感的個資？」

如果答案是「有」，那恭喜你，這就是安全需求的起點。你可以在需求文件上，就簡單加一條：「此功能涉及金流支付，需特別注意支付過程的安全性。」或是「此功能會處理使用者身分證字號，需確保資料儲存與傳輸加密。」就這樣，很簡單。這就是把安全需求納進來的第一步。

階段二：設計

設計階段，我覺得最重要的，就是「威脅模型分析」（Threat Modeling）。哇，聽起來又是一個很專業的名詞。但其實，你可以把它想成是「大家一起來當壞人」的遊戲。

你就找開發人員、PM...可能的話，找個懂一點資安的人，大家對著架構圖。然後開始想：「如果我是駭客，我會從哪裡打？我會想偷什麼？我可以用什麼方法？」比如，冒充使用者 (Spoofing)、竄改資料 (Tampering) 等等。這些想法，隨便記下來就好，用白板、用便利貼都可以。

這一步的重點不是找出所有威脅，而是培養團隊的「安全意識」。讓大家在設計系統的時候，腦中會多一根筋，去想「這邊會不會有問題？」

階段三：開發（寫扣）

開發階段，要做的事情就比較具體。我建議從兩件事開始：

導入一個原始碼掃描工具（SAST）：現在很多工具，甚至 GitHub 本身都有內建一些免費的。你就把它加到你的 CI/CD 流程裡。一開始可能會掃出一大堆問題，開發者會很反彈。所以...嗯...你可以先設定，只看「高風險」的漏洞就好。先求有，再慢慢調整。
管理好你的「套件」：現在開發很少從零開始，都會用很多第三方套件。你要確保這些套件是安全的，沒有已知的漏洞。這件事也有專門的工具（SCA, Software Composition Analysis）可以幫忙。一樣，先從最嚴重的漏洞開始修。

把帳號密碼寫在程式碼裡...這種事情就真的不行，這在很多規範裡都有提到。這應該是最最基本的底線。

階段四：測試

測試階段，除了原本的功能測試，你可以多加一個「動態應用程式安全測試」（DAST）。簡單說，就是一個模擬駭客去戳你網站的工具。它會在你網站還沒上線前，自動去跑一些常見的攻擊手法。

這個跟 SAST 不太一樣，SAST 是看程式碼，DAST 是實際去攻擊你跑起來的系統。兩個是互補的。一樣，一開始先關注高風險問題就好。

階段五：部署與維護

到了這個階段...嗯...我覺得最重要的一件事，就是「監控與日誌」（Monitoring and Logging）。你要確保系統上線後，所有的操作、所有的錯誤，都有被好好地記錄下來。這樣萬一真的出事了，你才有線索可以追查，知道發生了什麼事。

這麼多框架，NIST、OWASP SAMM... 我該選哪個？

對，這也是一個大問題。很多人會被這些名詞搞混：Microsoft SDL、OWASP SAMM、NIST SSDF... 到底差在哪？

我覺得，對於剛起步的團隊，你可以這樣理解。我做個簡單的比較表好了，但我用口語化的方式說。

不同安全開發框架的入門比較
框架	我的理解...嗯...口語版	適合誰
Microsoft SDL	算是始祖級的吧。很完整，但也有點...嗯...重。它把所有你想得到的事情都定義好了，有點像一本厚厚的教科書。	資源多、有專門資安團隊的大公司。想直接抄一套完整作業的可以參考。
OWASP SAMM	這個比較像自助餐。它把安全分成幾個面向，每個面向有不同成熟度等級。你可以自己決定要從哪個面向、哪個等級開始做。彈性很大。	我覺得最適合大部分團隊，尤其是中小型團隊。你可以從 Level 1 開始，一步一步來，比較不會消化不良。
NIST SSDF	這是美國政府的標準。所以如果你要跟美國政府做生意，這個基本上是必考題。它很權威、很全面，但條文也比較...嗯...正式。比較像法規。	需要跟美國聯邦機構合作的供應商，或是那些身處嚴格監管行業（像金融、國防）的公司。

所以，我的建議是，你可以先看看 OWASP SAMM 的架構，因為它最有彈性。至於 NIST SSDF，你可以把它當成一個...嗯...最終的目標或是一個參考。我知道在台灣，政府有些案子也會參考這類標準，但直接整套搬進來，對小團隊來說真的太辛苦了。一個有趣的觀點是，有些人認為 NIST SSDF 算是 OWASP SAMM 的一個子集，所以把 SAMM 做好，很大程度上也能符合 SSDF 的精神。

導入時，最容易踩到哪些坑？

我覺得有幾個常見的錯誤，或者說是...嗯...迷思吧。

迷思一：買了工具就等於安全了。 工具很重要，但它只是輔助。如果團隊沒有那個心態，工具掃出來的報告也只是堆在那邊積灰塵。
迷思二：這是資安團隊的事，跟開發無關。 這大概是最致命的想法。安全必須是開發流程的一部分，要「左移」（Shift Left），也就是越早開始越好。不能等到東西都做完了，才丟給資安人員去測，那樣修改的成本會非常非常高。
迷思三：追求一次到位。 就跟我一開始講的一樣。不要想著一次就把所有事情都做好。那樣只會讓大家覺得很煩，然後陽奉陰違。從小處著手，建立信心，再慢慢擴大範圍，這才是...嗯...比較人性的做法。