软件供应链安全怎么落地：从依赖清单到制品签名

软件供应链安全要落地，关键不是单独生成一份软件物料清单（SBOM），而是把依赖识别、漏洞处置、构建记录和制品验签串成发布门禁。团队可以按代码依赖、构建过程、发布制品三个环节逐步实施：先知道软件由什么组成，再确认它如何构建，最后验证交付物是否来自可信流程且未被篡改。需要注意，签名能帮助验证来源和完整性，不代表制品本身没有漏洞。

一、代码依赖：清点组成，并让漏洞处置进入流程

软件物料清单用于描述一个软件版本包含哪些组件及其版本信息。它可以帮助团队识别直接依赖与间接依赖，为漏洞排查、影响范围分析和后续升级提供依据。它不是漏洞扫描报告，也不能仅凭清单判断软件是否安全。

落地时，先从构建实际使用的依赖信息生成清单，而不是只依据开发者手工维护的文档。清单应与具体版本或构建关联，便于在出现漏洞时判断哪些已发布版本可能受影响。对于容器等交付形态，也应明确扫描对象与交付物之间的对应关系，避免只检查源代码依赖，却遗漏最终制品中的组件。

依赖扫描则回答另一个问题：已识别的组件中，哪些匹配已知漏洞信息或违反团队的依赖策略。扫描结果需要经过判断，不能将“发现漏洞”直接等同于“可利用”，也不能因为漏洞暂时没有修复版本就忽略风险。团队应为每项发现记录组件、受影响版本、风险判断、处置方式和责任人。

可执行的检查清单：

• 每次发布都生成与版本绑定的 SBOM，并能追溯到对应构建。
• 扫描覆盖直接依赖和间接依赖；明确哪些目录、镜像或制品纳入检查。
• 为高风险问题设定发布阻断条件，并明确例外审批人、理由和复查期限。
• 将升级依赖、替换组件或接受风险的决定留档，避免扫描结果长期无人跟进。
• 对暂时无法修复的问题设定复核时间；漏洞信息或组件版本变化后重新评估。

验收时不要只看“扫描任务成功”。更有意义的标准是：发布版本都有可读取的清单；阻断规则确实能阻止不符合条件的发布；例外可追踪、可到期复核；团队能从一条漏洞记录定位到受影响版本和后续处置。

二、构建过程：记录制品是如何产生的

依赖清单描述“包含什么”，构建来源记录（provenance）则描述“它是怎样生成的”。它通常需要把制品与源代码版本、构建流程、构建环境和关键输入关联起来。发生异常时，这些信息有助于判断某个制品是否来自预期的代码与流水线，而不是仅凭文件名或版本号推测。

构建记录要由实际构建流程产生，并与最终制品建立可验证的关联。若团队允许人工在流水线外替换文件、重新打包，却不更新记录，来源信息就无法完整反映交付过程。对于发布流程中的人工操作，也要明确记录哪些操作会改变制品，以及如何重新生成或更新相关证据。

建议先从最重要的生产发布流水线开始，记录以下信息：

• 对应的代码提交或版本标识。
• 使用的构建流程及其版本，执行构建的身份或环境。
• 构建输入与输出制品之间的对应关系。
• 构建结果、关键审批和必要的人工干预记录。

验收可以从“能否核对”开始：抽取一个已发布制品，能够找到其来源记录，并确认记录指向的代码版本、构建流程和制品相互匹配。还应验证非预期身份或未经批准的构建流程不能绕过发布门禁。具体记录字段和阻断规则应根据团队架构确定，不必一开始就追求覆盖所有开发与测试环境。

三、发布制品：签名并在使用前验证

制品签名用于验证制品是否与签名时的内容一致，以及签名是否来自团队认可的身份。它解决的是来源与完整性验证问题，不是质量背书：一个存在漏洞的制品也可能被正确签名。因此，签名应建立在前两个环节的检查基础上，而不是替代依赖扫描或构建治理。

发布流程中，签名对象应是最终交付的制品，并与版本、来源记录及必要的 SBOM 对应。签名密钥或签名身份需要受到访问控制；谁能发起签名、哪些构建可以签名、签名结果保存在哪里，都应有明确规则。部署或交付前再验证签名，并检查签名身份是否符合策略，才能把签名从“归档信息”变成实际门禁。

发布验收可检查：

• 最终制品存在可验证的签名，且签名对应的内容与交付内容一致。
• 验签策略限定可信身份或构建来源；验证失败时，发布或部署会被阻断。
• 制品、签名、来源记录和 SBOM 能通过版本或摘要相互关联。
• 密钥或身份的授权、轮换、撤销及异常处理有责任人和操作记录。
• 重新打包、修改或替换制品后，原有验证结果不再被误认为适用于新制品。

从试点到常态化：按发布路径逐步推进

团队不必一次性改造所有仓库。可以先选一个有代表性的服务或应用，梳理其依赖、构建和交付路径；再把 SBOM 生成、扫描处置、构建记录、制品签名依次接入现有流水线。先以报告模式观察误报和流程缺口，再逐步对高风险问题、非可信构建和验签失败设置阻断。

一套可落地的发布检查清单，可以压缩为四个问题：

1. 清单是否齐全？ 这次发布的制品能否对应到实际依赖清单？
2. 风险是否处置？ 发现的问题是否有修复、接受风险或限期复核的记录？
3. 来源是否可查？ 能否从制品追溯到代码版本和受控构建流程？
4. 交付是否可验？ 部署前能否验证签名，并拒绝不符合策略的制品？

如果其中任一项无法回答，团队就应先修补对应的流程断点，而不是仅增加一份报告或一个安全工具。成熟度的衡量重点也不应只是“接入了多少检查”，而是发布证据是否完整、失败门禁是否有效、例外是否可审计，以及团队能否在问题发生时快速界定影响范围。

【软盟资讯观察】

趋势判断： 软件交付的安全控制正在从“发布前做一次扫描”转向沿交付链留存可核验的证据。对企业而言，清单、构建来源和签名的价值在于彼此关联，形成可追溯的发布记录，而非单项工具的数量。

机会与风险： 先从高价值系统和关键发布路径试点，可以让安全要求更贴近工程流程，也便于逐步建立例外管理和责任边界。但如果只追求自动生成文件，缺少版本关联、验签门禁和漏洞处置责任，证据很容易变成无人维护的附件。

冷思考： 安全控制会增加构建、审查和密钥管理成本，团队需要按业务影响确定阻断级别，并持续校准策略。签名可信不等于软件无缺陷，清单完整也不等于风险已消除；真正可用的供应链安全，是能在异常发生时解释制品从何而来、受什么影响，以及团队采取了什么行动。