3. 漏洞接收与确认：接收、验证与影响评估
漏洞报告进来了，然后呢？
很多团队把精力都花在“修漏洞”上，却忽略了接收和确认这个环节。我见过不少案例，因为接收流程混乱，导致漏洞被重复提交、关键信息丢失，甚至引发法律纠纷。说白了，这一步没做好，后面的修复全是白费功夫。
3.1 漏洞接收流程
接收流程的核心就四个字：有章可循。你不能让白帽子把报告往公共邮箱一丢就完事，得有一套标准化的入口和响应机制。
标准接收渠道
- 专用安全邮箱：例如
security@company.com，并配置自动回复，告知报告者已收到。 - 漏洞赏金平台：如 HackerOne、Bugcrowd，自带模板和流程管理。
- PGP 加密密钥：我建议必须提供，敏感信息传输的基本保障。
- Web 表单：结构化收集漏洞描述、复现步骤、影响版本等。
我个人习惯在自动回复里加一句：“我们会在 3 个工作日内确认收到，并给出初步评估。” 这既是承诺，也是给报告者吃定心丸。
小技巧：自动回复里附上你的 PGP 公钥指纹，方便报告者加密后续沟通。
3.2 漏洞真实性验证
收到报告后，第一件事不是修，而是验证。你想想看，如果连漏洞是不是真的都没搞清楚就投入资源，那得多浪费？
验证流程我一般分三步走：
- 信息完整性检查：报告里有没有复现步骤？有没有截图或 PoC？如果信息不全，直接退回要求补充。
- 环境复现：在隔离的测试环境里，严格按照报告步骤操作。我遇到过报告说“在 Chrome 最新版上复现”，结果我在 Firefox 上死活跑不出来——后来发现是浏览器兼容性问题。
- 误报排除：有些所谓的漏洞其实是配置问题或预期行为。比如，某个接口返回了 403，但报告者认为这是信息泄露。这时候需要和开发确认。
避坑指南：我曾经收到一份报告，声称发现了 SQL 注入。结果复现时发现，那个参数根本不会被拼接到 SQL 语句里。后来和报告者沟通，原来是他用了过时的扫描器。所以，不要盲目相信任何报告，哪怕是来自知名白帽子。
验证通过后，我会给报告打一个标签：已确认、需更多信息 或 已关闭（非漏洞）。这个标签会同步给报告者，保持透明。
3.3 漏洞影响评估
确认漏洞是真的，接下来就要评估它的影响。这一步决定了你该用多大力气去修，以及什么时候修。
影响评估我主要看三个维度：
| 维度 | 说明 | 评估要点 |
|---|---|---|
| 技术影响 | 漏洞能造成什么破坏？ | 数据泄露？权限提升？拒绝服务？ |
| 业务影响 | 影响哪些业务系统？ | 核心交易？用户数据？合规要求？ |
| 利用难度 | 攻击者需要什么条件？ | 需要认证？需要用户交互？需要特定版本？ |
举个例子，一个需要管理员权限才能触发的 XSS，和一个无需认证的 RCE，优先级天差地别。我一般会用 CVSS 3.1 评分系统来量化，但不会完全依赖它。为什么？因为 CVSS 不考虑业务上下文。一个 CVSS 9.0 的漏洞，如果只影响一个内部演示系统，那优先级可能还不如一个 CVSS 6.0 但影响核心支付接口的漏洞。
我的评估清单
- 漏洞是否可远程利用？
- 是否需要认证？
- 是否影响数据机密性、完整性、可用性？
- 是否涉及敏感数据（如 PII、支付信息）？
- 是否有公开的 PoC 或利用代码？
- 是否影响合规要求（如 GDPR、PCI DSS）？
评估完成后，我会输出一份 漏洞影响评估报告，包含漏洞描述、复现步骤、影响范围、CVSS 评分、建议修复优先级。这份报告会同步给安全团队、开发团队和相关负责人。
嗯，这里要注意：评估结果要客观，不要为了降低优先级而故意打低分，也不要为了显得自己很忙而夸大影响。实事求是，才是合规的基石。
流程走完，漏洞就进入了修复阶段。但别忘了，接收和确认阶段的每一个步骤，都要有记录。合规审计的时候，这些记录就是你最好的护身符。