软件供应链风险量化：让漏洞、暴露与业务影响形成优先级
摘要
只看CVSS会忽略可利用性、资产暴露和业务关键程度。
一、为什么值得关注
软件供应链的风险跨越源码、依赖、构建、发布和运行环境。只在发布前扫描一次，无法证明交付链持续可信。团队需要将风险判断嵌入日常开发，并保留可以复核的证据。
二、核心技术与治理思路
建立仓库—依赖—构建—制品—部署的资产关系图谱；将KEV、EPSS、恶意包情报与业务分级结合。
三、落地示例
采用可解释的风险评分，定期校准权重；对高危且互联网暴露的核心服务优先处置。
建议采用以下策略样例作为讨论起点，而不是直接视为通用强制标准：
supply_chain_policy:approved_registry:truedependency_review:requiredsbom:requiredprovenance:required_for_productionartifact_signature:required_for_productionexception:owner:requiredexpiry:required四、实施步骤
- 盘点：建立仓库、流水线、依赖、制品和部署环境的对应关系。
- 试点：选择一个高价值服务，记录现状和风险。
- 自动化：将检查接入PR与CI，并对高风险条件执行阻断。
- 证据化：保留扫描报告、审批记录、Digest、SBOM与来源证明。
- 运营化：每月复盘例外、误报、修复时长和覆盖率。
五、常见误区
- 只装工具不设责任人：告警无人处置，覆盖率无法代表安全性。
- 只生成证据不验证：签名和SBOM只有进入消费侧策略才形成闭环。
- 一刀切阻断：应先观察、再分级，逐步进入强制模式。
- 把评分当真相：评分只能辅助排序，不能替代业务上下文和专家判断。
六、关键指标
| 指标 | 说明 |
|---|---|
| 资产覆盖率 | 纳入供应链台账的生产服务比例 |
| SBOM覆盖率 | 可追溯组件清单的制品比例 |
| 签名验证率 | 部署前成功验证的制品比例 |
| 高危整改时长 | 从发现到完成处置的时间 |
| 例外超期率 | 过期未关闭的安全例外比例 |
七、总结
只看CVSS会忽略可利用性、资产暴露和业务关键程度。真正有效的落地方式，是把要求转成可执行的工程控制、可复核的证据和可持续的运营指标。
