软件供应链安全：从SBOM到制品签名

现代应用很少从零开始。一个制品可能包含操作系统包、开源库、容器基础镜像、构建插件、下载脚本和外部流水线。攻击者不一定直接入侵生产服务器，也可能污染依赖、构建环境、制品仓库或更新渠道。软件供应链安全的目标，是让组织能够回答：软件由什么组成、从哪里来、由谁以什么过程构建、是否被篡改、发现风险后如何定位和处置。

本文面向研发、DevOps、平台、安全和运维团队，给出从资产清单、SBOM、构建来源到签名验证的渐进式方案。

一、软件供应链包含什么

一条常见供应链包括：

  1. 源代码仓库、提交和分支；
  2. 开发依赖和包管理器；
  3. CI运行器、构建容器和插件；
  4. 编译器、基础镜像和系统包；
  5. 测试、扫描和审批；
  6. 制品仓库、镜像仓库和发布渠道；
  7. 部署清单、IaC和GitOps仓库；
  8. 运行环境和更新机制；
  9. 外部供应商提供的二进制、设备固件和SaaS。

其中任何环节失去身份、完整性或可追溯性，都可能让未经授权的内容进入生产。

二、常见风险

  • 依赖名称拼写相近，下载了恶意包；
  • 使用浮动版本或 latest，同一构建得到不同结果；
  • 从非官方站点下载脚本并直接通过管道交给 shell；
  • CI 插件或 Action 使用可变标签，后续被替换；
  • 构建运行器长期保存高权限密钥；
  • 开发人员本机构建后直接上传生产制品；
  • 镜像仓库允许覆盖已有标签；
  • 只做漏洞扫描，不验证制品来源；
  • SBOM生成后不更新、不保存，也没有消费流程；
  • 紧急修复绕过流水线，事后没有补齐记录。

三、先建立最小资产与责任边界

在引入复杂工具前，先明确：

  • 哪些仓库和制品进入生产；
  • 每个服务和镜像的负责人；
  • 使用哪些语言、包管理器和基础镜像；
  • 构建在哪里运行，由谁管理；
  • 制品保存多久、谁可以发布或删除；
  • 哪些外部组件无法自行构建；
  • 漏洞和供应链事件由谁接收、评估和修复。

如果不知道生产正在运行哪些版本，再完善的扫描结果也无法快速映射到真实影响。

四、依赖治理

1. 锁定版本

应用依赖、基础镜像、CI插件和工具尽量使用不可变版本或摘要。锁文件应提交到版本库，并在评审中关注依赖变化。

2. 管理依赖来源

企业可以通过内部代理仓库统一访问外部依赖，获得缓存、审计、隔离和下架能力。代理仓库不能自动保证包安全，仍需校验来源、签名和策略。

3. 控制新增依赖

新增依赖前评估：维护活跃度、许可、已知漏洞、发布者身份、下载来源、替代方案和业务必要性。不要只因为一个库能减少几十行代码就忽略长期维护成本。

4. 自动更新但不自动直达生产

自动化工具可以创建升级合并请求，但仍需要测试、兼容性验证和渐进发布。安全更新也可能带来行为变化。

五、SBOM是什么

软件物料清单（SBOM）描述制品包含的组件及其关系。常见格式包括 SPDX 和 CycloneDX。一个有用的SBOM通常包含：

  • 组件名称、版本和唯一标识；
  • 包供应商或作者；
  • 依赖关系；
  • 哈希或校验信息；
  • 许可证；
  • SBOM生成工具、时间和对应制品；
  • 已知情况下的构建或分发信息。

SBOM不是漏洞扫描报告，也不能证明软件没有恶意代码。它提供的是透明度和定位基础。

六、SBOM生命周期

生成

尽量在构建流水线中针对最终制品生成，而不是只扫描源代码目录。容器镜像应包含操作系统包和应用依赖。

关联

SBOM必须与制品摘要、版本、仓库和部署记录关联。只有一个名为 sbom.json 的文件却不知道对应哪个镜像，没有实际价值。

保存

SBOM应随制品保留，设置访问权限和保留周期。对供应商软件，需要在采购和更新流程中收集。

消费

当高危漏洞公布时，通过SBOM快速查询受影响制品，再结合实际部署和可利用性判断优先级。

更新

每次制品内容改变都要重新生成。不要把旧SBOM复制到新版本。

七、漏洞并不等于风险结论

扫描器发现CVE后，需要结合：

  • 组件是否实际存在于最终制品；
  • 漏洞代码路径是否可达；
  • 功能是否启用；
  • 是否暴露给不可信来源；
  • 是否有厂商补丁或缓解措施；
  • 业务重要性和数据级别；
  • 是否已有利用活动；
  • 修复是否可能引入更大风险。

可以使用VEX等方式记录某个漏洞对特定产品是否受影响及理由，但结论必须有证据、负责人和复核机制。

八、构建来源与SLSA

来源证明（Provenance）描述制品在哪里、何时、用什么输入和构建过程产生。SLSA提供逐步提高供应链完整性的框架。落地重点包括：

  • 构建由受控系统执行，而非个人电脑；
  • 构建步骤由版本化配置定义；
  • 来源证明由构建平台生成，不能由提交者随意伪造；
  • 构建服务和发布人员权限分离；
  • 制品与来源证明使用不可变摘要关联；
  • 消费端在部署前验证来源和策略。

来源证明回答“怎么构建”，SBOM回答“里面有什么”，两者相互补充。

九、制品签名与验证

签名解决什么

签名可以帮助验证制品发布者和内容完整性，但不能证明代码没有漏洞。签名私钥或身份流程一旦被滥用，恶意制品也可能拥有有效签名。

推荐流程

  1. CI完成测试和扫描；
  2. 生成制品、SBOM和来源证明；
  3. 使用受保护身份完成签名；
  4. 上传到不可随意覆盖的制品仓库；
  5. 部署策略验证签名、摘要、来源和允许的构建者；
  6. 记录验证结果和部署环境；
  7. 密钥或身份泄露时可以吊销、阻止并重新签名。

优先使用短期身份或无长期私钥的签名方式；必须使用私钥时，应放在KMS/HSM或受控签名服务中，并限制导出。

十、CI/CD安全基线

  • 流水线配置与应用代码一样需要评审；
  • 第三方Action、插件和镜像固定到版本或提交摘要；
  • 合并请求中的不可信代码不能自动获得生产密钥；
  • 构建运行器按任务隔离并及时销毁；
  • 默认只读权限，需要写权限时单独声明；
  • 密钥不写入环境输出、缓存和构建产物；
  • 发布与审批角色适当分离；
  • 保护主分支、发布标签和制品仓库删除权限；
  • 构建日志、签名和来源证明具有审计记录；
  • 依赖代理、仓库和构建平台本身纳入补丁与备份。

十一、容器供应链

容器场景还应关注：

  • 使用精简、受维护的基础镜像；
  • 基础镜像固定摘要并有更新流程；
  • 多阶段构建避免把编译工具和密钥带入最终镜像；
  • 以非root用户运行；
  • 清理包管理缓存和不需要的软件；
  • 镜像仓库开启访问控制、扫描、保留和不可变标签；
  • 部署时验证签名与允许的仓库；
  • 运行时镜像与批准摘要一致；
  • 高危镜像的例外有到期时间和补偿措施。

十二、供应商软件管理

采购和引入外部软件时可以要求：

  • 支持的版本和安全更新期限；
  • 漏洞通报渠道和响应时限；
  • SBOM格式、更新频率和交付方式；
  • 签名、哈希和官方下载渠道；
  • 第三方组件与许可证说明；
  • 安全事件通知和远程访问边界；
  • 产品停服或厂商退出时的数据导出与替代方案。

SBOM是输入之一，不能替代供应商安全评估和合同约束。

十三、发现供应链风险后的响应

  1. 确认受影响组件、版本和攻击路径；
  2. 查询哪些制品包含该组件；
  3. 查询这些制品部署在哪些环境；
  4. 判断是否存在已利用迹象；
  5. 隔离或阻止受影响版本继续发布；
  6. 选择升级、配置缓解、下线或访问限制；
  7. 重新构建、生成SBOM和来源证明并签名；
  8. 验证生产已不再运行旧摘要；
  9. 轮换可能暴露的凭据；
  10. 复盘为什么没有更早发现或阻止。

十四、成熟度路线

基础阶段

  • 建立生产制品清单和负责人；
  • 锁定依赖，集中制品仓库；
  • 在流水线中执行基础扫描；
  • 禁止共享生产发布凭据。

受控阶段

  • 为主要制品生成SBOM；
  • 保护分支、标签和发布流程；
  • CI插件和基础镜像固定不可变版本；
  • 建立漏洞例外和修复时限。

可验证阶段

  • 生成来源证明并签名；
  • 部署端强制验证签名、来源和策略；
  • SBOM与运行资产联动；
  • 定期演练依赖污染和签名泄露事件。

十五、常见误区

  • 生成SBOM就等于供应链安全；
  • 扫描没有高危漏洞就可以信任制品；
  • 只保护源代码仓库，不保护CI和制品库；
  • 使用签名却没有验证；
  • 长期签名私钥保存在流水线变量中；
  • 漏洞数量越少，风险就一定越低；
  • 所有高危CVE都立即无测试升级；
  • 为赶紧急发布永久绕过安全门禁。

十六、检查清单

  • [ ] 知道所有进入生产的仓库、制品和负责人；
  • [ ] 依赖、基础镜像和CI插件有版本锁定；
  • [ ] 构建由受控环境执行；
  • [ ] 主要制品生成并保存SBOM；
  • [ ] SBOM与制品摘要和部署记录关联；
  • [ ] 制品仓库有权限、保留和不可变策略；
  • [ ] 签名身份受到保护，部署端执行验证；
  • [ ] 漏洞例外有证据、负责人和到期时间；
  • [ ] 可以在高危漏洞出现后快速定位所有运行实例；
  • [ ] 定期演练供应链事件和凭据吊销。

十七、示例：高危依赖漏洞出现后的定位

安全团队收到某日志组件高危漏洞通报。传统做法是向所有团队群发通知，让负责人自行查找，几天后仍无法确认影响范围。建立供应链数据后，团队先用组件标识和版本范围查询SBOM，得到23个可能受影响制品；再通过制品摘要与部署清单关联，确认其中8个正在生产运行。

随后结合配置、可达路径和运行参数评估实际风险：3个服务未启用相关功能，记录VEX结论和证据；5个服务需要升级。制品仓库阻止旧摘要继续发布，流水线升级依赖后重新执行测试、生成SBOM和来源证明并签名。部署平台只允许通过验证的新摘要进入生产，最后扫描运行环境，确认旧制品已经退出。

演练还暴露两个问题：一个历史服务没有负责人，一个离线供应商制品没有SBOM。整改不只是“升级依赖”，还包括补所有权、完善采购要求和建立无法获得SBOM时的替代风险评估。这样下一次漏洞出现时，组织可以在小时级回答“是否受影响”，而不是靠人工逐台搜索。

十八、参考资料

软件供应链安全不是增加一次扫描，而是让每个生产制品都有清晰身份、组成、来源和验证路径，并能在风险出现时迅速回答“我们是否受影响”。

Copyright © yan-jian.com 2023 - 2026 · Powered by GitBook更新时间： 2026-10-18 18:03:14

results matching ""

    No results matching ""