先說結論：那張檢核表，其實不是重點
好，我們今天來聊聊 SSDLC，那個... 就是安全軟體開發生命週期。很多人一聽到這個，第一個反應就是，「喔，所以有沒有檢核表 (checklist) 可以下載？」、「那個表要怎麼填？」。嗯... 我得先說，如果你心裡想的只是找一份現成的表格，然後印出來，在每次會議上逼著開發團隊一項一項打勾... 那我幾乎可以跟你保證，這件事最後一定會失敗，而且大家還會做得很痛苦。
說真的，那張表本身不是重點。它只是一個工具，一個輔助我們建立「安全開發習慣」的工具。真正的目標，是讓整個團隊，從 PM、開發者、到測試人員，心裡都有一條安全的弦，在做每一個決定的時候，都能下意識地去想：「欸，這樣做安不安全？會不會有什麼洞？」。檢核表只是用來提醒我們，在流程的不同階段，有哪些事情「通常」不能忘記。它是一個起點，不是終點。所以，與其問「檢核表怎麼做」，不如問「我們團隊的安全開發文化要怎麼建立？」... 這才是我覺得真正核心的問題。
別再救火了，談談為什麼我們需要這東西
我想先講個故事，這大概是很多團隊的共同回憶。還記得有一次嗎？禮拜五晚上，大家準備要下班了，突然客服接到電話，說有個客戶發現我們網站上某個輸入框，隨便打幾個符號，頁面就整個爛掉了。資深的工程師一看，啊，一個超基本的 XSS (跨站腳本攻擊) 漏洞。然後呢？整個週末就泡湯了。大家緊急集合，查 code、修 bug、上 hotfix... 整個過程雞飛狗跳，還得跟老闆、跟客戶道歉。
這就是典型的「救火」。問題都已經在線上發生了，我們才手忙腳亂地去補救。SSDLC 想做的，就是把這個「發現問題」的時間點，從「上線後」，一路往左推，推到最早最早的「需求」跟「設計」階段。這就是大家常說的「安全左移 (Shift Left)」。 因為你想想看，如果當初在設計那個輸入框功能的時候，PM 或設計師就想到：「這個框會讓使用者輸入資料，我們要怎麼防止惡意腳本？」並且把它列為一個需求，那工程師在開發時就會直接處理掉。這比起事後花整個週末來修補，成本是不是低太多了？不只是金錢成本，還有團隊的士氣、客戶的信任... 這些都是無形成本。
所以，導入 SSDLC 不是為了應付稽核，也不是為了讓文件看起來很漂亮。它的核心價值，是把資安從一個「事後補救」的麻煩事，變成一個「事前預防」的內建習慣，讓團隊可以更安穩、更有品質地交付產品。
怎麼做？從理想、現實到我的建議
好，理論講完了，那具體來說到底要幹嘛？傳統的軟體開發生命週期大概分成幾個階段嘛，需求、設計、開發、測試、部署維運... 我們就在這些階段裡，安插一些安全相關的活動。但我不想講得太八股，我們來看看理想、現實，還有我的務實建議。
| 開發階段 | 理想中該做的事 (The Ideal) | 但現實是... (But the reality is...) | 我的建議：從這裡開始 (Start Here) |
|---|---|---|---|
| 1. 需求分析 (Requirement) | 大家坐下來，除了討論功能，也把安全需求、合規需求（像 GDPR、個資法）一條條列清楚，寫進規格書裡。 | 「先求有再求好啦！功能都來不及了還管什麼安全！」、「使用者才不在乎這個。」 PM 常常這樣說，然後這階段就直接被跳過了。 | 不用一開始就想做到完美。先從最基本的開始：針對「所有使用者會輸入資料」的地方，明確定義一條安全需求：「所有使用者輸入都必須經過驗證與淨化，防止 XSS 與 SQL Injection。」就這一條，先做到位。 |
| 2. 系統設計 (Design) | 召集資深工程師和架構師，針對系統架構做「威脅建模 (Threat Modeling)」。畫出資料流，分析每個環節可能被怎麼攻擊，然後設計對應的防禦措施。 | 「威脅建模？聽起來好複雜，我們沒那個美國時間。」、「架構？複製貼上以前的專案就好了啊。」結果就是把以前的洞也一起複製過來了。 | 一樣，先簡化。在設計會議的最後，固定留 15 分鐘，大家一起看著架構圖，只問三個問題：「1. 我們的『金鑰/密碼』放哪？安全嗎？」、「2. 我們的『使用者個資』在哪裡流動？有沒有加密？」、「3. 我們的『後台權限』是怎麼分的？會不會有低權限帳號做到高權限的事？」光這三點，就能擋掉一堆低級錯誤。 |
| 3. 開發實作 (Development) | 所有工程師都上過安全編碼的課，寫出來的 code 天生免疫各種漏洞。CI/CD 流程整合了 SAST (靜態應用程式安全測試) 工具，一提交程式碼就自動掃描。 | 「那個 SAST 工具報了一堆東西，根本看不懂啦，先 ignore 掉再說。」、「什麼是安全的寫法？能動不就好了？」結果工具買了，警報響了，但沒人理。 | 先專注在 OWASP Top 10 的前三名，例如：注入攻擊 (Injection)、失效的存取控制 (Broken Access Control)。要求團隊在 Code Review 時，把這幾項當成必看重點。然後，與其花大錢買很貴的 SAST 工具，不如先用一些開源或 IDE 內建的 linter，至少先把最明顯的洞補起來。SAST 工具的規則也要客製化，關掉那些惱人的、不重要的，只留下真正關鍵的項目。 |
| 4. 測試驗證 (Testing) | 除了功能測試，QA 團隊還會執行 DAST (動態應用程式安全測試)、滲透測試，用駭客的思維來攻擊系統，找出潛在漏洞。 | 「我只負責測功能，那個按鈕按下去會不會動。」、「滲透測試？那是資安公司的事吧？」QA 通常沒有資安測試的訓練或資源。 | 不要想一步到位。可以先提供 QA 團隊一些簡單的「安全測試劇本」。例如，給他們一個特殊字元列表（像是 `' OR 1=1; --`），讓他們在每個輸入框都貼貼看，看系統會不會爆掉。這雖然很基本，但已經能抓出很多問題。然後，一年至少做一次由外部專家執行的滲透測試，當作是系統的健康檢查。 |
| 5. 部署與維運 (Deployment & Operation) | 所有上線的系統都經過嚴格的版本控管，伺服器環境也都做了強化 (Hardening)。有完整的監控與告警機制，一有異常馬上就知道。 | 「SOP？先上線再說啦，回來再補文件。」、「那個套件有漏洞？可是更新了怕其他東西會壞掉，先不要動好了。」通常是上線後就沒人管了，直到出事。 | 自動化！這階段就是要靠自動化。導入像 Dependabot 或 Snyk 這樣的工具，自動檢查你的開源套件有沒有已知漏洞 (這就是所謂的 SCA, Software Composition Analysis)。 至少，要做到能「知道」自己用了有風險的套件。然後，建立一個簡單的通報流程，讓大家知道發現問題要通知誰，而不是裝沒看到。 |
你看，沒有一個階段是要求你「把檢核表填滿」。全都是在既有的工作流程中，加入一個小小的、跟安全有關的「動作」或「思考點」。這才是能持續下去的方法。
情境變體：新創公司跟金融業的玩法當然不一樣
上面那張表是一個通用性的建議，但現實中，不同團隊的資源和壓力完全不同。你不能拿對金融業的要求，去套在一間只有五個人的新創公司上。
給資源有限的小團隊或新創公司
你們的重點是「快」，所以任何會拖慢速度的流程都會被抗拒。我的建議是，不要追求完整的文件和流程。專注在「高槓桿」的活動上。例如，把錢花在刀口上，與其買昂貴的掃描工具，不如投資在開發團隊的教育訓練上，讓大家從源頭就寫出比較安全的 code。 然後，把威脅建模那套複雜的流程，簡化成每次 Sprint Planning 時的 10 分鐘安全快問快答。重點是培養意識，而不是產出文件。
給有一定規模的中大型企業
你們通常已經有比較固定的開發流程，甚至可能有專門的 QA 團隊。這時候，重點就是「整合」和「自動化」。把 SAST/DAST 工具整合進 CI/CD pipeline 是必須的。 目標是讓安全檢查變成像單元測試一樣自然的存在，開發者在自己的電腦上就能收到回饋，而不是等到要上線了才被資安團隊擋下來。這時候，檢核表就扮演了「標準化」的角色，確保每個專案、每個團隊，都有一個最基本的安全基準。
給需要高度合規的產業（金融、政府、醫療）
對你們來說，事情就不只是「安不安全」，還有「合不合規」。這時候，你的 SSDLC 流程就必須跟法規緊密結合。像台灣的金融業或政府單位，常常會參考「資通系統防護基準」。 這份文件其實就非常具體地列出了各個階段的控制措施要求。這跟國際上比較常見的 OWASP SAMM 模型有點不同。OWASP SAMM 比較像是一個成熟度模型，它讓你評估自己在各個安全實踐上的等級，然後決定要往哪個方向改善，彈性比較大。 但像「資通系統防護基準」這類法規，它的要求就比較硬，比較像是一條必須跨過的及格線。
所以對這類組織來說，SSDLC 檢核表的內容，很大一部分會直接來自這些法規條文。執行的重點會變成「留下證據」，確保每個步驟都有文件、有簽核、有紀錄，以備將來的稽核。這時候，工具的角色就更重要了，你需要能夠產出合規報告的工具，來證明你確實有做到這些要求。
為什麼導入通常會失敗？幾個常見的坑
我看了太多團隊導入 SSDLC，一開始轟轟烈烈，三個月後無聲無息。為什麼？大概都踩了這幾個坑。
第一個，就是我一開始說的，「為了打勾而打勾」。 大家把檢核表當成一份考卷，心裡想的只是怎麼把它填完交差，而不是真正去理解每個項目的用意。結果就是，表格看起來很完美，但系統還是一堆洞。這就是所謂的「安全劇場 (Security Theater)」。
第二個，「資安是資安團隊的事」。開發團隊覺得：「你不要來煩我，我負責寫 code，你負責找漏洞。」 這種壁壘分明的文化，是 DevSecOps 的天敵。安全應該是每個人的責任，如果開發者沒有從心裡認同這件事，那所有流程都只是強加的負擔。
第三個，「沒有高層支持」。導入 SSDLC 初期一定會有效率陣痛期，開發速度可能會變慢。如果沒有管理層，特別是 C-level 的理解和支持，只要專案時程一緊張，第一個被犧牲的絕對是安全流程。「這次先這樣，下次再說」，然後就沒有下次了。
最後一個是，「想一步到位」。有些團隊太有雄心壯志，一開始就想導入最完整、最複雜的流程，買了最貴的工具，結果團隊根本消化不了，光是學工具、搞設定就花了三個月，大家馬上就累了、放棄了。這跟減肥一樣，一開始就設定每天跑十公里，大概第二天就放棄了。
常見錯誤與修正
好，最後我們來整理一下，如果你們團隊已經在跑 SSDLC，但感覺卡卡的，可以看看是不是犯了這些錯。
錯誤一：把 SAST 工具當成神主牌，報出來的每個問題都要修。
修正：拜託不要。SAST 工具的誤報率 (False Positive) 本來就不低。正確的做法是，由資深人員或資安窗口（如果有的話）先過濾一次掃描結果，建立一個「基準線 (Baseline)」。把那些明顯是誤報、或風險極低的項目標示為忽略。團隊只需要專注在「新增的」、「高風險的」問題上。不然光是處理誤報，工程師就崩潰了。
錯誤二：威脅建模會議開得像博士論文口試，又長又沒結論。
修正：保持簡單。威脅建模的價值在於「引發討論」，而不是產出完美的文件。試試看用 STRIDE/DREAD 這類模型當作腦力激盪的框架，但不要被它綁死。會議時間控制在一個小時內，目標是找出 2-3 個「最可能發生、且衝擊最大」的威脅，然後把它們變成 user story 加到 backlog 裡，跟其他功能需求一起排程開發。有做，比做得完美更重要。
錯誤三：安全訓練就是每年看一次影片，然後線上測驗。
修正：這種訓練基本上沒用。有效的訓練，應該是互動的、跟實際工作相關的。可以試試看舉辦內部的「抓漏競賽 (Capture the Flag, CTF)」，讓工程師實際去攻擊一個有漏洞的測試系統。或是，在 Code Review 的時候，當發現一個安全問題，不是只有叫對方修掉，而是花五分鐘跟他解釋這個漏洞的原理和後果。把每一次犯錯，都當成一次學習的機會。
總結來說，SSDLC 檢核表只是一個地圖，告訴你路上大概有哪些景點。但要怎麼走、開什麼車、在哪裡休息，都需要你的團隊自己決定。從小的、有感的改變開始，慢慢把安全的 DNA 植入到開發的每一個環節裡。這趟路沒有捷徑，但絕對值得。
那麼，回到你的團隊，你覺得導入 SSDLC 最大的挑戰會是什麼？是開發者的抗拒、主管的不支持，還是根本不知道從何開始？在下面留言分享你的看法吧！
