企业级供应链安全路线图 2026
软件供应链安全专题 · EP.06 · 2026-09-04
上海见形信息科技有限公司 · 灵御（Aegis）安全实验室
16 项供应链安全工作
供应链治理需要连接代码来源、依赖、构建、发布、运行和更新。组件清单、扫描结果、签名与来源声明都应能够关联到具体制品及生产部署。
| 工作类别 | 代码源与依赖 | 构建与发布 | 运行与更新 | 评估与治理 |
|---|---|---|---|---|
| 战略与治理 | 攻击点全景 B1-01 | SLSA 等级目标 B3-01 | 运行漂移治理 B1-02 | 组件准入治理 B5-01 |
| 架构与设计 | 依赖图健康 B1-03 | 构建链路设计 B4-01 | OTA 通道设计 B1-04 | 评估框架 B5-02 |
| 工程与运营 | 依赖投毒检测 B1-05 | SBOM 自动生成 B2-01 | 运行时 SBOM B2-02 | 发布检查设计 B5-03 |
| 审计与追踪 | 来源追踪 B1-06 | Provenance 验证 B3-02 | 更新通道审计 B1-07 | 持续评估 B5-04 |
组件评估覆盖来源可信度、维护活跃度与依赖关系带来的影响。需要保留评估依据、版本、例外审批和复查时间，便于在上游事件发生时更新判断。
CMM-SC 五级内部评估模型
CMM-SC 是本文用于组织企业自查的内部评估模型。各等级描述工程能力与证据，具体 SLSA Build 等级仍依据对应规范独立检查。
| 等级 | 能力状态 | 可验证证据 |
|---|---|---|
| L1 初始级 | 依赖和制品清单不完整 | 当前发布流程、关键制品与责任人记录 |
| L2 感知级 | 能识别组件、版本和来源 | 依赖清单、来源记录与基础 SBOM |
| L3 工具级 | SBOM 自动生成，SCA 与依赖审查进入流程 | 覆盖率、扫描结果、处置与复查记录 |
| L4 整合级 | 签名、Provenance 与部署检查相互连接 | 制品摘要、身份、来源声明与验签结果 |
| L5 韧性级 | 构建隔离、持续验证和事件响应形成制度 | 隔离证明、事件演练、重建与恢复记录 |
等级检查应考虑内容完整性、自动化覆盖范围与实际执行情况。仅有源代码依赖清单时，还需要检查编译结果、容器层和运行时实际加载的组件。
四类企业的年度安排
缺少 SBOM 基础的企业
| 时间 | 建设工作 | 交付内容 |
|---|---|---|
| Q1 | 盘点上线制品及其直接、间接依赖 | 制品、依赖、版本与责任人清单 |
| Q2 | 确定 CycloneDX、SPDX 等交换格式 | 数据字段、生成与消费要求 |
| Q3 | 在 CI 接入 Syft、cdxgen 等生成工具 | 构建 SBOM 与覆盖范围报告 |
| Q4 | 补充制品分析和关键元数据，检查清单与制品是否一致 | 制品摘要、许可证、工具与生成上下文记录 |
已开展 SBOM 试点的企业
| 时间 | 建设工作 | 交付内容 |
|---|---|---|
| Q1 | 关联源代码、发布镜像和运行组件 | 多阶段 SBOM 与制品对应关系 |
| Q2 | 将 SCA 和异常依赖审查接入关键流水线 | 告警阈值、责任分配与处理记录 |
| Q3 | 评估 SAST、SCA、SBOM、签名、Provenance 和构建隔离 | 能力清单与差距记录 |
| Q4 | 为关键制品启用签名与验证策略 | 签名、允许的身份与部署校验记录 |
SBOM 已规模化运行的企业
| 时间 | 建设工作 | 交付内容 |
|---|---|---|
| Q1 | 为容器镜像、二进制和 SDK 建立签名管理 | 关键制品签名与身份策略 |
| Q2 | 在部署端执行签名与来源检查 | 准入策略和失败告警 |
| Q3 | 接入 slsa-github-generator、Tekton Chains 等来源声明工具 | Provenance、构建服务与 commit 关联记录 |
| Q4 | 建立第三方组件风险评估和例外管理 | 准入条件、复查周期与审批记录 |
关键基础设施与产品厂商
| 时间 | 建设工作 | 交付内容 |
|---|---|---|
| Q1 | 按目标 SLSA 要求检查构建平台隔离与证明生成机制 | 平台能力评估与整改证据 |
| Q2 | 根据业务需要接入远程证明与 in-toto 声明验证 | 证明格式、身份策略与验证结果 |
| Q3 | 完善一次性 Runner、防篡改保存与缓存隔离 | 构建环境记录与审计证据 |
| Q4 | 演练依赖事件响应、停止部署、凭证撤销与客户通知 | 响应 SOP、重建记录与通知流程 |
TEE、透明日志和 WORM 存储分别提供执行环境、公开可查记录和保存方面的保证。设计时应逐项说明所依赖的保证以及验证方式。
SBOM 的生成、校验与使用
SBOM 字段应覆盖组件身份、版本、供应者、依赖关系、许可证、摘要、生成工具和生成上下文，并按适用规范补充作者与签名信息。企业需要保留生成时间、工具版本和分析对象。
源代码分析与制品分析应互相核对。制品中可能含有预编译库、系统软件、镜像层与安装后加入的组件，运行环境还可能出现动态加载或人工安装带来的变化。
漏洞事件发生后，应能从组件版本查询受影响制品，再查询对应构建与部署位置。组件清单、VEX 或其他适用性判断需要保留证据和更新记录。
发布与事件处理
发布策略应检查制品摘要、允许的签名身份、构建服务、源代码版本与风险处置状态。验证失败时停止发布，并把原因通知责任人。
供应链事件处理流程应覆盖：确认影响范围、阻止受影响版本进入新构建、隔离构建任务、撤销相关凭证、使用经过核验的输入重新构建、验证新制品、通知下游。各动作需要有执行记录与恢复条件。
五项后续研究
| 编号 | 研究问题 | 研究方向 |
|---|---|---|
| AI-SC-01 | 跨生态攻击 | npm、PyPI、Cargo、Maven 之间的传播与检测 |
| AI-SC-02 | post-build SBOM 自动化 | 编译产物、容器层与运行组件的生成和核验 |
| AI-SC-03 | 高等级构建保证自动化 | 隔离、来源证明和远程证明与 CI/CD 的连接 |
| AI-SC-04 | AI 时代的供应链风险 | 仿冒仓库、生成式依赖推荐和恶意组件识别 |
| AI-SC-05 | 组件评估标准化 | 跨组织交换的风险证据、评估结果与更新机制 |