文章总结： 文章探讨AI在进攻性安全领域的应用，指出AI能加速漏洞发现但无法替代人类验证。核心观点是AI输出不等于证据，验证仍需依赖对系统、协议和业务逻辑的深入理解。行业已出现大量低质量AI报告，团队应区分线索与已验证发现，并建立严格验证标准。最终结论是AI应作为力量倍增器，而非判断力的替代品。 综合评分： 87 文章分类： AI安全,漏洞分析,实战经验,红队,安全运营

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

FreeBuf

2026年7月17日 18:00 上海

在小说阅读器读本章

去阅读

人工智能（AI）正在改变进攻性安全领域，但它并未改变最重要的标准：一个发现必须经过验证才能发挥作用。AI辅助工具可以快速读取代码、生成payload、总结攻击面、解释陌生的API，并以惊人的速度运行重复性测试工作流。这对安全团队来说是一个真正的优势，但也带来了新的压力，因为业界现在能够以前所未有的速度生成看似漏洞的输出。

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

随着AI在安全工作流中越来越普及，这种区分变得愈发重要。AI可以加速发现，但验证仍然依赖于知识：关于系统、协议、应用行为、身份边界、内存损坏、业务逻辑以及所有那些将合理理论与真实利用区分开来的实现细节的知识。进攻性安全的未来，不属于那些仅仅产出最多发现的人，而属于那些能够证明什么才是真正重要的个人和团队。

Part01

行业已看到浅层AI输出的代价

警示信号已经显现。漏洞赏金计划和维护者一直在应对大量低质量的AI生成报告，这些报告通常证据薄弱、语言模板化，且缺乏有意义的验证。Bugcrowd在其关于AI生成提交的政策变更中公开讨论了这种模式，描述了一类看似精致但反而造成了不必要的分类负担、而非有用安全信号的报告。

这不仅仅是漏洞赏金的问题。它预示了任何使用AI生成安全发现但背后缺乏足够人类判断的情况下会发生什么。如果工具能在几秒钟内生成令人信服的报告，组织将收到更多的报告、更多的警报和更多的声明。除非这些声明得到验证，否则结果不是更好的安全，而是更长的队列。

安全团队已经忙于处理扫描器输出、依赖项警报、云配置问题和合规发现。在此基础上再添加AI生成的猜测，除非同时提高质量门槛，否则毫无帮助。一个发现应该清晰地回答基本问题：发生了什么、如何复现、攻击者控制了什么、越过了哪个边界、以及展示的影响是什么。没有这些，报告可能很有趣，但不足以驱动工程行动。

Part02

“看起来有漏洞”不等于有漏洞

进攻性测试中最危险的习惯之一，就是将可疑模式与已验证的漏洞混为一谈。AI可能加剧这种习惯，因为它善于解释某些事情为什么可能有问题。模型可能看到用户输入靠近数据库查询，就描述为SQL注入；可能看到一个URL获取，就建议是SSRF；可能看到代码路径中的危险API，就描述为远程代码执行。有时模型指向了真实问题，但有时它忽略了决定问题是否重要的条件。

测试人员仍需证明可达性：攻击者控制的输入是否真的到达了危险操作？是否需要身份验证？授权是否在其他地方强制执行？有漏洞的功能是否已启用？生产配置是否暴露了代码路径？应用程序是否在payload起作用之前对其进行了标准化、编码、清理或拒绝？该问题是否跨越了信任边界，还是仅影响内部路径且没有实际安全影响？

这些问题才是真正进攻性安全的起点，也是浅层自动化常常失效的地方。AI可以快速生成假设，但假设不是发现。优秀的测试人员将AI输出视为需要调查的线索，而非需要转发的结论。

Part03

为什么知识仍然重要

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

这种理解通常是通过重复实践获得的。资深研究员花了多年时间手工完成工作：追踪请求、阅读源代码、逆向工程二进制文件、调试崩溃、编写利用代码、破解认证流程，以及学习真实系统如何失效。这个过程建立了记忆和直觉。它教会从业者：什么时候发现很可能是真实的，什么时候工具被误导了，什么时候一个小缺陷如果与其他缺陷链式组合可能变得严重。

这种知识很难伪装。它体现在测试人员提出的问题中，体现在报告撰写的方式中，体现在测试人员能否不依赖泛泛语言来解释攻击路径中。最重要的是，它体现在第一次尝试失败时。理解系统的人能够调整适应；只接受工具解释的人往往束手无策。

Part04

AI能让优秀的测试人员更快

但也可能让人变得生疏

经验丰富的从业者中存在一个真实担忧：过度依赖AI会让人变得生疏。这不是反AI的论点，而是关于人类学习的论点。当工具能瞬间回答每个问题时，人们就容易不再记住细节；当工具写出每个脚本的初版时，人们就容易停止练习；当工具解释每个代码路径、payload、崩溃和错误消息时，人们就容易停止自己构建心理模型。

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

如果从业者停止锻炼这些能力，他们就会失去部分使自己高效的关键技能。风险不在于AI让安全专业人员变得无用，而在于人们让AI过早承担了太多思考，然后将流畅度误认为能力。提示（Prompting）很有用，但它不能替代判断力。

Part05

AI辅助测试仍在使用熟悉的技术

大量的AI安全营销可能让人以为机器学习正在通过某种全新的推理方式发现漏洞。有时模型确实能发现人类可能遗漏的模式，尤其是在大型且不熟悉的代码库中。这很有用。但在许多实际的进攻性测试工作流中，底层技术仍然很熟悉：枚举端点、检查参数、追踪数据流、比较已认证和未认证行为、生成payload、运行模糊测试器、观察响应，并确定应用程序状态是否以安全相关的方式发生了变化。

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

AI最有价值的用途不是取代这些决策，而是减少围绕它们的机械性工作，以便熟练的测试人员能花更多时间进行分析和验证。

Part06

良好验证的标准

一个经过验证的进攻性发现应该是具体的、可复现的，并且与影响相关联。它不应让读者猜测问题为什么重要。报告应使攻击路径足够清晰，让工程师能够复现，安全领导者能够理解风险。这并不意味着每个问题都需要一个戏剧性的利用链或电影式的概念验证。它意味着证据应支持主张。

对于AI辅助测试，团队应严格区分线索（leads）和已验证发现。线索是值得调查的东西；已验证发现是经过测试并证明的东西。混淆这两者会造成混乱并浪费时间。良好的工作流绝对可以使用AI来生成线索，但从线索升级为发现应要求有证据。

Part07

实用的验证清单

一个实用的验证标准并不需要复杂。在将线索变为报告发现之前，测试人员应能回答如下问题：

• 观察到了什么具体行为？发生在哪里？
• 需要什么攻击者控制的输入、身份或状态？
• 越过了什么安全边界（如身份验证、授权、租户隔离、信任、权限或内存安全）？
• 在目标环境中复现该行为的确切步骤是什么？
• 展示的影响是什么（而非理论上的最坏情况）？
• 有什么证据表明该问题在部署配置中是可达且相关的？
• 修复需要改变什么？团队如何确认修复有效？

这种清单有助于让AI保持在正确的角色。它可以帮助生成候选方案、建议测试思路、加速复现。但它不应被允许跳过人类根据现实验证主张的步骤。

Part08

人类角色仍然是技术性的

AI安全平台一个未被充分认识的事实是，人类验证在幕后仍然非常重要。这不应令人惊讶。进攻性安全始终需要判断力，而当发现变得有影响力时，判断力尤其重要。审查证据的人必须决定攻击路径是否现实、环境是否重要、问题是孤立的还是可链式组合的、以及严重性声明是否合理。

这不仅仅是一个管理性质的质量控制功能。它是技术工作。授权缺陷通常依赖于业务逻辑和对象关系；API漏洞可能需要理解角色、租户和资源如何交互；内存损坏需要对崩溃状态、控制、缓解措施和利用原语进行推理；云发现严重依赖于身份、信任策略和服务特定行为。AI可以协助所有这些，但并不能消除对懂行之人的需求。

发现的影响越大，人类角色就越重要。当结果可能影响工程优先级、客户信任、合规义务或高管风险决策时，组织需要的不是自信的猜测，而是证据。

Part09

避免夸大影响

AI生成的报告也可能夸大严重性。反射输入在演示脚本执行之前不是跨站脚本；URL获取在测试人员展示能访问攻击者本不应接触到的内容之前不是有意义的SSRF；危险函数在证明可达性、控制和可执行性之前不是远程代码执行。这些错误不仅令人尴尬，还会侵蚀安全团队与工程团队之间的信任。经常发生的情况是，一个发现被评为CVSS 9.8，而实际上它根本可能不是一个发现。

经验丰富的研究人员对影响很谨慎，因为他们知道影响是挣来的。管理员专用功能中的漏洞与未认证的面向互联网的漏洞风险不同。一个崩溃可能是拒绝服务、代码执行路径，或者仅仅是一个不可利用的可靠性问题，这取决于上下文。一个代码路径中缺失检查可能很严重，也可能被另一处的控制所保护。唯一的判断方法是验证。

良好的验证既能防止低估也能防止高估。它帮助测试人员避免“狼来了”，同时当问题确实严重时，它也提供做出有力论证所需的证据。Tenable最近也提到了这一领域的挑战，包括常常会遗漏关键的上下文组合。

Part10

团队应该如何使用AI

正确的目标不是避免使用AI——这项技术太有用了。正确的目标是使用AI来加强进攻性测试，而不是削弱执行测试的人。AI应帮助测试人员更快行动、探索更多假设、减少重复性工作。它不应成为学习系统行为的替代品。

安全领导者可以通过设定关于证据和培训的期望来鼓励这种平衡。初级测试人员仍应在过度外包流程之前学习基础知识；高级测试人员应将AI作为力量倍增器而非权威来源。团队应审查的不仅是是否生成了发现，还有测试人员能否解释和复现它。这种解释是真正理解变得可见的地方。

一个健康的AI辅助进攻性测试项目应奖励经过验证的影响而非数量。它应衡量信号质量，而不仅仅是发现计数。它应在请求操纵、代码审查、调试、利用开发、威胁建模和影响分析等领域保留手动实践。它还应该将AI用作教学工具：当模型建议一个问题时，测试人员应问为什么、测试该主张，并从结果中学习。

Part11

标准没有改变：证明它

AI将继续改进。Agent将更擅长导航应用程序、阅读代码、生成payload和记录结果。其中一些进步将令人印象深刻，安全团队应加以利用。但进攻性安全不能变成一种数量游戏，让每个合理理论都成为别人分类的负担。

该领域的核心标准仍然简单：证明它。证明漏洞存在。证明攻击者能到达它。证明影响。证明业务风险。证明修复有效。AI并未降低这一标准。相反，它提高了强制执行标准的必要性，因为现在比以往任何时候都更容易产生令人信服但未经证明的输出。

未来十年最优秀的研究人员和团队，不会是那些拒绝AI的人。而是那些将自动化与技术判断相结合、用机器加速工作但不交给它最终决定权的人。知道何时停下来检查、测试和思考，仍将是竞争优势。知识仍然重要，因为验证仍然重要。而在进攻性安全中，验证就是噪音与真相之间的分界线。

参考来源：

AI Can Find Bugs, But Human Knowledge Still Proves Them

https://thehackernews.com/2026/07/ai-can-find-bugs-but-human-knowledge.html

推荐阅读

#

#

#

#

#

#

#

#

#

#

#

#

#

#

#

电报讨论

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：FreeBuf 《AI能发现漏洞，但验证仍需人类知识》