Software Supply Chain / SBOM

软件供应链与SBOM治理

SBOM的价值不是生成一份清单, 而是让组件来源、影响范围和处置责任在需要时立即可用。

2026年7月22日阅读约6分钟
供应链治理应覆盖源码、依赖、构建环境、制品和交付过程。SBOM是连接这些环节的基础数据, 但必须保持准确、可关联和持续更新。

在构建过程中生成准确SBOM

仅扫描源码可能遗漏构建时下载、基础镜像和最终制品中的组件。更可靠的做法是在持续集成中生成清单, 并对最终镜像或安装包再次分析。组件记录应包含名称、版本、来源、许可证、哈希和依赖关系, 关联到具体产品与发布版本。

对于无法识别或版本不确定的组件, 不应静默忽略, 而要作为质量问题处理。清单本身也可能暴露技术栈信息, 因此对外提供时需按合同和用途控制访问。

从依赖入口控制来源与变更

组织应使用受控制品仓库代理外部依赖, 保留下载来源和完整性信息。锁定直接与间接依赖版本, 对新增组件执行许可证、维护状态和安全风险检查。包名相似、来源异常或维护停滞都应触发人工复核。

构建环境采用最小权限和短期凭据, 将源码读取、依赖下载、签名和发布权限分离。关键流水线配置和构建工具同样需要版本控制与评审。

让漏洞情报快速映射到在用产品

漏洞公告出现后, 团队需要回答组件是否存在、是否处于受影响配置、部署在哪些环境以及谁负责修复。SBOM应与资产、漏洞、工单和发布系统关联, 以实际可达性和业务影响确定优先级, 避免只按通用评分机械处置。

暂时无法升级时, 应记录补偿控制、接受人、到期时间和复查条件。修复完成后不仅更新依赖, 还要验证制品中旧版本确已消失。

验证构建来源与制品完整性

发布制品应经过签名, 部署环境验证签名、来源和允许策略。构建证明记录使用的源码版本、构建流程和关键材料, 帮助识别绕过流水线或被篡改的产物。签名密钥需要隔离、轮换和审计。

治理指标可以包括SBOM覆盖率、未知组件数量、高风险依赖响应时间、非受控来源阻断次数和签名验证覆盖率, 并定期用真实漏洞演练影响分析流程。

治理检查SBOM对应最终交付制品; 依赖通过受控入口获取; 漏洞能够映射到产品负责人; 例外有到期时间; 发布制品具备来源证明与完整性验证。