CNCF 项目毕业评审中的供应链治理关注点

CNCF 项目毕业评审中的供应链治理，重点是项目能否解释代码和发布权限由谁控制、交付物怎样形成，以及安全问题由谁接收和跟进。第三方安全评审和徽章是材料的一部分，不能用“已经开启依赖扫描”替代完整的治理说明，也不能把某项供应链工具视作自动毕业条件。

CNCF 官方地址：https://www.cncf.io/

毕业申请模板：https://github.com/cncf/toc/blob/main/.github/ISSUE_TEMPLATE/template-graduation-application.md

本文面向准备申请材料的维护者，以及阅读项目成熟度信息的采用方，解释现行公开模板与供应链最佳实践之间的关系，不是一则新项目毕业公告，也不把历史白皮书包装为刚发布的新要求。

评审关注的是可持续治理，不只是一个安全功能

设想一个开源项目已经定期发布镜像，但只有一位维护者知道发布凭据的位置。即使扫描结果暂时没有高风险提示，团队仍无法清楚回答维护者离任后谁能发布、外部报告交给谁、某个版本对应哪次源码变更。这就是供应链技术与治理需要结合的地方。

CNCF 旧的 graduation_criteria.md 页面目前指向毕业申请模板。准备材料时应从这个明确入口查条目，并记录适用于本次申请的模板版本或提交位置；网络上的旧摘录可以帮助理解历史，不能替代当前申请的依据。

先分清 Required 和 Suggested

当前申请模板的 Security 部分把安全问题报告流程、代码库访问控制、安全响应职责、安全自评、第三方安全评审以及 OpenSSF Best Practices passing badge 列在 Required 下。silver 或 gold badge 则列为 Suggested。维护者应按各条目提供可定位的材料，而不是只写一句“遵循最佳实践”。

例如，报告入口回答外部人员把问题发往哪里；响应职责回答谁负责分诊和升级。两份说明可以互相引用，但邮箱地址本身并不能说明团队如何持续处理报告。第三方评审项还要求跟踪中低级发现及主题性改进；报告存在与整改持续推进是不同层次的材料。

SBOM、构建来源证明、签名和自动化可以支撑风险说明，但不能仅凭这些技术名词就宣称满足全部评审。具体要求应按项目类型、当前模板与评审意见理解，本文不另设“所有项目必须达到某个 SLSA 等级”的通用门槛。

围绕一次发布整理最小材料

CNCF 的供应链最佳实践讨论源码、材料、构建、产物等不同边界，强调明确的信任关系、自动化和受限权限。下面的材料表是据此整理的编辑建议，用于帮助维护者解释项目自己的实现，不是新增官方清单。

例如可以建立一个发布材料索引，将某次发布的版本标记、构建定义位置、产物摘要和责任人对应起来。索引只放适合公开的说明；不公开密钥、恢复码或未协调披露的漏洞细节。项目没有采用某种证明机制时，应如实记录现状与计划，避免用空文件冒充已完成。

旧流程可以分段改进，但要说明缺口

如果发布主要依赖手工操作，维护者可以先公开可重复理解的发布说明，再梳理仓库和发布平台权限，逐步将容易漂移的环节自动化。这里的“先后”是实施建议，不能据此自行宣布某个 Required 条目可以免除。

每个缺口至少记录问题范围、负责角色、计划和后续状态。第三方报告中的发现不应只在表格里勾选为“已查看”，而应能关联处置记录。若采用方关心某个版本，项目层面的成熟度仍要结合该版本的发布与安全信息阅读。

徽章、签名和毕业状态分别说明什么

拿到 passing badge 就能毕业吗？不能。它是申请模板中的一项要求；评审还涵盖治理、工程、安全和采用情况等方面。silver、gold 与 passing 的要求层级也不能混写。

有签名是否说明构建内容没有问题？不能。签名需要结合信任身份与验证规则理解，它无法单独说明依赖安全、发布权限合理或评审发现已经整改。使用者仍要看实际发布的材料及其覆盖范围。

团队最实用的准备动作是什么？把官方条目、项目材料位置和负责角色对应起来，再对照实际操作补缺。对不能公开的细节提供合理的处理说明，避免用泛化的安全口号代替可讨论的事实。

资料：CNCF 毕业尽职调查模板；软件供应链最佳实践。正式申请仍应使用 TOC 当前发布的模板与流程。