事件响应

​

1. 检测和分流

安全信号来源包括：

• GitHub 安全公告（GHSA）和私密漏洞报告。
• 报告不涉及敏感信息时，使用公开的 GitHub issue/讨论。
• 自动化信号：Dependabot、CodeQL、npm 公告、密钥扫描。

初步分流：

1. 确认受影响的组件、版本以及对信任边界的影响。
2. 根据 SECURITY.md 的范围和范围外规则，将其分类为安全问题或加固/无需处理事项。
3. 事件负责人采取相应措施。

​

2. 严重程度

​

3. 响应

1. 向报告者确认已收到报告（涉及敏感信息时私下确认）。
2. 在受支持的发布版本和最新 main 上复现问题，然后实施并验证补丁，同时加入回归测试覆盖。
3. 严重/高：在实际可行的情况下尽快准备修复后的发布版本。
4. 中/低：在正常发布流程中修复，并记录缓解措施指南。

​

4. 沟通和披露

通过受影响仓库中的 GitHub 安全公告、已修复版本的发布说明/变更日志条目，以及直接向报告者跟进状态和解决情况来进行沟通。 严重/高等级事件采用协调披露，并在适当情况下发布 CVE。对于低风险的加固问题，可根据影响和用户暴露程度记录在发布说明或公告中，而不发布 CVE。

​

5. 恢复和后续跟进

发布修复后：

1. 在 CI 和发布工件中验证补救措施。
2. 进行简短的事件后审查：时间线、根本原因、检测缺口、预防计划。
3. 添加后续加固、测试和文档任务，并跟踪至完成。

​

相关内容

• 安全策略 — 报告范围和信任模型。
• 威胁模型