前言：別再讓「安全」成為上線前的絆腳石
嗯…大家好，今天…今天想來聊一個可能有點硬，但老實說，對每個開發團隊都超級重要的主題：SSDLC。對，就是 Secure Software Development Lifecycle，安全軟體開發生命週期。很多人聽到這個詞，特別是工程師，可能頭就開始痛了，覺得「唉，又要多一堆流程」、「又要填一堆表單」、「又要被資安卡關」，對吧？
我自己是覺得，會有這種想法很正常。因為太多時候，「安全」這件事，都是在產品快要上線的時候，才突然冒出來，像個程咬金一樣，把你擋下來。然後，資安團隊丟給你一堆弱點報告，說這裡有洞、那裡有風險，但開發時程早就訂好了，這時候要改，真的是…你知道的，會搞得大家人仰馬翻。
但反過來說，如果我們能把「安全」這件事，從一開始…對，就是從「需求分析」那個最早的階段，就把它考慮進來，讓它變成開發流程的一部分，而不是最後的「檢查哨」，那整個狀況就會完全不一樣。這就是 SSDLC 的核心精神：安全左移（Shift Left Security）。 白話講，就是越早發現問題，修復的成本就越低，不管是時間還是金錢成本。所以今天，我們不談那些很空泛的理論，我想來聊聊，一個務實的 SSDLC 檢核表到底該怎麼做？又該怎麼一步一步導入到你的團隊裡？
為什麼我們需要一個「檢核表」？先說結論
我知道，大家都很忙，所以先說結論。為什麼一個「檢核表」很重要？因為它能把 SSDLC 這種有點抽象的框架，變成具體、可執行、可追蹤的動作。它就像一份待辦清單，讓團隊裡的每個人，不管是 PM、開發者、還是測試人員，都知道在自己負責的階段，該注意哪些跟安全有關的事。 這份檢核表，不是要增加大家的工作量，正好相反，它是要幫助我們避免在專案後期，因為一堆突如其來的安全問題而加班、延遲上線。 簡單講，它是一個「避坑指南」。
一個實際的痛點：沒有 SSDLC 的開發日常
在我們深入檢核表細節之前，我想先分享一個…嗯…可以說是很多團隊都遇過的場景。想像一下，你們團隊用敏捷開發，衝了三個月，好不容易把一個新功能開發完了。大家都很興奮，準備要上線了。結果，按照公司規定，上線前要先過資安檢測。一週後，資安部門或外部廠商，給了你一份幾十頁的滲透測試報告，上面列了十幾個高風險漏洞，像是 SQL Injection、XSS、還有一些套件的已知漏洞（CVE）。
這時候會發生什麼事？PM 的臉色大概會變得很難看，因為上線時程勢必得延後。開發者會覺得很煩，因為要去修一些可能在架構設計初期就能避免的問題。更慘的是，有些問題可能要動到核心程式碼，改起來牽一髮動全身，風險超高。這就是典型的「安全後補」造成的災難。如果一開始在需求階段就定義好輸入驗證的規則、在設計階段就做了威脅模型分析、在開發階段就用了 SAST 工具掃描，很多問題根本不會活到最後的滲-…滲透測試階段。
怎麼做？打造一份可行的 SSDLC 檢核表
好，那說了這麼多，到底這份檢核表該長什麼樣子？老實說，沒有一份「萬用」的檢核表可以適用所有公司。 一個三人小 startup 跟一個幾百人開發團隊的金融機構，需要的檢核表肯定不一樣。但我們可以依據 SSDLC 的標準階段，來建立一個基礎的範本。 然後你可以根據自己團隊的規模、產品的特性、還有你們用的技術，去做客製化。
底下我會把開發生命週期分成六個主要階段，然後列出每個階段你至少該問自己的問題。
階段一：需求與規劃 (Requirement & Planning)
- [ ] 我們的專案或功能，會處理到敏感性資料嗎？（例如：個資、金融資訊、醫療記錄）如果有，那資料保護的等級就要拉高。這點跟 GDPR 或台灣的個資法都有關係。
- [ ] 有沒有定義清楚的安全需求？這不是一句「系統要安全」就帶過。而是要具體，例如：「所有使用者密碼儲存前必須經過 bcrypt 雜湊」、「後台管理功能必須強制啟用 MFA」。
- [ ] 法規遵循需求是什麼？如果你的產品跟支付有關，可能就要符合 PCI DSS 標準。如果是醫療相關，可能要看 HIPAA。這些法規裡面，其實就藏了很多安全需求。
- [ ] 我們有為這些安全需求，預留開發資源跟時間嗎？這點超重要，但最常被忽略。安全功能也是功能，需要時間開發和測試。
階段二：設計 (Design)
- [ ] 我們做「威脅模型分析 (Threat Modeling)」了嗎？這是設計階段最重要的安全活動。 簡單說，就是站在攻擊者的角度，去思考系統可能被怎麼攻擊，然後預先設計防禦措施。 你可以用像是 STRIDE 這種模型來幫助思考，例如：有沒有可能被假冒身份 (Spoofing)？資料有沒有可能被竄改 (Tampering)？
- [ ] 系統架構有考慮到安全設計原則嗎？像是「最小權限原則」，每個元件或使用者，只給他執行任務所必需的最小權限。還有「縱深防禦」，不是只靠一道防火牆，而是層層設防。
- [ ] 第三方服務或 API 的串接，有評估過它的安全性嗎？你用的這個 API 会不会有漏洞？傳輸過程有沒有加密？
- [S ] 安全設計有沒有被寫成文件？這能確保所有開發者都在同一個基準上做事。
階段三：開發與實作 (Implementation)
- [ ] 團隊有沒有遵循一套安全的編碼規範 (Secure Coding Standard)？例如 OWASP Secure Coding Practices。 這可以避免很多常見的程式碼層級漏洞。
- [ ] 我們有沒有使用 SAST (靜態應用程式安全測試) 工具？這些工具可以在程式碼還沒編譯執行前，就掃描出潛在的漏洞，就像拼字檢查一樣。 把它整合到 CI/CD 流程裡，每次 commit 就自動掃，效果最好。
- [ ] 專案使用的第三方套件 (Open Source Libraries) 有沒有做漏洞掃描？現在的應用程式，大概有八、九成都是由開源套件組成的。 你需要用 SCA (軟體組成分析) 工具去檢查這些套件有沒有已知的 CVE 漏洞。
- [ ] 所有機敏資訊，像是密碼、API 金鑰，有沒有從程式碼裡移除？這些東西應該要用安全的金鑰管理系統（例如 HashiCorp Vault 或雲端服務商提供的 secrets manager）來管理。
階段四：測試 (Testing)
- [ ] 我們有沒有執行 DAST (動態應用程式安全測試)？跟 SAST 不一樣，DAST 是在應用程式跑起來之後，去模擬駭客的攻擊手法，找出執行期的漏洞。
- [ ] 除了自動化工具，有沒有規劃手動的滲透測試？特別是針對高風險的核心功能。自動化工具很難發現業務邏輯上的漏洞，這需要靠人的經驗。
- [ ] 測試案例有沒有包含「濫用案例 (Abuse Cases)」？不只是測「正常」功能，也要測「不正常」的使用情境。例如，如果一個 API 呼叫一次要 1 秒，那如果一秒內呼叫它 100 次會發生什麼事？
- [ ] 找到的漏洞，有沒有被記錄、追蹤、並分派給負責人修復？
階段五：部署 (Deployment)
- [ ] 生產環境的設定安全嗎？例如，有沒有關閉不必要的 port？作業系統、Web Server 有沒有做強化 (Hardening)？
- [ ] 我們的 CI/CD pipeline 本身安全嗎？有沒有保護好 pipeline 的存取權限？部署用的金鑰有沒有妥善保管？
- [ ] 有沒有產出軟體物料清單 (SBOM, Software Bill of Materials)？這份清單會列出你軟體裡所有的元件，當未來某個套件爆出新漏洞時，你可以很快地知道自己有沒有受到影響。
- [ ] IaC (Infrastructure as Code) 的腳本有沒有經過安全掃描？如果你用 Terraform 或 CloudFormation 來管理基礎設施，那這些程式碼也應該被檢查。
階段六：維護與監控 (Maintenance & Monitoring)
- [ ] 我們有沒有監控系統的日誌 (Log) 來偵測異常活動？
- [ ] 有沒有建立漏洞通報的管道？如果外部的資安研究員發現你們的漏洞，他要怎麼聯絡你們？
- [ ] 有沒有定義好漏洞修補的流程跟 SLA (服務等級協議)？例如，高風險漏洞必須在 7 天內修補完成。
- [ ] 有沒有定期重新進行安全評估？威脅是會一直變的，所以安全檢測不是一次性的事。
觀念比較：導入 SSDLC 前後差在哪？
為了讓大家更有感，我弄了個簡單的表格，比較一下傳統開發流程跟導入了 SSDLC 的流程，在每個階段的思維有多大的不同。
| 開發階段 | 傳統開發流程 (沒有 SSDLC) | 安全開發流程 (導入 SSDLC) |
|---|---|---|
| 需求分析 | PM：「我們要做個很酷的社群功能！」 （重點全在功能） |
PM：「我們要做社群功能，而且要保護使用者個資，防止機器人洗版。」 （功能跟安全需求一起考慮） |
| 設計 | Tech Lead：「好，DB schema 這樣開，API endpoint 這樣訂。」 （只考慮怎麼實現功能） |
Tech Lead：「API 要加 rate limit，使用者上傳的檔案要隔離存放，DB 欄位要加密…」 （從威脅模型出發來設計架構） |
| 開發 | Developer：「功能寫完了，動了就好！」 （然後 code review 可能只看 coding style） |
Developer：「功能寫完了，SAST 掃過沒問題，也處理了 SQL Injection 的風險。」 （邊寫邊用工具檢查） |
| 測試 | QA：「功能點一點都正常，過關！」 （只測 Happy Path） |
QA：「功能測試OK，DAST 也跑了，還試了幾個 bypass 權限的濫用案例。」 （功能、安全、濫用都測） |
| 部署/上線 | Ops：「腳本跑下去，上線！啊…上線後才發現有洞…」 （祈禱不要出事） |
DevSecOps：「CI/CD pipeline 自動掃描、測試、部署，全程都有 log，SBOM 也產出了。」 （自動化、可監控、有紀錄） |
務實的導入建議：別想一步到位
看到這裡，你可能會覺得「哇，要做的事情也太多了吧！」沒錯，如果想一次全部做到完美，幾乎是不可能的任務，而且團隊的反彈一定會很大。所以，導入 SSDLC 的關鍵在於「循序漸進」。
我的建議是，先從「痛點」最明顯、而且「CP值」最高的地方開始。例如：
- 從開發階段開始：先要求團隊在 CI/CD 流程中，整合 SAST 跟 SCA 工具。這兩件事相對容易自動化，可以在不改變太多開發習慣的情況下，就抓住很多低級但常見的錯誤。很多 GitLab, GitHub Actions 都有內建或很容易整合的功能。
- 教育訓練很重要：與其發一堆文件，不如辦個 training session。 可以找一些真實的案例，分享 OWASP Top 10 的漏洞是怎麼造成的，讓開發者有感。
- 先挑一個新專案試點：不要一開始就想改造公司裡最複雜的那個祖傳專案。找一個新的、小型的專案來試行完整的 SSDLC 流程，會順利很多。
- 參考成熟的框架：你不需要從零開始發明一切。可以參考像是 OWASP SAMM (Software Assurance Maturity Model) 或 NIST 的 SSDF (Secure Software Development Framework)。 這些框架把安全實踐分成了不同的成熟度等級，你可以評估自己團隊現在在哪個等級，然後設定一個務實的目標，一步步往上爬。例如，OWASP SAMM 就把安全實踐分成很多個面向，你可以先挑「威脅評估」和「安全測試」這兩項來加強。
常見的錯誤與修正
在導入 SSDLC 的路上，很多團隊都會踩到一些相似的坑。這裡列出幾個最常見的，希望能幫你避開。
- 錯誤一：把 SSDLC 當成是資安團隊自己的事。
修正：安全是每個人的責任。PM 要懂安全需求，開發者要寫安全程式碼，QA 要做安全測試。SSDLC 要成功，必須要整個開發團隊都投入，而不只是等著資安團隊來「檢查」。 - 錯誤二：買了一堆昂貴的工具，卻沒有流程跟文化支持。
修正：工具只是輔助。如果你買了 SAST 工具，但開發者根本不看報告，那工具就只是個擺設。重點是建立起「發現問題 -> 分類 -> 修復 -> 驗證」的閉環流程，並讓團隊養成習慣。 - 錯誤三：檢核表變成只是「打勾」用的形式主義。
修正：檢核表的目的是「引發思考」，而不是「完成任務」。 在每個檢核項目後面，應該都要有對應的「產出」或「證據」。例如，「威脅模型分析」的產出就是一份威脅模型文件或圖表。如果只是勾選了「有」，卻什麼都沒做，那就失去意義了。 - 錯誤四：追求完美的安全性，導致專案動彈不得。
修正：安全永遠是風險管理，而不是消除所有風險。要學會依據風險高低來排定ولوويات。一個只對內使用的後台系統，跟一個處理金流的公開服務，它們的安全要求等級就不同。對於一些低風險的問題，可以先記錄下來，排入技術債清單，不一定要立刻停下所有事來修復它。
總結來說，我自己是覺得，把 SSDLC 成功導入團隊的關鍵，不在於你用了多厲害的工具，或是有多完美的檢核表。真正的關鍵在於「溝通」和「文化」。讓團隊裡的每個人都理解為什麼我們要做這件事，並且讓安全成為一種內建的「肌肉記憶」，而不是額外的負擔。一開始一定會痛，會需要磨合，但只要方向對了，循序漸進，你的團隊一定能開發出更安全、更可靠的產品。
好，今天大概就聊到這邊。希望這些內容對大家有幫助。如果你們團隊有導入 SSDLC 的經驗，不管是成功的還是失敗的，都歡迎在下面留言分享，我們可以一起交流一下。
