漏洞披露流程：收到报告后怎么办

发布时间:2026-09-08 11:56

## 适用场景 团队收到外部安全研究者的漏洞报告，或自家测试发现了线上问题。此刻的处理方式决定后果走向：流程顺畅，漏洞被安静修复，报告者获得尊重；处理失当，要么漏洞被抢先公开，要么报告石沉大海后酿成事故。团队内部先定好谁负责接收、谁有权确认、谁能拍板修复，三件事有归属，外部沟通才不会乱，骨架定了，剩下的就是响应速度与态度。 ## 步骤清单 第一步，确认收悉。尽快回复报告者，确认收到并给出评估时间预期，先不说结论，只表达认真对待。第二步，验证复现。在测试环境复现问题，评估影响范围、利用条件与严重程度，排除误报。第三步，修复验证。按严重程度排期，高危立即处理，修复后在测试环境验证，再灰度上线。第四步，回复与致谢。修复完成后告知报告者结果，公开渠道可致谢，事先约定披露节奏，避免对方在修复前抢先公开。全程沟通记录留存，邮件与顺云工单是合适的载体，时间线清晰可回溯。 ## 验证方法 修复上线后请报告者复测确认，这是对双方都体面的收尾。内部再做一次复盘：漏洞如何进入、为何自测没发现、同类风险还有哪些。 ## 注意事项 不要指责报告者，哪怕是测试性质的探测，沟通姿态决定后续走向。不要静默修复后装作无事，报告者往往有其他披露渠道。不要承诺无法兑现的奖励，量力而行走致谢路线同样成立。对外沟通保持专业与克制：不追问对方怎么发现的，不暗示对方行为不当，把注意力放在验证与修复上。绝大多数报告者要的只是确认与尊重，处理顺畅的一方往往还愿意继续报告新问题，等于免费多了一双外部眼睛。响应速度本身就是态度，多数矛盾都源于漫长的沉默。