本地AI在渗透测试中的基准测试：本地模型为何胜出

导语：自上次尝试类似方法以来，模型智能和攻击技术都有了很大进步。关于Anthropic发布的研究外界有很多热议，但成本和隐私问题仍然是障碍。当无法保证工作完成得足够彻底时，安保工作就变成了某种像在赌博一样的事情。

为了测试，我设计了一个小实验。

我对四种不同的方法进行了基准测试，用一个我已知的漏洞来评估每种方法的有效性。

基准漏洞：PHPIPAM 认证型本地文件包含（LFI）

基准漏洞是一个经典的.php认证型本地文件包含问题。

控制器名称取自用户输入，直接拼接到require_once中，没有任何过滤。

如果API已启用（默认关闭）且你有有效凭据获取API令牌，就可以包含/执行任何可被Web服务器访问的、以.php结尾的文件。

第二次请求包含了我植入的phpinfo();文件来演示问题。

⚠️ 此问题已在没有补丁的情况下公开披露，因为风险相对较低，且PHPIPAM维护者没有任何回应。

该漏洞仅影响启用了API的实例（默认不启用）。默认影响也有限，似乎没有办法向Web服务器上传任意.php文件，也没有有趣的默认文件可以包含/执行。

如果你正在运行PHPIPAM并希望立即采取行动，建议在此期间先禁用API。此漏洞编号为CVE-2026-12194。

测试结果

简而言之：在测试的四种方法中，最成功的一种清楚地表明：框架/方法比模型本身更重要。

如果你只对这个方法感兴趣，可以直接跳到这里。

方法	是否发现了漏洞？
Semgrep	否
云端GLM 5.1 + Strix AI Agent	否 *
云端SOTA + 代码审查技能	有时能
本地AI + 自定义框架	是

Semgrep

仅使用semgrep scan --config auto运行的Semgrep没有识别出这个漏洞。

当然，写自定义规则来检测这个特定模式是可能的。然而，这一直是传统SAST工具的核心挑战之一：你只能为你已经知道的危险模式编写规则。

GLM 5.1 + Strix全自动化AI渗透测试

接下来我看了Strix：一个全自动化AI渗透测试工作流。

拥有超过25,000个GitHub stars，我很期待看看它能做到什么，以及是否能识别这个bug。

💡 注意：其文档要求使用GPT-5.4、Claude Sonnet 4.6或Gemini 3 Pro。

我不想签一张空白支票，所以选择了GLM 5.1，这样我就能先用更便宜的模型观察token消耗情况。GLM 5.1的基准测试结果与Strix推荐的模型相似，但请对这个结果持保留态度。

看它运行起来真的很激动人心。

它克隆了仓库、探索了代码库，甚至自己安装了应用程序来动态验证可能的发现。

大约12小时后，消耗了近6000万tokens，一份report.md文件已经准备好了。

它没有发现我们的LFI。这让我想起了这条推文。

GPT-5 just refactored my entire codebase in one call. 25 tool invocations. 3,000+ new lines. 12 brand new files. It modularized everything. Broke up monoliths. Cleaned up spaghetti. None of it worked. But boy was it beautiful.

使用GLM 5.1的实际花费约为30美元（尽可能多的请求也被路由到了免费推理提供商）。如果使用Sonnet，费用大约在180到300美元之间。Opus则要再加倍。

我不太有兴趣花那么多钱用更贵的模型重试。

生成时间：2026-05-22 04:33:37 UTC

执行摘要

对phpIPAM（IP地址管理）1.8.1版本进行的外部渗透测试发现了多个安全弱点，如果被利用，可能导致敏感数据泄露、存储型跨站脚本、服务器端请求伪造和权限提升。

整体风险态势：高。

主要发现包括：

通过API暴露敏感用户数据（任何认证用户均可访问密码哈希、令牌、2FA密钥）
通过API的存储型XSS（HTML转义被禁用，允许持久化脚本注入）
保险库证书获取中的SSRF（可扫描内网和访问云元数据）
API中功能级授权缺陷（非管理员用户可以创建管理员资源）
管理员端点上状态变更的多个CSRF漏洞
自定义字段重排序功能中的二阶SQL注入
使用松散比较而非计时安全比较的弱CSRF令牌验证

其中一些问题按PHPIPAM的威胁模型是属于设计如此。其他的看起来像是误报/不太有趣/已经修复了。

云端SOTA + 技能型代码审查

接下来我尝试了另一种方法：AI技能。

对于不熟悉这个概念的人来说，AI技能实际上就是Markdown文件，为Agent提供特定的指令、工作流程和专业知识。

我用一个社区贡献的安全审查技能作为起点。

我做的修改包括：

移除了依赖审计、密钥扫描和提议补丁步骤
将每个漏洞类别分散到各自的专用子Agent中
在注入缺陷部分增加了关于本地文件包含（LFI）的额外指导

最终，我发现结果非常不一致。扫描有时能找到漏洞，有时完全找不到。

Claude Code + Opus 4.8

在这个技能加持下尝试使用Claude Code的’Pro’计划，得到了一个相当糟糕的结果。

阅读它的思考过程，它决定不生成子Agent来处理每个漏洞类别。

要求它显式生成子Agent，结果立即达到了5小时的会话限制……

Cursor + GPT 5.5（中配）——使用OpenRouter约5-10美元

经过几次使用各种模型的尝试后，下面是使用Cursor和GPT 5.5找到问题的一次运行。

问题所在

我很快意识到，在相当大的代码库中，审查工作不够彻底。是否能找到问题往往取决于Agent决定读取哪些文件，以及它选择用哪些术语进行grep。

有趣的是，一旦指向正确的文件，几乎每个模型都能立即识别出漏洞。

“再仔细点！”——使用技能

使用技能尝试这种方法，立即遭到了拒绝。看模型的推理，它经常得出结论：任务太大，无法在单次运行中完成。

即使我通过了拒绝，这方法的成本也可能令人望而却步。

但是，如果本地模型在给定单个源代码文件+上下文的情况下就足够用了，而不是一次性审查整个代码库这个难得多得多的任务呢？

本地AI模型 + 自定义框架

我们的下一步方法是将单次大审查换成一个小型的本地框架。不是让一个Agent一次推理整个代码库，而是让框架引导本地模型逐个文件地遍历项目，每次给它一个文件加上所需的上下文。

对于每个源文件：

|
+--> 本地模型审查单个文件（+上下文）
|
+--> 写一份结构化报告
|
v
收集所有报告
|
v
???
|
v
Profit

高级架构图：

这种方法每次运行都找到了基准漏洞。

安全漏洞报告：api/index.php

高风险：路径遍历/通过Controller参数的任意文件包含

描述

API入口点使用未经过滤的用户输入构造文件包含路径。值从$_GET、$_POST、JSON body或XML body直接流入require_once()，没有任何路径验证，启用了目录遍历（../）来包含文件系统上任意PHP文件。

— 省略 —

对于这个代码库，我估计大约消耗了1.2亿tokens，审查了约800个源代码文件。

局限性

Token密集型：如果你无法本地运行模型，成本会很高。幸运的是，Project Black已经为需要密码破解的渗透测试维护了一个hashcat设备。事实证明，这套硬件也足以运行Qwen 3.6 27b，约170k上下文。
误报多：由于这种方法纯粹基于代码审查，可能会产生误报。你可以将这个阶段的输出输入更多AI工具来验证可利用性，但这会进一步增加token消耗。
缺乏威胁模型/更广泛的应用程序上下文理解：根据我对其他已知问题的测试，它似乎在识别更复杂的访问控制缺陷时遇到困难——这些问题在假设的细微差异方面更为复杂。

无论如何，一次可能是侥幸。看看它能不能找到我自己都不知道的东西？