资源 · 41
协调漏洞披露：接收、修复和通知
构建安全的外部报告渠道，评估影响，协调受影响方并发布实用指南。
已更新 · 3 min
本指南有助于实现的目标
- 确保报告的可行性和安全性。
- 为每份报告指定负责人。
- 协调可验证的修复。
- 为用户提供可操作的指导。
快速检查
- 是否可以在没有客户帐户的情况下发送报告？
- 范围和允许的测试是否明确？
- 如果主要联系人不在，由谁负责回复？
- 哪些产品和供应商存在此缺陷？
- 哪些临时缓解措施有效？
- 该建议是否明确指出实际受影响的版本？
分步指南
- 1
发布清晰的策略
说明范围、应避免的测试、联系渠道、有用的报告详情和响应流程。 请根据您的实际情况审核该策略。
交付成果：已发布的策略和监控渠道。
- 2
确认并保护证据
确认收到证据，分配标识符，限制敏感信息的传播，并仅要求提供重现问题所需的证据。
交付成果：注明日期并指定负责人的报告。
- 3
评估并扩大范围
在不损害系统的情况下重现问题。 检查可利用性、资产、版本、数据以及与其他产品或供应商共享的组件。
交付成果：影响评估和利益相关者地图。
- 4
协调补救措施
与报告者和维护者保持定期沟通。 商定验证里程碑，并根据风险或传播方式的变化调整沟通方式。
交付成果：共享时间表、修复和回归测试。
- 5
发布并跟进
说明受影响的版本、修复或缓解措施、用户操作和不确定性。 验证部署情况，并根据实际情况更新建议。
交付成果：版本化建议和分发证据。
虚构示例
示例情境
一位研究人员报告了旧版 API 中的访问控制故障。 团队确认了该故障，并在授权环境中重现了该问题，发现一个共享组件影响了两个产品。
决策及预期证据
该计划将维护者、版本、修复测试和临时缓解措施联系起来。 最终建议为用户提供了明确的操作步骤，并按照约定对研究人员给予了认可。
管理指标
| 指标 | 衡量内容 | 首要行动 |
|---|---|---|
| 已追踪收据 | 报告包含所有者和首次响应日期 | 修复静默渠道 |
| 已确定范围 | 已确认受影响的产品、版本和依赖项 | 在最终建议前扩大搜索范围 |
| 已验证修复 | 已在已发布版本上重现原始案例和相关案例 | 不要关闭存在漏洞的变体 |
| 已通知用户 | 已向受影响用户提供指导 | 已更新所需渠道和翻译 |
常见错误
- 不考虑风险而承诺单一截止日期
- 向报告者索取过多个人数据
- 将确认视为补救措施
- 在提供可用缓解措施之前发布详细的利用证据
- 忽略合作伙伴嵌入的版本
常见问题解答
披露政策是否等同于漏洞赏金？
否。政策解释了如何报告和协调。 奖励需要单独的规则和资源。
沟通是否必须始终等待问题解决？
否。时机取决于风险、临时措施和受影响方。 记录并重新审视决策。
协调员何时应该提供帮助？
当多个供应商受到影响、联系人无响应或共享时间表难以制定时，协调员可以提供帮助。
官方参考文献
参考文献支持该方法。 请根据您的实际情况调整检查；它们并非认证。 原始参考文献标题和源文档可能使用其他语言。
