夜雨聆风
组件清单、制品签名、来源证明和可信准入的最小闭环
上一篇把安全检查前移到代码、依赖、构建、镜像、制品和发布门禁，这一篇继续深入制品可信本身：组件清单、签名校验和来源证明。
很多企业已经有代码扫描、依赖扫描和镜像扫描，但真正出问题时，仍然答不上三个问题：这个制品包含哪些组件，是否由可信流水线构建，发布到生产前有没有被篡改。
这一篇要回答的问题是：讲清企业如何用 SBOM、制品签名、来源证明、可信仓库和准入策略，把软件供应链风险从不可见变成可验证、可追溯、可阻断。对研发负责人、平台团队、安全团队、DevOps工程师、采购与合规负责人来说，软件供应链安全不是多生成几份报告，而是把“知道里面有什么、确认是谁构建、验证是否被改、决定能不能发布”做成闭环。
一、先把供应链风险拆成五个问题
软件供应链安全不要从工具清单开始，而要先回答五个问题。
这五个问题串起来，才是供应链安全闭环。只做漏洞扫描，最多知道“有没有已知风险”；做 SBOM、签名和来源证明，才能进一步判断“这个制品是否可信”。
二、SBOM：先解决“里面有什么”
SBOM 的价值不是生成一个文件，而是让企业能持续知道每个软件制品里包含哪些组件、版本、许可证和依赖关系。
第一阶段不要把 SBOM 做成“归档文件”。更重要的是让 SBOM 和制品库、漏洞库、发布记录关联起来：发现某个组件漏洞时，能快速知道哪些服务、哪些镜像、哪些环境受影响。
三、签名：确认制品没有被悄悄替换
制品签名解决的是完整性和身份问题。简单说，就是让平台在发布前能确认：这个镜像或制品确实来自可信构建流程，并且从构建完成到发布前没有被替换。
签名最常见的误区是只签了镜像，但发布时没有验证。签名只有接入发布门禁或准入策略，才真正有价值。
四、来源证明：确认制品是怎么构建出来的
来源证明解决的是“这个制品从哪次提交、哪条流水线、哪个构建环境生成”的问题。它比签名更进一步：不仅确认制品没有被改，还记录它是如何被构建出来的。
如果企业已经做了 DevSecOps 流水线安全，来源证明就是把那些流水线证据组织起来，变成制品可信的证明材料。
五、可信仓库：不要让制品四处散落
供应链安全落地时，可信仓库非常关键。没有统一制品入口，SBOM、签名和来源证明很难形成约束。
第一阶段可以先从生产镜像仓库做起：只允许可信流水线推送，推送后自动生成或关联 SBOM，签名后才能进入生产发布。
六、准入策略：把“可信”变成发布条件
供应链安全最后必须落到准入。否则 SBOM、签名和来源证明只是旁路材料，不能真正影响发布。
这一步的重点不是“所有问题都阻断”，而是把阻断、例外、提示和复核标准提前写清楚。
七、最小化落地步骤
第一版软件供应链安全可以按六步推进。
这六步跑通后，企业就能从“发现漏洞”升级到“验证制品是否可信”。
八、常见踩坑点
九、验收清单
十、管理者应该看什么
管理者不需要看每个 SBOM 字段，但要定期问四个问题：
某个组件爆出高危漏洞时，能不能在当天知道哪些业务受影响？ 生产里的每个关键制品，能不能证明它来自可信流水线？ 发布前是否能验证签名、摘要和来源证明，而不是只看镜像 tag？ 例外、未知来源制品和长期未修漏洞是否越来越少？
如果这些问题能回答，软件供应链安全才从“扫描报告”升级成“制品可信体系”。
十一、下一篇预告
下一篇会继续讲第三方与开源组件治理：从引入审批到持续风险复核。重点会放在组件引入审批、许可证风险、漏洞响应、供应商安全和持续复核。
参考来源
CISA: Software Bill of Materials CycloneDX Specification SPDX Specification Sigstore Cosign Documentation SLSA: Supply-chain Levels for Software Artifacts in-toto Attestation Framework NIST Secure Software Development Framework SP 800-218 国家互联网信息办公室
