资源 · 16
软件供应链保障：组件发布
将组件、来源、构建、漏洞和更新与每个实际部署的版本关联起来。
已更新 · 2 min
本指南有助于实现的目标
- 了解实际发布的依赖项
- 验证工件来源
- 根据上下文确定缺陷优先级
- 测试替换和回滚
快速检查
- 物料清单是否与已部署版本匹配？
- 是否包含传递依赖项？
- 谁可以签署版本？
- 您的使用过程中是否存在漏洞？
- 是否可以在不进行任何修改的情况下移除关键组件？
分步指南
- 1
映射已发布的版本
识别存储库、直接和传递依赖项、构建工具、镜像、外部服务及其所有者。 将所有这些关联到可验证的版本。
交付物：产品、组件、版本和所有者映射。
- 2
生成可用的物料清单 (SBOM)
为每个版本生成 SBOM，并将其与实际交付的工件进行比较。 解决名称不准确、版本缺失和内部组件等问题。
交付成果：带有日期且经过验证的 SBOM。
- 3
保护构建
限制发布权限，隔离敏感阶段，并保留来源、摘要和签名。 在部署前验证这些证据。
交付成果：构建记录和验证策略。
- 4
警报分类
将每个漏洞通知与组件、版本、暴露情况和实际使用情况关联起来。 指定负责人、截止日期、决策和关闭证据。
交付成果：上下文分类队列。
- 5
演练变更
在测试环境中替换关键组件，检查业务流程并演练回滚。 评估阻碍变更的依赖关系。
交付成果：替换和备用方案演练报告。
- 6
保存证据
在重大版本发布和事故发生后审查组件和供应商。 保留记录以支持调查和纠正措施。
交付成果：审查日历和发布历史记录。
管理指标
| 指标 | 衡量内容 | 首要行动 |
|---|---|---|
| SBOM 覆盖率 | 已发布版本，并已检查组件清单 | 发布前解决差异 |
| 已验证来源 | 部署前已检查工件 | 阻止缺少预期证据的发布 |
| 分类时间 | 从相关通知到记录决策的时间 | 升级暴露组件 |
| 可逆性 | 已测试关键替换组件的回滚功能 | 移除阻塞依赖项 |
常见错误
- 混淆存储库清单和已部署组件
- 保留 SBOM 而不更新
- 仅按分数对缺陷进行排名
- 未验证构建来源就对工件进行签名
常见问题解答
SBOM 是否足够？
不够。它有助于识别组件，但来源、完整性、暴露情况和更新能力也需要验证。
每个漏洞都应该阻止发布吗？
根据实际使用情况、风险暴露程度、补偿控制措施和业务关键性做出决策，并记录决策理由。
哪些参考框架有所帮助？
NIST 安全软件开发框架提供贯穿整个生命周期的安全开发和软件保护实践。
官方参考文献
参考文献支持该方法。 请根据您的实际情况调整检查；它们并非认证。 原始参考文献标题和源文档可能使用其他语言。
