CNCF 于2026年9月7日发布了一份题为《处理漏洞报告：配方卡》（Handling vulnerability reports: Recipe card）的指南卡，面向主要不专注于安全的小型和中型开源项目。该材料由Edera的Marina Moore与Red Hat的Sherine Khoury共同编写；Marina Moore 是TAG Security的联合主席，Sherine Khoury 是TAG Security的负责人。
该指南的核心理念是减少维护者和用户的额外工作，同时避免安全报告在修复准备就绪之前变成公开讨论。CNCF 说明，安全漏洞是可被利用、进而影响系统机密性、完整性或可用性的缺陷，但并非所有软件缺陷都可被利用，也并非都被归类为漏洞。
从明确且私密的报告渠道开始
指南建议在README.md中设置清晰且易于找到的安全部分，将说明直接写入该文件，或指向代码库根目录中的SECURITY.md文件。目标是引导研究人员使用私密渠道，而不是在所有人都能阅读的公开 issue 中发布问题细节。
报告说明应明确多个要素，包括威胁模型，或将报告视为漏洞所需满足的最低条件；提交位置；报告格式；预计审查时间；以及大致的披露时间。可以使用 GitHub 的私密漏洞报告机制或私有邮件列表。如果中小型项目没有运营漏洞奖励计划的能力，则不必设置该计划。
在按漏洞处理之前确认报告的性质
收到报告后，首先应确定它是否确实指向一个可被利用的漏洞，还是不可利用的缺陷、对预期行为的误解，或文档错误。CNCF 建议与报告提交者以及项目中的相关专家讨论报告，同时限制参与人数，并要求所有人在报告公开之前遵守保密规定。
可以提出的实际问题包括：用户是否有可用的缓解措施？该缺陷是否可能导致入侵、数据泄露或其他恶意活动？问题是否仅存在于文档中？如果确认报告不是漏洞，可以引导提交者创建公开 issue，并在需要时使用适当的发布流程通知用户。
如果存在不确定性，指南指出可以向TAG Security and Compliance或 CNCF 工作人员寻求指导，同时不得将报告细节带入公开渠道。此外，应谨慎选择保密期内的参与者，只让确实需要参与解决的人加入，以免在提供修复之前信息泄露给攻击者。
在非公开环境中开发并测试修复
CNCF 警告，在公开 pull request 中发布或讨论补丁，可能会在用户有机会更新之前暴露漏洞的性质。如果使用 GitHub 的私密报告机制，可以从报告创建私有分支。否则，可以通过私有渠道开发和审查修复。
必须测试修复，即使常规持续集成环境无法处理私有分支。在这种情况下，可以根据维护者的判断和变更范围在本地执行测试。在确认补丁能够解决问题且测试充分后，指南建议迅速合并，并让足够数量的维护者参与其创建和测试。在公开发布之前，应再次审查代码，并确认漏洞确实已经被修复。
协调发布与 CVE 披露
修复完成后，CNCF 认为在收到报告后90天内披露漏洞是一种常见做法。如果项目资源允许，可以提前通知一个私有用户名单，但维护一份最新的联系人名单是大多数小型项目难以承担的负担。
因此，该卡片提出了一种更简单的方法：同时提供包含修复的版本并公布漏洞，使用户能够在问题公布时获得修复。这要求在修复合并后立即构建新版本，然后发布CVE。如果使用 GitHub 的私密机制，则可以通过 GitHub 界面完成这一流程。
CVE 编号必须由CNA，即 CVE 编号机构分配。GitHub 是这些机构之一，可以执行该流程；项目和研究人员也可以直接联系列出的某个 CNA。CVE 的严重性等级通过一组问题确定，项目应与研究人员合作，确保答案准确，并就分配的等级达成一致。
为什么这些指南很重要？
从实际角度看，该卡片将漏洞管理责任从随机应对转变为一条可执行的流程：私密渠道、有限验证、非公开修复，然后是协调发布与披露。CVE 发布后，相关信息会出现在OSV和其他漏洞数据库中，从而帮助用户的扫描工具发现需要更新。
但该配方的适用范围十分明确：它面向非安全专业的中小型项目，并不能替代高风险或安全敏感项目所需的更复杂计划。CNCF 还建议考虑在修复可用一段时间后发布概念验证，为用户提供额外的更新机会，同时承认在使用私密报告机制时实施这一做法可能较为困难。