漏洞报告不再特殊了

漏洞报告垃圾信息的规模与性质

• 许多公司如今每周/每天都会收到多份未经请求的报告，这些报告往往明显由 AI 生成、质量低下，或者接近勒索性质。
• 常见模式包括：琐碎的 CSS/UI 问题、被错误归类为“严重”的发现，或者把预期行为报告成漏洞。
• 维护者和安全团队表示已经出现倦怠，并考虑关闭或收紧项目（例如：禁止 AI 撰写的报告、要求视频 PoC、添加类似“turtle123”的隐藏令牌）。

漏洞赏金、激励与法律风险

• 用于抑制垃圾信息的建议包括：每份报告收取少量费用（可能不可退款）、为联系表单设置微型付费墙，或者制定严格规则。
• 相关担忧：激励不一致（公司可能为了避免付费而拒绝有效漏洞）、保留费用带来的会计/法律复杂性，以及付款会去匿名化研究者并增加其被捕风险感知，从而产生寒蝉效应。
• 一些研究者回忆称，即使是非平凡的 DoS/RCE 类问题，也曾被忽视或得到过低回报。

CVE 疲劳与依赖地狱

• 许多人抱怨 CVE 过载，尤其是对低影响问题给出高严重性评级（例如构建/开发工具中的 ReDoS、晦涩的文件格式）。
• Dependabot 和扫描器会产生大量告警，包括针对开发依赖项的告警；团队难以在真实风险与噪声之间做区分。
• 反方观点：开发和构建依赖项确实是攻击向量（例如供应链、从开发/CI 系统中窃取数据），尤其是在受监管行业中。
• 由此产生的做法：有些团队自动合并所有更新；另一些则批量更新，或尝试尽量缩小依赖图。

安全中的 LLM：能力与局限

• 共识是：LLM 大幅降低了发现许多浅层或基于模式的漏洞的成本，同时也会生成大量虚假或夸大的报告。
• 有人认为，对于某些类别的漏洞，LLM 已达到或接近“平均水平”的低投入研究者；也有人认为这种说法被夸大且令人反感。
• 一些组织现在使用 LLM 对收到的报告进行分诊、分类严重性或过滤垃圾信息；另一些则提议使用代理式工具自动审计，甚至修补代码。
• 怀疑者强调“参差不齐”的智能：模型可能漏掉困难漏洞、幻觉出问题，而且目前还无法提供可靠的最后一公里影响分析。

漏洞报告还特殊吗？

• 一种观点认为：漏洞与普通 bug 在本质上仍然不同；如今补丁更容易被武器化，因此保密与协调的重要性甚至更高。
• 另一种观点认为：“安全报告”与“真实且有影响的漏洞”之间的相关性已经崩塌，使得这些报告看起来只是更多噪声化的 bug 工单。
• 许多人认为，稀缺资源不再是找漏洞，而是值得信赖的分诊能力以及对真实世界影响的证明。

安全实践、形式化方法与文化

• 有人主张转向内存安全语言、形式化方法以及更强的规格层推理；也有人指出，不可判定性和高成本限制了完全验证。
• “要么完美安全，要么失败”与务实的风险管理、纵深防御之间存在张力。
• 还有人强调：与已知研究者建立信任关系、提供更好的激励，以及让安全与工程之间的互动更专业、少些对抗。

未来展望（尚不明确且存在争议）

• 一种观点认为：当前的“漏洞末日”只是暂时的；LLM 会快速吃掉容易的漏洞，然后在发布前被整合进去，从而减少外部报告。
• 反方观点认为：LLM 也会放大不安全代码的生成，而且许多组织永远不会采用稳健的发布前扫描，因此数量和噪声仍会居高不下。
• 还有人预测，由于垃圾信息泛滥，公开赏金项目会缩小或关闭，安全工作将转向可信网络以及内部或精选项目。