CNCF 开源项目漏洞处理配方卡：SECURITY.md、embargo 与 CVE 披露
CNCF TAG Security 发布了一份"配方卡"（recipe card），专门面向中小型、非安全专业的开源项目维护者，讲清楚收到漏洞报告后怎么处理。核心三步：设好上报通道（Set the Station）→ 先鉴别是不是真漏洞（Taste Test First）→ 补丁与 CVE 披露协同发布（Plate for Everyone）。
适用范围与边界
面向中小型、非安全聚焦项目；高风险的 security-sensitive 项目需要更复杂的方案。不覆盖：依赖漏洞、编码最佳实践（怎么避免漏洞）。
第一步：准备好接收漏洞（备好厨房）
维护者不希望漏洞通过公开 issue 报上来。在仓库 README.md 直接放安全区块（或指向根目录的 SECURITY.md），让上报路径显眼易找。上报说明应包含：
- 威胁模型 / 可接受的漏洞下限：什么算漏洞、什么不算；
- 上报渠道：GitHub 私有漏洞上报（Private vulnerability reporting）或私有邮件列表；
- 格式要求；
- 时间线：多久内会看、多久内披露；
- 赏金政策：中小项目没有赏金也完全可以。
第二步：收到报告后先鉴别（试味）
在保密范围内回应：embargo（禁运）——只有必要维护者知道并协同处理。第一件事是判断它到底是不是漏洞：不可利用的 bug、对项目预期行为的误解，都不是漏洞。决定时与上报者及相关专家讨论，尽量少人参与，所有人同意在公开前保密。判定非漏洞的，引导上报者转公开 issue。
拿不准时可以找 TAG Security and Compliance 或 CNCF staff 私下咨询，别把报告内容发到公开频道。判断辅助问题：用户有缓解手段吗？这个 bug 能导致入侵、数据泄露或恶意活动吗？是文档错误吗？
embargo 管理要克制：只让解决问题必需的人知道，确保每个人明白漏洞尚未公开、需保密。embargo 保证攻击者在补丁前接触不到漏洞。
第三步：修复与披露（烹饪与上菜）
修复：补丁在公开前保持私有——用 GitHub 漏洞上报机制建私有分支，或走私有频道开发评审；测试补丁（私有分支可能跑不了现有 CI，尽量本地测）；确认修复后快速合并（尤其没用私有分支时），并和披露流程协调，让补丁与漏洞公告同时公开；公开前再检查一次代码，重新跑"试味"确认漏洞真的修了。
披露：补丁公开时同步发布 CVE 披露，让用户知道风险并尽快升级。披露内容应包含：漏洞是什么、影响哪些版本、修复版本、缓解措施。协调得当的披露让用户先升级后曝光，而不是裸奔在公开漏洞信息里。
实践建议
中小项目最低配置三件套：根目录 SECURITY.md（含上报渠道与时间线）、私有上报渠道（GitHub 私有漏洞报告即可）、一条"先鉴别后修"的 SOP。披露时宁可晚一天也要和补丁同步，避免"公告发出、补丁未合"的空窗期。