软件供应链安全要验证来源、构建与交付链路

现代软件由源代码、第三方依赖、构建工具、基础镜像、制品仓库和部署系统共同形成。攻击者不必直接突破生产服务，只要污染其中一个上游环节，就可能让合法发布流程分发恶意内容。供应链安全关注的是每个转换步骤的来源、权限和完整性证据。

依赖扫描只是其中一项活动。即使所有依赖没有已知漏洞，构建凭据被盗、源码审查被绕过或制品在仓库中被替换，仍会产生严重风险。

资产清单连接源码与运行制品

组织需要知道一个生产制品来自哪个仓库、提交、依赖锁文件、构建任务和基础镜像。清单若只列包名，无法在构建工具或证书泄露时确定影响范围。

软件物料清单可以记录组件与版本，但不自动证明组件真实进入制品，也不证明来源可信。它应由构建过程生成，与制品摘要绑定，并在发布后可查询。手工维护很快会漂移。

开发、测试工具和构建插件同样属于供应链。它们可能只在构建时执行，不出现在运行依赖列表，却拥有源码、令牌和制品写入权限。

包名相似、命名空间接管和镜像源混用会让解析器下载错误组件。仓库配置应限定可信源和作用域，锁定可重现版本，并验证摘要或签名。临时从个人地址获取二进制会绕过审计。

长期固定版本能减少意外变化，却会积累漏洞；无条件自动更新又可能直接引入破坏或恶意版本。更新策略应结合风险、兼容测试和回退，关键依赖需要所有者和替代方案。

漏洞数据库只覆盖已知问题。项目活跃度、维护者变化、发布流程和权限模型也影响风险。很少更新不一定不安全，频繁更新也不代表可靠，判断需要保留依据。

构建任务通常能读取源码并写入发布仓库，是高价值执行环境。任务应使用短期身份、最小网络和仓库权限，构建结束后销毁。共享持久工作区可能让前一个任务污染后续输出。

依赖下载与编译步骤需要固定输入。构建时间、随机数和外部网络内容会破坏可重现性。完全字节级重现并非所有项目都容易，但至少应记录工具链、环境和所有解析结果，使差异可以调查。

来自分支或外部贡献的任务不能自动获得生产密钥。审批状态与代码内容之间要有不可绕过的连接，批准后提交变化应使批准失效。

制品签名验证某个身份认可了特定摘要，来源证明则记录构建者、输入和过程。两者都依赖密钥和签发系统安全，不能因签名有效就推断代码没有漏洞。

签名应在受控构建环境产生，私钥不直接暴露给普通任务。验证必须发生在部署入口；只在仓库上传时验证，后续替换仍可能进入生产。验证失败应拒绝，而不是记录警告后继续。

制品在晋级测试、预发布和生产时应保持同一摘要。每个环境重新构建会产生多个无法比较的结果。环境差异应通过外部配置注入，并受到独立管理。

能够修改代码的人不应单独绕过审查并发布生产，能够管理仓库的人也不应无痕替换制品。分支保护、审批、构建身份和部署授权形成连续控制，任一旁路都会削弱整体保证。

紧急发布仍要有受控流程。紧急账号、审批和事后审查应预先设计，不能在事故中临时共享管理员密码。速度要求不等于取消来源记录。

部署清单、策略和基础设施代码也是供应链输入。攻击者修改部署参数，可以让正确制品以高权限或不安全入口运行。对这些内容需要同等审查、签名和审计。

出现新漏洞时，要从组件定位所有制品、环境和运行实例。仅搜索源码可能漏掉间接依赖和旧镜像。资产清单、构建记录与部署清单应能双向查询。

修复包括升级、配置缓解、功能关闭或隔离。每种处置都要验证实际生效，并记录无法立即升级的风险接受。补丁完成后仍需处理缓存、旧节点和可下载历史制品。

被污染的签名密钥或构建平台需要更广泛响应。仅重新构建当前版本不够，还要确定信任起点、撤销凭据、重签可信制品并通知使用方。

采购方应明确组件清单、漏洞通知、支持期限、更新真实性和事件响应责任。问卷不能替代制品摘要、签名和可验证更新渠道。供应商提供的证明也有适用范围和有效期。

无法获得完整构建证据的闭源组件，可以通过隔离、权限限制、运行监控和替代计划降低风险。风险不能因为合同存在就被视为转移完毕。

对外发布软件时，组织也成为他人的供应商。安全开发实践、变更记录、漏洞接收渠道和及时通知共同影响下游风险。

软件供应链安全建立的是从来源到运行实例的证据链。它不能证明软件绝对安全，但能减少未授权变化、缩短影响定位，并让每次发布都能回答“这是什么、从哪里来、由谁以什么过程生成”。

NIST：Secure Software Development Framework Version 1.1，https://csrc.nist.gov/pubs/sp/800/218/final
OWASP Foundation：Application Security Verification Standard，https://owasp.org/www-project-application-security-verification-standard/