NIST SP 800-218：安全软件开发框架（SSDF）完全引入
NIST SP 800-218 把软件开发全流程的安全要求收成一张清单——从需求到维护每个阶段该做什么。本文覆盖 SSDF 定位、设计哲学、16 项实践清单、实施指南，以及与国标 GB/T、ISO 27001 的对照、NIST 官方工具与配套参考标准。附 SSDF 与 SDLC 的关系图。
一、它是什么
NIST（美国国家标准与技术研究院）于 2022 年 2 月发布的官方标准，名字很长但内容直接：
《安全软件开发框架》（Secure Software Development Framework，简称 SSDF）版本 1.1：降低软件漏洞风险建议
它和传统的"软件生存周期标准"（如 ISO/IEC 12207）最大的不同是：一份开发区流程的标准里，第一个把"安全"作为强制要求嵌进每一步。
发布它的背景是美国 2021 年 5 月的《改善国家网络安全行政令》（Executive Order 14028）——联邦机构必须在采购软件时证明供应商"按安全流程开发"，SP 800-218 就是给企业"怎么证明其开发流程是安全的"提供标准答案。
两个权威来源
- 官方全文 PDF：https:/
/ nvlpubs. nist. gov/ nistpubs/ SpecialPublications/ NIST. SP. 800‑ 218. pdf - NIST CSRC 项目主页：https:/
/ csrc. nist. gov/ projects/ ssdf
作者
Murugiah Souppaya（NIST）、Karen Scarfone（Scarfone Cybersecurity）、Donna Dodson
演进路径
第一版（SSDF 1.0）是 2020 年 4 月以"白皮书"形式发布的（NIST Cybersecurity White Paper #13）。2022 年 2 月正式升为 SP 800-218 标准。2026 年起持续增长，最新新增了针对生成式 AI 开发的补充 SP 800-218A。
二、它要解决什么
两点：
第一，大多数软件开发标准没有专门处理"安全"。ISO 12207、CMMI 等讲的是"开发流程怎么走"，但不具体讲"每一步怎么保安全"。SSDF 假设用户采用一条软件开发流程，然后把该流程的每个阶段都重新用"安全目标"写一遍。
第二，消费者不知道怎么选"安全可靠的软件"。一个企业买软件，供应商说"其流程是好流程"，但怎么证明？SSDF 提供4 组 16 个实践 + 每个实践的验收动作 + 验收标准（Outcome），这样采购方可以按这 16 条问供应商。
三、核心结构：4 组 + 16 个实践（Practice）
这是 SSDF 最核心的东西。它把"安全开发全流程"分成 4 个阶段，每个阶段有 4 个具体实践。
3.1 四个阶段（Practice Group）
PO — 准备组织（Prepare the Organization）
第一步：管理层 + 设备上 + 工具上，准备好"能安全地开发"的条件。
PS — 保护软件（Protect the Software）
第二步：开发过程中，每一步都保持软件组件和源代码不被篡改、不被未授权访问。
PW — 产出安全可靠的软件（Produce Well-Secured Software）
第三步：目标——交付出去的代码，漏洞最少。
RV — 响应漏洞（Respond to Vulnerabilities）
第四步：软件上线后，发现漏洞怎么修、怎么防下一次。
3.2 16 个实践完整清单
| # | 组 | 实践编号 | 实践名称（原文摘要） |
|---|---|---|---|
| 1 | PO | PO.1 | 为所有软件开发人员定义安全需求 |
| 2 | PO | PO.2 | 实现自动化支持功能集 |
| 3 | PO | PO.3 | 规定信息安全的任务及职责 |
| 4 | PO | PO.4 | 使用安全机制培训教育事业 |
| 5 | PO | PO.5 | 建立安全软件开发与测试环境（v1.1 新增） |
| 6 | PS | PS.1 | 保护所有组件（代码、库、配置）免受篡改与未授权修改 |
| 7 | PS | PS.2 | 收集并记录证据以证明软件按规范正确产出 |
| 8 | PS | PS.3 | 保护开发、测试与生产构建环境（v1.1 新增任务：收集成分来源溯源数据） |
| 9 | PW | PW.1 | 对所有发布的版本执行软件漏洞喷洒与弱点分析 |
| 10 | PW | PW.2 | 创建低漏洞的第三方件库版本 |
| 11 | PW | PW.3 | 对每个组件执行静态分析（SAST）、动态分析（DAST）、依赖审计与软件加固 |
| 12 | PW | PW.4 | 使用专业安全开发规范进行代码评测 |
| 13 | RV | RV.1 | 开发产品安全事件响应标准、过程与访问 |
| 14 | RV | RV.2 | 公开验证漏洞披露（PSRI）与责任披露关系及 SLA |
| 15 | RV | RV.3 | 从最终用户提供反馈与安全事件报告 |
| 16 | RV | RV.4 | 在过程中记录、共享信息安全教训，并在流程中实施预防 |
3.3 每个实践的 4 要素（重点看 PW 里怎么展开）
SSDF 的每个 Practice 由 4 个字段定义，这就是它"可执行"的原因：
1. Practice（实践）——事情本身是什么，为什么重要
2. Task（任务）——实施该实践具体要做什么动作（每个实践 1-4 个任务）
3. Notional Implementation Example（概念化实施方案）——一个工具 + 流程 + 步骤的具体例子（不是唯一方案，而是"可这样实施"的示范）
4. Reference（参考）——对应一个既定的安全开发实践文档（OWASP、ENISA、SAFECode、BSI、NIST 自身 CSWP 等），以及这些文档映射到哪一个或哪几个任务
举例——PW.3 静态分析任务展开：
- Practice：对每个组件执行静态分析与动态分析
- Task 1：对源代码进行静态分析（SAST）
- Task 2：对依赖进行依赖审计
- Task 3：对构建产物运行动态分析（DAST / Fuzzing）
- Task 4：加固代码以避免常见漏洞类（注入、XSS、反序列化等）
- Implementation Example：例如用 SonarQube（SAST）+ Snyk（依赖）+ OWASP ZAP（DAST）
- Reference：指向 OWASP Secure Coding Practices, SAFECode, NIST 今端的 CSWP 各篇文档
四、实施指南：怎么用 SSDF
NIST 在文里明确说：
> SSDF 不是一张清单去照抄，而是一个规划起点。
> 一个组织会根据它自己的风险容忍度、成本、资源、发展阶段，选用哪些实践、投入多少，同时这个起点本身是可以随时间演化的。
这就是它和 CMMI / ISO 25000 等"评估类标准"不同的地方——它不打分，不审证书，它给的是"目标清单 + 验收动作"，使开发流程往这个方向去。
四步实施法（NIST 官方建议）
1. 看现状：当前软件的安全状况，有没有漏事件
2. 对对 16 实践：逐条核对做没做（没全做也正常——任何企业都做不到 100%）
3. 找差距：哪些是严重缺、哪些是重要缺
4. 定行动计划：按优先级 + 资源，逐项排期，一个月/一个季度一个实践
五、典型应用场景（为什么企业喊"EO 14028 需要 SSDF"）
最关键的业务场景——政府采购（具体有直接法律约束）：
- 2021 年 5 月《EO 14028 第 4e 条》要求：中小企业但凡中标美国联邦机构软件合同，必须证明其开发流程符合可测量、可信的"安全软件开发标准"
- 2024 年 10 月 1 日起强制执行，这个标准是什么？就是 NIST SP 800-218
- 所以在美国，"证明 SSDF 合规"成为了联邦软件达标的关键门槛——如 JFrog、HPE、Atlassian 等都有'NIST 800-218 合规包'产品
对开发者的应用（不用碰政府采购的场景）
- 开源项目：用 SSDF 当"安全红线"，社区安全设施一步推着无漏洞类（可安全编程、无供应链漏洞）
- 软件外包：甲方按 SSDF 的 16 实践做对对，乙方逐项证明已做
- 内部团队安全文化：在安全培训、代码评审制度里把这 16 条揉进去，避免安全只是"IT 部门的事"
六、SSDF 在规范体系里的位置
把它放在一张坐标系里看——和映射位置就清楚了：
简说：SSDF 是一个横向安全层，叠在软件开发流程的每一步之上——定义了在需求、设计、编码、测试、发布、维护的每一步上，安全要求是什么。
七、与国标 GB/T 的对标关系
| 维度 | GB/T（中国） | NIST SP 800-218 |
|---|---|---|
| 生存周期过程 | GB/T 8566 | 重叠：SSDF 按 SDLC 阶段走 |
| 文档管理 | GB/T 8567 | 重叠：PS.2 记录证据 + PO.1 定义需求 |
| 单元测试 | GB/T 15532 | 重叠：PW.3 静态分析 + 测试 |
| 质量特性 | GB/T 25000 | 重叠：SSDF 即"安全"那个特性的标准 |
| 安全专项 | 无专门国标（只有 CIS 类标准） | SSDF 就是"安全"这块的官方标准 |
区别：
- GB/T 是一个"过程 + 质量"通用框架
- SP 800-218 是"安全"专项框架
- 两不冲突，可叠加：一个中国软件公司既需要 GB/T 8566 声明"其过程合规"，也可以同时 SP 800-218 声明"其安全合规"
八、NIST 官方工具（下载即做）
NIST 给出了这些免费工具，里就是"做完 SSDF 16 个实践"里具体该用上的：
1. SSDF 官方 Excel 表格：含 16 实践的完整 Task 与 Reference 映射（每阶段做什么、对应到哪些具体技术要求）。官方 XLSX 文件下载地址：
csrc.
nist.
2. SP 800‑218A：AI 增补（2026 年发布）：针对生成式 AI 与双用途基础模型的 SSDF 个性化实践——AI 系统在 SSDF 16 之外需要追加什么。
九、配套参考标准（非 NIST 自有，但 NIST 在文档里指向）
SSDF 本身不做 "详细怎么写" 的部分，而是转指给那些标准去展开：
OWASP Secure Coding Practices——OWASP 独立组织的安全编码指南，NIST 在 SP 800-218 中指出编码角色应使用的核心参考。
IEC 62443‑4‑1——欧洲电工技术委员会，工业系统安全开发的安全设计要求。
ISO/IEC 29147——产品漏洞披露流程标准化。
ISO/IEC 30111——漏洞处理全过程：接收 → 验证 → 修复 → 发布。