CNCF 公告中的供应链安全能力怎样落到工程团队

很多团队第一次遇到供应链问题时，看到的是一个很具体的症状：镜像已经进入仓库，部署却无法回答“它由谁构建、从哪份源码来、依赖是否变化、为什么这次仍然被允许运行”。CNCF 近期公告与官方社区资料传递的重点，并不是再堆一层扫描器，而是把这些答案变成可以验证的证据。

这篇文章按一次发布故障复盘来拆解。它不把 CNCF 的公开资料当成某个团队的合规认证，而是把其中反复出现的能力——SBOM、签名、provenance、策略即代码和运行时核验——翻译成工程团队能执行的发布门禁。

官方资料入口：https://www.cncf.io/announcements/、https://contribute.cncf.io/community/tcgs/software-supply-chain-security/

先看影响面：缺的不是一个扫描结果

如果团队只记录“扫描发现 3 个高危漏洞”，复盘很容易停在依赖升级。真正影响发布可信度的证据至少有四层：

第一个触发条件：制品能运行，但无法证明怎么来的

一次典型故障是：构建成功、镜像推送成功，部署平台也能拉取镜像；后来有人发现依赖树发生变化，团队却只有镜像标签，没有对应的源码提交、构建器身份和生成时间。此时重新扫描只能回答“现在看见什么”，不能回答“发布当时发生了什么”。

CNCF 的供应链安全技术社区把 SBOM、签名验证、provenance、构建隔离、漏洞管理和攻击路径分开列出。这个拆分很有用：SBOM 描述组成，签名保护完整性，provenance 描述构建来源，策略决定是否接受，不能用其中一项冒充全部证据。

SLSA 官方地址：https://slsa.dev/。SLSA 把 provenance 作为上手入口之一，并用逐级保证水平帮助团队安排改进顺序。

根因通常在发布链断点，而不在某个 CVE

复盘时可以把断点固定成四个问题：

1. 来源断点：构建是否只接受受保护分支和可追溯提交，还是允许人工上传源码压缩包。
2. 构建断点：构建器是否隔离，构建定义是否进入审计范围，是否能生成不可随意修改的 provenance。
3. 制品断点：镜像、软件包和 SBOM 是否绑定到 digest，签名是否与可信身份关联。
4. 消费断点：CI、仓库或集群准入是否真的检查证据；如果检查失败，是阻断、告警还是静默放行。

这四问能把“我们有扫描”改成“哪一条证据在什么位置被验证”。CNCF 的供应链最佳实践也强调，制品及其元数据应带有可独立验证的签名，并在消费和部署阶段重新验证。

修复动作：先建最小证据链，再增加门禁

工程团队不必第一天就把所有项目推到最高等级。一个可落地的最小闭环是：构建时生成 SBOM 和 provenance，发布时对制品与元数据签名，部署前按 digest 查询并验证，验证结果写入发布记录。

# 下面是发布链的示意命令，参数名需按团队实际 CI 工具调整
# 先固定制品摘要，避免 tag 被移动后仍被当成同一个版本
IMAGE_DIGEST="registry.example/app@sha256:REPLACE_ME"

# 生成或导出 SBOM，供依赖追踪和漏洞处置使用
generate-sbom "$IMAGE_DIGEST" --output sbom.spdx.json

# 为制品和构建元数据签名；私钥、OIDC 身份和信任根由平台统一管理
sign-artifact "$IMAGE_DIGEST" --sbom sbom.spdx.json --provenance provenance.json

# 发布前验证签名、来源和策略，失败时返回非零状态交给流水线处理
verify-artifact "$IMAGE_DIGEST" --require-provenance --policy policy.yaml

命令里的工具名是接口位置示意，不应直接复制成某个厂商的完整配置。重点是把三个返回值保存下来：制品 digest、签名/证明材料的位置、策略判定及其原因。

把策略写成代码：告警、阻断和例外要分开

CNCF 关于 policy-as-code 的讨论强调，供应链规则应被版本化、自动评估，并在 CI/CD、制品入口、准入控制和审计等位置执行。团队可以先用三档结果降低迁移阻力：

• 阻断：签名缺失、digest 不匹配、来源身份不在允许范围内。
• 告警：SBOM 字段不完整、构建环境尚未达到目标等级，但当前项目仍在试点期。
• 例外：必须绑定责任人、原因、到期时间和补救任务，不能用永久白名单代替策略。

# 策略示意：把证据要求和迁移阶段拆开，避免一次性全部阻断
artifact:
  # 生产环境只接受摘要固定的制品
  require_digest: true
  # 试点阶段先要求签名，来源身份逐步收紧
  require_signature: true
  trusted_issuers:
    - "ci.example.org"
provenance:
  # 没有构建来源证明时先告警，由项目按期限补齐
  missing: warn
exceptions:
  # 例外必须有到期日，过期后自动回到正常判定
  require_owner: true
  require_expiry: true

策略文件本身也要纳入代码评审。否则签名、SBOM 都具备了，真正决定“允许运行”的那条规则却可能由人工在生产环境临时修改。

运行时核验解决什么，解决不了什么

只在 CI 检查还不够：镜像进入仓库后可能被重新标记，某些工作负载也可能绕过常规准入路径。CNCF 2026 年关于 NRI 的供应链核验文章展示了另一层思路：在容器运行时按镜像 digest 检查 SLSA provenance、VEX 和 VSA，并根据命名空间策略决定是否允许创建容器。

这类运行时核验适合做纵深防御，但不能被夸大成“节点已经安全”。官方文章明确指出，它假设节点本身仍然可信；拥有节点 root 权限的攻击者可能停止插件、替换策略文件或关闭 NRI。因此复盘记录要同时写清保护层和未覆盖的威胁模型。

防复发：用一次拒绝记录推动下一轮改进

每次发布被拒或被放行，都建议保留以下字段：制品 digest、源码提交、构建器身份、provenance 地址、SBOM 地址、签名验证结果、策略版本、例外编号、判定时间和执行位置。这样下一次出现依赖异常时，团队能回到具体证据，而不是重新猜测。

落地顺序可以是：先为高价值服务绑定 digest；再在 CI 生成 SBOM 与 provenance；随后在发布入口验证签名；最后把关键命名空间切到阻断，并为遗留项目保留有期限的例外。每一步都要有负责人和退出条件，SLSA 等级只是衡量改进的语言，不是替代风险判断的分数。

Sigstore 官方地址：https://www.sigstore.dev/。CNCF 相关资料把 Sigstore、cosign、in-toto、TUF/Notary 等放在签名、证明、信任委托和更新安全的不同位置，选型时应按证据链缺口决定，而不是把项目名称直接当作方案。

几个容易混淆的问题

有了 SBOM 是否就等于供应链安全？

不是。SBOM 说明组成，但不能证明制品由可信构建器生成，也不能单独证明发布后未被替换；至少还要结合签名、provenance 和消费端验证。

为什么扫描通过，仍然应该拒绝部署？

扫描主要回答已知漏洞或组件风险，无法替代来源身份、构建证明和策略条件。缺少关键证据时，团队无法判断“扫描的正是准备运行的那个制品”。

是不是一开始就应该全量阻断？

通常不建议。先选一类高价值服务建立完整证据链，把缺失项分成告警、阻断和有期限例外，再扩大范围，能减少开发团队绕过门禁的冲动。

结语

CNCF 公开内容真正值得工程团队吸收的，不是某个新闻标题或工具清单，而是把“相信这个制品”拆成可验证的证据关系：它从哪里来、怎样构建、是否被改过、谁批准它进入环境，以及这次判定的边界是什么。把这些证据接入发布链和运行时，供应链安全才会从报告里的名词变成团队每天能复盘的工程事实。