AI 能发现漏洞，但证明漏洞仍需人类知识

导语：AI 正在改变攻击性安全，但"证明一个发现真实存在"这一标准并未改变。本文深入探讨 AI 辅助工具的局限、人类判断的重要性，以及 Bugcrowd 等平台面对 AI 生成低质量报告的应对经验。

人工智能（AI）正在改变攻击性安全领域，但它并未改变最重要的标准：一个发现必须经过验证才有价值。AI 辅助工具能够快速阅读代码、生成攻击载荷、总结攻击面、解释不熟悉的 API，并以惊人的速度运行重复性测试工作流。这对安全团队来说是真正的优势。它也带来了一种新的压力，因为行业现在能产出比以往更多的"看似漏洞"的内容。

问题在于，输出并不等于证据。一份自动生成的报告可以看起来很专业，包含严重等级评分，甚至包含乍一看合理的概念验证（PoC）。但这并不能证明漏洞在已部署环境中真实存在，也不能证明其可利用性、影响或风险。在攻击性测试中，真正的难点从来不是写一份听起来像漏洞报告的东西，而是要证明什么才是真实存在的。

随着 AI 在安全工作流中越来越普遍，这种区别变得更加重要。AI 可以加速发现过程，但验证仍然依赖于知识：系统的知识、协议的知识、应用行为的知识、身份边界的知识、内存破坏的知识、业务逻辑的知识，以及所有把"看似合理的理论"与"真正的漏洞利用"区分开的实现细节。攻击性安全的未来不会属于那些仅仅能产出最多发现的人，而会属于那些能够证明重要问题的人和团队。

预警信号已经显现。漏洞赏金计划和维护者一直在应对大量涌现的低质量 AI 生成报告，这些报告往往证据薄弱、语言模板化、缺乏有意义的验证。Bugcrowd 在其针对 AI 生成提交的政策调整中公开讨论了这种现象，描述了一类看似精致却只会增加分类负担、并不能提供有效安全信号的报告。

这不仅仅是漏洞赏金领域的问题。它是任何地方使用 AI 创建安全发现而缺乏足够人类判断时会发生什么的预演。如果一个工具能在几秒内生成一份有说服力的报告，组织就会收到更多报告、更多告警、更多声明。除非这些声明经过验证，否则结果不是更安全，而是更长的待处理队列。

安全团队已经不堪重负，承受着扫描器输出、依赖项告警、云配置问题和合规发现的压力。在此基础上叠加 AI 生成的猜测并不会带来帮助，除非质量门槛同时提高。一份发现应当清楚地回答基本问题：发生了什么、如何复现、攻击者能控制什么、跨越了哪条边界、证明出的实际影响是什么。如果缺少这些，报告或许有趣，但还不足以推动工程层面的行动。

攻击性测试中最危险的习气之一，是把可疑模式当成已验证的漏洞。AI 会让这种习气更加严重，因为它擅长解释"为什么某些东西可能是坏的"。模型可能看到数据库查询附近有用户输入，就描述为 SQL 注入；可能看到 URL 请求，就建议服务端请求伪造（SSRF）；可能看到代码路径中存在危险 API，就描述为远程代码执行。有时模型确实指向了真实问题，但更多时候，它忽略了那些决定该问题是否重要的前提条件。

测试人员仍然必须证明可达性。攻击者控制的输入是否真的到达了危险操作？是否需要认证？授权是否在其他地方被强制执行？易受攻击的功能是否启用？生产配置是否会暴露该代码路径？应用程序在关键点之前是否对载荷进行了规范化、编码、清理或拒绝？该问题是否跨越了信任边界，还是仅仅影响一个没有实际安全影响的内部路径？

这些问题的答案，才是真正攻击性安全的起点。它们也是浅层自动化经常失效的地方。AI 可以快速生成假设，但假设不是发现。优秀的测试人员会把 AI 的输出当作调查线索，而不是直接转发的结论。

最优秀的攻击性安全从业者之所以有价值，是因为他们理解系统，而不仅仅是因为他们能运行工具。工具一直是工作的一部分，但工具的输出从来都不足够。Web 扫描器可能识别出一个会反射输入的参数；静态分析器可能标记出一个危险函数；模糊测试器可能产生一次崩溃；语言模型可能描述出一条看似合理的攻击路径。在每一种情况下，仍然需要有人理解这些信号意味着什么。

这种理解通常是通过反复实践获得的。资深研究员花了多年时间手动完成这些工作：追踪请求、阅读源码、逆向二进制、调试崩溃、编写漏洞利用代码、突破认证流程，并学习真实系统是如何失效的。这个过程建立了记忆和直觉，它教会从业者何时一个发现可能是真的、何时工具被误导了、何时一个小漏洞在与其他东西串联后会变得严重。

这种知识难以伪造。它体现在测试人员提出的问题中，体现在报告的撰写方式中，体现在测试人员能否不依赖泛泛之辞解释清楚利用路径。最重要的是，它体现在第一次尝试失败时。真正理解系统的人能够灵活调整；而只接受工具解释的人往往陷入僵局。

资深从业者中存在一个真实的担忧：过度依赖 AI 会让人变得生疏。这并不是反 AI 的论点，而是关于人类学习的论点。当一个工具瞬间回答每个问题时，人们很容易就不再记忆细节；当它写出每个脚本的第一版时，人们很容易就不再练习；当它解释每段代码路径、每个载荷、每次崩溃和每条错误信息时，人们很容易就不再自己构建心智模型。

这种便利是有代价的。攻击性安全奖励的是深度、模式识别和技术回忆。最难的发现往往来自于识别出一个区域的行为违背了另一个区域的假设；来自于了解解析器、框架、分配器、身份提供方和授权系统以前是如何失效的；来自于看到孤立时看似不重要的细节之间的联系。

如果从业者停止锻炼这些能力，他们就会丧失让他们有效的一部分核心技能。风险不在于 AI 让安全从业者变得无用，而在于人们让 AI 在太早的阶段做了太多思考，然后把流畅误认为能力。提示词工程是有用的，但它不能取代判断。

大量 AI 安全营销听起来仿佛机器学习正通过某种全新的推理方式发现漏洞。有时模型确实能浮出人类可能忽略的模式，特别是在大型且陌生的代码库中。这是有用的。但在许多实际的攻击性测试工作流中，底层技术仍然是熟悉的：枚举端点、检查参数、追踪数据流、对比认证前后行为、生成载荷、运行模糊测试、观察响应，并判断应用状态是否以安全相关的方式发生了变化。

换句话说，许多 AI 驱动的系统只是在规模化地编排已知测试技术。它们能够比纯手工的人类更快地规划、执行、观察和迭代。这是一个有意义的改进，但它并没有消除理解结果的需要。如果系统报告了一个授权缺陷，仍然需要有人知道对象关系是否重要；如果它报告了一个内存破坏漏洞，仍然需要有人推理可达性、崩溃上下文、缓解措施和可利用性；如果它报告了一个 API 弱点，仍然需要有人判断观察到的行为是否违反了应用程序的信任模型。

AI 最有价值的用途不是取代这些判断，而是减少围绕它们的机械性工作，让有经验的测试人员能把更多时间投入到分析和验证上。