供應鏈
NIST SSDF（SP 800-218）
安全軟體開發框架（Secure Software Development Framework，SSDF）是 NIST 為打造安全軟體所訂定的一套實務做法。它以 SP 800-218 發布，分成四個群組描述成熟的開發計畫應該做什麼，但不規定您該使用哪些工具。它因美國聯邦政府的軟體規定而廣為人知，如今已是安全開發普遍採用的參考依據。
更新日期
四大實務群組
SSDF 將實務做法分成四個群組。 每項實務都陳述一個成果，而 NIST 明確表示它並不是檢核表，而是以風險為基礎進行規劃的依據。
| 群組 | 目標 | 範例 |
|---|---|---|
| Prepare the Organization（PO，準備組織） | 人員、流程與工具已準備就緒 | 定義資安需求、指派角色、保護開發環境 |
| Protect the Software（PS，保護軟體） | 程式碼與發布版本不受竄改 | 保護所有形式的程式碼、驗證發布版本的完整性、封存每個發布版本 |
| Produce Well-Secured Software（PW，產出安全的軟體） | 發布的軟體中漏洞極少 | 以安全為前提設計、重複使用安全的軟體、審查並測試程式碼 |
| Respond to Vulnerabilities（RV，回應漏洞） | 找出殘留的缺陷並加以處理 | 持續識別漏洞、排定優先順序並修正、分析根本原因 |
與您的供應鏈相關的實務做法
- PO.3 支援工具鏈，以及 PO.5 安全環境。您的 CI 系統也是必須保護的對象之一。請參閱 CI/CD 管線安全檢核表。
- PS.3 封存並保護每個發布版本。這包括為每個發布版本的元件蒐集來源證明（provenance）資料，而 SSDF 指出 SBOM 是達成此目的的一種方式。
- PW.4 重複使用安全的軟體。第三方元件應經過審查並保持更新，這正是 軟體組成分析的用武之地。
- RV.1 持續識別漏洞。這是持續性的責任，而非發布前的關卡，因此需要監控您已出貨的軟體。
- RV.2 評估、排定優先順序並修補。請參閱 如何排定漏洞的優先順序。
SSDF 是強制性的嗎？
它本身不是。它是 NIST 的出版品，而不是法律。有幾年時間，它與美國聯邦供應商直接相關，因為 OMB 備忘錄 M-22-18 與 M-23-16 要求供應商證明自己遵循源自 SSDF 的實務做法。這在 2026 年 1 月 23 日有了改變： OMB 備忘錄 M-26-05 撤銷了上述兩份備忘錄，改採以風險為基礎的做法。各機關仍可使用共通的證明表單與 NIST 的標準，但已不再強制要求，因此供應商應預期各機關的要求會有所不同。
在聯邦採購之外，SSDF 作為共通語言依然實用。客戶會在資安問卷中引用其內容，而它也能對應到其他標準。
SSDF 的版本
- 1.1 版，即 SP 800-218，於 2022 年 2 月發布，是目前的正式版本。
- 1.2 版，即 SP 800-218 Revision 1，已於 2025 年 12 月 以草案形式發布。
- SP 800-218A 是一份社群設定檔（community profile），將 SSDF 延伸至生成式 AI 與雙重用途基礎模型。
如何導入 SSDF
- 盤點您目前的做法。逐一檢視各項實務，記錄您已達成哪些，以及有什麼佐證資料。
- 依風險排序缺口。SSDF 期望您依自身風險套用它，因此並非每項實務都需要同樣的深度。
- 讓佐證資料自動化。從管線產出的佐證資料無需額外工作就能保持最新，手寫的佐證資料則會過時。
- 指派負責人。每項實務都需要一位負責人。大多數會落在工程團隊，而非資安團隊。
- 定期檢討。隨著您的工具改變以及 1.2 版的進展，更新對應關係。
SSDF、SLSA 與 CRA
SSDF 說明安全開發計畫應達成的目標。SLSA 則深入其中一個部分：建置完整性。歐盟 Cyber Resilience Act（CRA）是一部有其自身義務的法律。為其中一項所做的工作可以沿用到其他兩項，因為它們都期望您了解自己的軟體裡有什麼，並處理其中的漏洞。
CRACI 的定位
SSDF 是範圍廣泛的計畫，沒有任何工具能完整涵蓋。CRACI 為仰賴建置與已出貨內容的實務做法提供佐證資料：來自每個 GitHub Actions 作業的 SBOM、建置環境中的隔離作業與對外連線控制、對已出貨軟體的持續監控，以及對發現結果的分級研判。CRACI 不會讓您自動符合規範，對應與證明仍由您負責。請參閱 CRACI 的軟體供應鏈安全。
NIST SSDF：常見問題
什麼是 NIST SSDF？
安全軟體開發框架（Secure Software Development Framework），以 NIST SP 800-218 發布。它是一套打造安全軟體的實務做法，分為四個群組：準備組織、保護軟體、產出安全的軟體，以及回應漏洞。
SSDF 是什麼的縮寫？
Secure Software Development Framework（安全軟體開發框架）。
SSDF 是強制性的嗎？
不是。它是指引，而不是法律。美國聯邦供應商過去必須證明自己遵循其中的實務做法，但 OMB 備忘錄 M-26-05 已於 2026 年 1 月撤銷這項要求。各機關仍可能要求提出證明。
SSDF 的最新版本是哪一版？
1.1 版（SP 800-218，2022 年 2 月）是目前的正式版本。1.2 版已於 2025 年 12 月以草案形式發布，其狀態請查閱 NIST 網站。
SSDF 與 SLSA 有何不同？
SSDF 涵蓋整體的安全開發，橫跨人員、流程與技術。SLSA 則深入探討建置完整性與來源證明。兩者能相輔相成。
SSDF 要求 SBOM 嗎？
它要求您為每個發布版本的元件蒐集並分享來源證明資料，並指出 SBOM 是做到這一點的一種方式。它描述的是成果，而非強制使用特定工具。