开源项目安全响应流程如何区分修复、披露和下游通知节点

开源项目收到安全报告后，最容易混淆的是把“修复了”“已经披露”和“用户已被通知”当成同一件事。更稳妥的做法是把流程拆成三个节点：修复是产出可测试、可分发的代码或缓解方案；披露是公开影响范围、受影响版本、修复版本和处理结论；下游通知是让发行版、镜像维护者、云服务商和直接用户知道自己需要采取什么行动。三个节点可以在同一天完成，但完成条件不同。

官方参考入口：https://oss-vulnerability-guide.openssf.org/maintainer-guide.html；https://docs.github.com/en/code-security/concepts/vulnerability-reporting-and-management/repository-security-advisories

先把三个节点拆开：修复、披露、通知

修复回答的是“项目能交付什么”。它可能是补丁、修复版本、配置缓解或暂时关闭某项能力，关键是用户能拿到并验证。披露回答的是“外部世界需要知道什么”，至少应说明受影响版本、影响类型、修复版本或缓解方案，以及如何判断自己是否受影响。通知回答的是“谁需要现在行动”，对象不只包括仓库关注者，还可能包括发行版打包者、容器镜像维护者、插件生态和托管服务商。

OpenSSF 的协调披露指南把私下报告、评估、修复和向下游同步看成一个协作过程；GitHub 的 Repository Security Advisories 也把私下讨论、修复、验证和发布公告分开。这样划分的好处是，负责人可以逐项打勾，而不是用一个“已处理”状态掩盖仍未完成的通知工作。

用四个问题判断修复节点是否真的完成

维护者可以先检查四个结果：第一，是否明确了受影响的组件和版本；第二，修复是否有回归测试或其他验证证据；第三，是否已经生成用户能够获取的版本、补丁或缓解说明；第四，依赖项目能否在不猜测内部提交的情况下采用它。若只是“修复已合并”，但尚未打包、发布或写出升级路径，应该把状态记为“修复准备完成”，不要直接宣布“用户已安全”。

response_record:
  # 用固定字段把修复交付和公开沟通分开
  affected_versions: ["1.x", "2.0.x"]
  fixed_versions: ["1.8.4", "2.0.3"]
  mitigation: "暂时关闭外部输入路径，等待升级"
  regression_test: "覆盖边界输入和旧版兼容路径"
  distribution_channels: ["release", "package", "container"]
  disclosure_status: "draft"
  downstream_status: "contacted"

上面的字段不是某个厂商的固定格式，而是一份内部检查骨架。`fixed_versions` 为空时，不要把代码仓库里的提交号当成用户可用版本；`distribution_channels` 也能提醒团队检查包管理器、镜像和发行版是否需要单独动作。

披露和下游通知什么时候分开做

披露并不等于把完整技术细节立即贴到公共 Issue。协调披露通常先在私下渠道完成确认和修复准备，再公开一份足够让用户判断风险的公告。下游通知则更偏向行动清单：哪个组件受影响、哪个版本可升级、是否需要重建镜像、是否存在临时缓解，以及谁负责回复问题。

可以建立一份“下游对象—动作—确认人”表。发行版维护者关注补丁和构建时间，镜像维护者关注基础镜像与标签，云服务商关注托管版本和客户公告，直接用户关注升级命令与配置影响。通知内容应从同一份事实记录派生，不能让每个团队各自改写影响范围。

按影响范围选择响应模式

普通问题适合协调披露：私下接收、评估、修复、通知关键下游，再在补丁可用时公开。影响面较宽但没有统一发布窗口时，可以采用分阶段披露，先通知承担构建和分发职责的下游，再逐步扩大公开范围。若已经观察到广泛影响或现有信息会让用户立即暴露，则需要紧急带外响应，先给出清晰的临时缓解和受影响边界，之后再补齐完整修复与公开记录。

选择模式时不要只看漏洞严重程度，还要看生态的分发链长度、是否有可行缓解、下游是否能在同一窗口完成升级，以及公开细节会不会改变用户风险。对小型项目，最重要的不是制作复杂流程图，而是把安全联系人、接收渠道、状态更新频率和最终公告模板写进仓库的安全政策。

发布前的最小检查清单

在对外发布前，可以让维护者、发布负责人和下游联络人分别确认：报告是否已脱敏；受影响和不受影响的版本是否写清；修复版本是否能被下载或构建；临时缓解是否会造成兼容性变化；下游名单是否覆盖实际分发链；公告中的时间、版本和链接是否来自同一份记录。完成这些检查后，再决定是同步公开，还是保留一个短暂的分阶段窗口。

相关问题

修复提交已经合并，能否马上公开披露？

只有在用户能获得修复或明确缓解，并且关键下游有机会准备时才适合公开。提交合并只是研发状态，不代表发布包、镜像和发行版都可用。

下游通知是不是公开公告的重复工作？

不是。公告面向可查询的公共记录，下游通知面向具体分发链和行动责任人，内容可以共用事实，但消息对象和确认方式不同。

没有发现安全影响时还要走披露流程吗？

应记录评估结论并向报告人说明理由。把普通缺陷、设计取舍和安全漏洞区分开，能避免不必要的公开升级，也能留下后续复核依据。

小型开源项目没有专职安全团队怎么办？

先公开安全联系方式和处理边界，使用固定的私下报告模板、版本字段和公告模板；需要时邀请发行版、基金会或安全响应组织共同协调。