本文定位：面向正在建设 DevSecOps、镜像安全和发布准入能力的平台、安全与研发团队，重点解释概念、风险边界和可落地治理路径。
软件供应链安全不是只在代码仓库里加一个漏洞扫描工具，也不是只在镜像推送前跑一次安全检查。它关注的是软件从源代码、开源依赖、构建环境、流水线、制品仓库到部署运行的完整链路中，是否存在被篡改、被污染、无法追溯或无法验证的风险。对云原生团队来说，真正的挑战在于制品形态越来越多，构建链路越来越自动化，攻击者也可能从依赖、构建脚本、镜像层、CI 凭据、仓库权限等薄弱点进入交付流程。
如果把软件交付看成一条流水线，传统安全更像是在几个固定节点做检查；软件供应链安全则要求每个关键节点都留下可追溯证据，并在进入下一环节前能够被自动验证。只有当团队能回答“这个制品从哪里来、由谁构建、包含哪些组件、有没有被签名、部署前是否通过策略校验”这些问题时，制品可信才有基础。
图1：软件供应链风险在代码、构建、制品和部署链路中的分布
先说结论：软件供应链安全的核心是让制品来源可追溯、内容可解释、发布可验证
很多团队一开始会把软件供应链安全理解成“扫描依赖漏洞”。依赖漏洞确实重要，但它只是其中一部分。更完整的目标可以拆成三句话：
- 来源可追溯：知道代码、依赖、构建任务和制品版本来自哪里。
- 内容可解释：知道制品里包含哪些组件、库、基础镜像和许可证信息。
- 发布可验证：在部署前验证签名、来源证明、策略结果和准入规则。
这三个目标分别对应 SBOM、签名校验、构建溯源、制品仓库治理和准入控制等能力。它们不是彼此替代，而是共同构成制品可信机制。
从落地顺序看，不建议团队一开始就追求复杂框架。更稳妥的做法是先梳理关键系统的构建与发布路径，再把高价值制品纳入统一仓库、版本、SBOM 和签名治理，最后通过策略引擎把“必须满足哪些条件才能部署”固定下来。
软件供应链安全到底在防什么
软件供应链风险的特点是入口分散、影响链路长、发现时间晚。一次风险不一定来自业务代码本身，也可能来自构建环境、依赖源、发布凭据或制品仓库权限。
常见风险包括：
- 开源依赖风险：直接依赖或传递依赖存在漏洞、恶意包、混淆包或许可证问题。
- 构建环境风险：CI Runner、构建镜像、脚本和凭据管理不当，导致构建过程被污染。
- 制品篡改风险：镜像、二进制包或 Helm Chart 在生成后被替换，但部署端无法识别。
- 仓库权限风险：制品仓库缺少细粒度权限、审计和不可变标签控制。
- 部署准入风险：Kubernetes 环境只按镜像地址拉取，不验证签名、来源或策略结果。
这些风险和 容器镜像安全 有交集，但范围更大。镜像安全更关注镜像内容和漏洞，供应链安全还会继续向前覆盖源代码、依赖和构建，向后覆盖签名验证、准入控制和发布审计。
SBOM 是什么：它不是漏洞清单，而是制品成分清单
SBOM（Software Bill of Materials，软件物料清单）可以理解为软件制品的“成分表”。它记录一个制品包含哪些组件、组件版本、来源、许可证以及相关标识信息。常见格式包括 SPDX 和 CycloneDX。
SBOM 的价值不在于“生成一份文件”本身，而在于让团队具备快速回答问题的能力：
- 某个高危组件是否存在于我们的制品中？
- 这个组件是直接依赖还是传递依赖？
- 哪些镜像、服务或环境受影响？
- 该制品是否可以追溯到具体构建任务和代码版本？
没有 SBOM 时，安全团队往往只能靠镜像扫描或人工排查。遇到高危漏洞披露时，排查范围大、响应慢，还容易遗漏间接依赖。引入 SBOM 后，团队可以把组件清单纳入制品元数据，结合漏洞库、制品仓库和部署清单做影响面分析。
但也要注意，SBOM 不是万能工具。它不能自动证明制品没有被篡改，也不能替代签名校验和准入策略。更准确地说，SBOM 解决的是“里面有什么”，签名和来源证明解决的是“它是否来自可信构建过程”。
签名校验解决什么问题：防止制品被替换或伪造
在云原生环境中，应用通常以容器镜像、Chart、Operator Bundle 或二进制包的形式流转。只要部署端只信任镜像地址，而不验证制品本身，就会出现一个问题：同一个标签背后是否仍然是原来的内容，部署系统并不知道。
签名校验的核心思路是：
- 构建完成后，对制品摘要进行签名。
- 签名信息与制品一起保存或关联到仓库。
- 部署或准入阶段验证签名、证书、身份和策略。
- 只有验证通过的制品才能进入目标环境。
图2：制品从构建完成到部署准入的签名、验证和策略校验流程
对平台团队而言，签名校验的重点不是“有没有签名文件”，而是验证链条是否完整。签名主体是谁、证书如何管理、是否绑定构建身份、策略是否覆盖生产环境、失败时是否阻断部署，都会影响实际效果。
Sigstore 生态中的 Cosign、Fulcio、Rekor 等组件提供了面向云原生制品签名和透明日志的实践方向。企业落地时可以根据安全要求选择密钥托管、无密钥签名、私有证书体系或混合方式，但原则上要避免把签名私钥随意放在流水线变量里长期暴露。
SLSA 给团队提供了怎样的治理框架
SLSA（Supply-chain Levels for Software Artifacts）更像是一套软件制品供应链完整性框架。它把构建平台、来源证明、构建隔离、审计能力和防篡改要求分层描述，帮助团队判断当前供应链安全能力处在什么阶段。
对普通企业团队来说，不必一开始就把 SLSA 当成一次性达标任务。更合理的方式是把它当作路线图：
- 先确保构建过程可重复、可追踪。包括代码版本、构建任务、构建环境和输出制品能对应起来。
- 再生成并保存来源证明。让制品能关联到构建系统、参数、提交和触发者。
- 逐步提升构建环境隔离。避免不同项目、不同权限、不同信任级别的构建任务互相污染。
- 最后把验证结果接入发布准入。没有验证就不能进入关键环境。
这条路径和 云原生运行时安全 的运行阶段治理不同。运行时安全关注上线后的行为异常，SLSA 与供应链安全更多关注上线前和部署入口前的制品可信。
一套可落地的软件供应链安全机制应包含哪些能力
从平台建设角度看，软件供应链安全可以按“发现、生成、保护、验证、响应”五类能力组织。
| 能力层 | 关注问题 | 常见做法 | 落地重点 |
|---|---|---|---|
| 依赖治理 | 引入了什么组件 | 依赖扫描、版本锁定、私有源治理 | 避免无来源、无维护、无版本约束的依赖 |
| SBOM 管理 | 制品包含什么 | 生成 SPDX/CycloneDX 清单，关联制品版本 | 与漏洞响应和资产清单联动 |
| 构建溯源 | 谁在何处构建 | 构建日志、来源证明、构建身份绑定 | 避免不可追踪的手工构建 |
| 签名校验 | 制品是否被替换 | 镜像签名、摘要固定、透明日志 | 在部署前做强制验证 |
| 准入策略 | 什么能上线 | Policy-as-Code、准入控制、例外审批 | 策略要能阻断高风险制品 |
这些能力要按依赖关系推进
表格里的能力不要求一次建设完成，但顺序不能完全颠倒。如果没有统一制品仓库和版本规范，SBOM 与签名很难稳定关联；如果部署端没有准入控制，签名结果也可能只停留在审计报告里。
PACE 落地：从原则、动作、检查点到例外管理
供应链安全容易变成“大而全”的专项，最后落不到研发流程。用 PACE 思路拆解，会更适合工程团队推进。
原则：把信任前移到构建证据，而不是上线口头确认
核心原则是减少不可验证的人工信任。上线前不是问“这个镜像应该没问题吧”，而是检查制品是否满足清晰条件：来自受控流水线、具备 SBOM、通过扫描、完成签名、摘要未变化、符合环境准入策略。
动作：先覆盖关键应用，再扩展到全部制品类型
推荐动作顺序如下：
- 盘点关键应用、核心镜像和生产发布路径。
- 统一镜像仓库、命名、标签和不可变策略。
- 在 CI 中生成 SBOM，并作为制品元数据保存。
- 对镜像摘要签名，避免只依赖可变 tag。
- 在部署入口验证签名、SBOM、扫描结果和来源证明。
- 对例外发布建立审批、时效和复盘机制。
这一顺序的好处是先把高风险、高价值制品纳入闭环，再逐步扩大覆盖面，而不是从全量仓库开始做形式化扫描。
检查点：用可观测指标判断机制是否真的生效
上线前至少检查：
- 生产镜像是否全部来自受控仓库。
- 关键镜像是否有 SBOM、签名和构建记录。
- 部署是否固定镜像摘要，而不是只写 `latest` 或浮动 tag。
- 准入策略是否能阻断无签名、无扫描或来源不明的制品。
- 例外发布是否有过期时间和负责人。
这些检查点比“是否购买了供应链安全工具”更重要，因为它们直接反映流程是否可验证。
例外：不要让临时放行变成长期后门
任何安全机制都会遇到紧急修复、遗留系统、第三方闭源制品等例外场景。例外不是问题，问题是例外没有边界。建议把例外做成有时效、有负责人、有理由、有后续补偿措施的流程，并定期清理长期放行项。
哪些团队应该优先建设软件供应链安全
并不是所有团队都需要立刻建设完整 SLSA 级别能力，但以下场景应优先推进：
- 生产环境大量使用容器镜像和自动化流水线。
- 开源依赖占比高，且业务对漏洞响应时间敏感。
- 多团队共享制品仓库、CI Runner 或发布平台。
- 已经在推进 DevSecOps、零信任或合规审计。
- 需要证明关键制品来源、构建过程和发布记录。
如果团队还处在手工打包、手工上传、环境不统一的阶段，第一步不是追求复杂签名体系，而是先把交付链路标准化。可先参考 CI和CD有什么区别 中的交付边界理解，把构建、制品、发布职责拆清楚。
成熟度路线：从能看见到能阻断
软件供应链安全的成熟度可以分为四个阶段。
图3：软件供应链安全从资产可见、证据生成到强制准入的成熟度路线
阶段一：资产可见。团队知道有哪些仓库、依赖、镜像、流水线和部署环境，避免关键资产游离在治理之外。
阶段二：证据生成。构建过程可以生成 SBOM、扫描结果、构建记录和签名信息，制品能关联到提交与任务。
阶段三：策略校验。部署前验证制品证据，不满足策略的制品不能进入测试、预发或生产环境。
阶段四：持续治理。漏洞披露、依赖变更、密钥泄露、构建异常和例外放行都能进入持续响应和复盘机制。
这个路线强调的是“从可见到可控”。如果只生成报告但不阻断高风险发布，供应链安全就很容易停留在合规材料层面。
小结
软件供应链安全的关键，不是把每个安全名词都堆进流水线，而是让制品在完整交付链路中可追溯、可解释、可验证。SBOM 让团队知道制品包含什么，签名校验让部署系统能判断制品是否可信，SLSA 提供了逐步提升构建完整性的路线。对云原生团队而言，最可行的落地方式是先治理关键制品和生产发布路径，再把 SBOM、签名、来源证明和准入策略连成闭环。
常见问题
软件供应链安全和 DevSecOps 是什么关系？
DevSecOps 是组织把安全能力嵌入研发流程的整体方法，软件供应链安全更像其中一条专门面向交付链路的治理主线。它不只关心代码里有没有漏洞，还关心依赖从哪里来、构建环境是否可信、制品是否被替换、部署入口有没有验证。落地时可以把它放进 DevSecOps 体系：代码扫描负责发现源码风险，镜像扫描负责发现制品内容风险，SBOM 和签名负责提供制品证据，准入策略负责把证据变成上线约束。
有了 SBOM 是否就说明制品安全？
不能这样理解。SBOM 解决的是“这个制品里有什么”，它能帮助团队在漏洞披露、许可证审计或依赖排查时快速定位影响范围，但它本身不等于安全结论。一个制品可以有 SBOM，同时仍然包含高危组件；也可能 SBOM 是构建前生成的，最终制品后来又被替换。更可靠的做法是把 SBOM 与漏洞扫描、构建来源证明、镜像摘要、签名校验和部署准入放在同一条链路里使用。
签名校验应该放在 CI 阶段还是部署阶段？
签名通常发生在构建完成、制品摘要确定之后；校验则应尽量靠近部署入口，尤其是生产环境入口。CI 阶段可以检查制品是否生成了签名、SBOM 和扫描结果，但真正能阻止风险进入环境的是部署或准入阶段的强制验证。换句话说，CI 里的检查更偏“生成证据和提前发现问题”，部署入口的校验更偏“执行规则并阻断不可信制品”。
小团队有没有必要做软件供应链安全？
有必要，但不一定要一开始就上完整 SLSA 或复杂签名体系。小团队更实际的起点是把交付链路先标准化：固定依赖源和基础镜像，避免随意使用 `latest`，让镜像从受控流水线构建并进入统一仓库，保留构建记录和版本关系。等这些基础稳定后，再逐步加入 SBOM、镜像签名和部署准入。这样做的价值不是“显得安全”，而是在出现漏洞、凭据泄露或制品异常时能快速判断影响范围并恢复。
