过去两年，大模型的代码理解能力进步得很快。于是，一个看起来很自然的想法出现了：把整个代码仓库丢给模型，让它找漏洞。
我们在研发 MonkeyScan 的过程中反复验证过，这条路没有那么简单。
大模型很重要，但只靠大模型，做不好真实项目的代码安全审计。真正决定最终效果的，除了模型能力，还有模型之外的整套 Harness：怎样理解一个陌生仓库，怎样找到真正值得分析的攻击面，怎样跨文件追踪数据流，怎样验证候选漏洞，怎样压制误报，以及怎样让一次长时间扫描稳定完成。
这也是 MonkeyScan 在安全 Benchmark 上取得高检出率和高准确率的关键。我们做的并不是给大模型套一层界面，而是在框架层投入了大量工程工作，把模型的代码理解能力变成一套能够在真实仓库中工作的安全扫描系统。
大模型会看代码，不等于它会审计一个仓库
让模型分析一段几十行的代码，和让它审计一个几十万行、包含多种语言和复杂依赖的仓库，是两件完全不同的事。
在真实项目里，漏洞往往不会完整地出现在同一个文件、同一个函数，甚至同一个模块中。
一个外部输入可能从路由进入，经过参数转换、权限判断和业务封装，最后在另一个目录中的危险函数里被执行。单独看其中任何一段，代码都可能显得没有问题。只有把入口、约束条件和最终影响串起来，才能判断它是不是一个真正可利用的漏洞。
如果只是把代码切成若干段，逐段询问大模型，通常会遇到几个问题：
- 上下文不完整，模型看到了危险函数，却不知道输入是否真的可控；
- 仓库太大，分析预算被大量低价值代码消耗，真正的攻击面反而没有被深入检查；
- 缺少跨文件追踪，能发现局部风险，却无法还原完整利用链；
- 缺少验证和结果收敛，模型提出大量“可能存在”的问题，最后变成误报清单；
- 过程不稳定，同一个项目重复扫描，结果可能出现明显波动。
因此，模型能力只是起点。要把它用于真实代码安全审计，还需要一套能够组织、约束和验证模型工作的 Harness。
MonkeyScan 真正投入的，是模型之外的 Harness
可以把大模型理解为一位代码理解能力很强的安全工程师，把 Harness 理解为这位工程师使用的方法、工具和工作台。
MonkeyScan 不会简单地把整个仓库塞进一个 Prompt，然后等待模型给出答案。一次扫描背后，包含了多个相互配合的环节。
首先是仓库理解。系统需要识别项目的语言、框架、目录结构、依赖关系和主要入口，先建立对项目的整体认识。
然后是攻击面定位。并不是每一行代码都值得投入同样的分析成本。外部输入、鉴权逻辑、文件操作、命令执行、反序列化、数据库访问、网络请求等位置，需要被优先识别和深入分析。
接下来是上下文获取与跨文件追踪。系统需要围绕可疑点继续查找调用关系、变量来源、保护条件和最终影响，而不是停留在局部代码片段上。
发现候选问题之后，还要进行漏洞验证。MonkeyScan 会继续判断输入是否可控、危险路径是否可达、现有校验能否被绕过，以及问题能否形成真实的安全影响。
最后是结果收敛。同一条漏洞链可能在多个位置留下信号，系统需要去重、合并证据、校准风险等级，并过滤掉缺少依据的猜测。
这套 Harness 的价值，是让模型知道应该先看哪里、还缺什么上下文、什么时候需要继续追踪，以及什么样的证据才足以输出一条漏洞。
换句话说，MonkeyScan 的效果并不只来自“用了哪个模型”，更来自我们怎样组织模型完成一次完整、稳定、可复核的安全审计。
我们没有只在合成样例上测试
为了验证 MonkeyScan 的真实扫描能力，我们选择了已经公开披露漏洞的真实开源项目，使用对应的历史版本进行复测。
当前已经完成复核的样本覆盖 5 个开源项目、至少 8 个公开漏洞要点，包括：
- Agent Zero 中可能导致未认证任意文件读取的路径遍历；
- OpenClaw 中与命令执行相关的批准绕过和参数完整性问题；
- Apache ActiveMQ 中可导致远程代码执行的危险操作链路；
- Flowise 中可能导致远程代码执行的沙箱或输入校验缺陷；
- ComfyUI-Manager 中能够篡改安全设置的 CRLF 注入问题。
这些不是为了 Benchmark 临时编写的玩具代码，而是来自真实项目、真实版本和真实漏洞链。它们跨越不同语言、框架和漏洞类型，也更接近日常安全审计面对的情况。
在这组安全 Benchmark 中，MonkeyScan 同时取得了很高的检出率和准确率。
这两个指标必须放在一起看。
检出率高，意味着已知漏洞不容易从扫描中漏掉；准确率高，意味着输出的结果中有足够多是真正值得处理的问题，而不是把审计成本转移给用户。
只追求检出率并不难：让模型尽可能多地猜，告警数量自然会上升。但这样的工具会很快失去信任。真正困难的是，在尽量找全漏洞的同时，让每一条结果都有清晰的代码位置、完整的分析链路和可以复核的证据。
MonkeyScan 在 Harness 层做的大量工作，最终就是为了同时守住这两个指标。
为什么准确率比“发现了多少条”更重要
传统代码扫描工具经常遇到一个问题：扫描结束后产生几百甚至几千条告警，真正的工作才刚刚开始。
开发者需要逐条判断告警是否成立，安全人员需要重新理解上下文，最后可能发现其中大部分并不能形成实际风险。工具看起来发现了很多问题，但没有真正减少人的工作。
MonkeyScan 想解决的不是“怎样生成更多告警”，而是“怎样给出更值得相信的结果”。
因此，我们更关心：
- 外部输入是否真的能够到达危险操作；
- 漏洞成立所需的权限和条件是什么；
- 中间是否存在有效的校验或防护；
- 问题最终会造成什么安全影响；
- 用户能否根据现有证据快速复核和修复。
一条能够说清楚入口、传播路径、危险操作和影响的漏洞，远比十条模糊的“这里可能不安全”更有价值。
安全扫描不应该只属于安全团队
MonkeyScan 面向的不只是专业安全研究人员。
如果你正在快速开发一个新项目，引入一个不熟悉的开源仓库，或者大量使用 AI 生成代码，都可以在上线前多做一轮源码安全检查。
你不需要在本地部署复杂的扫描环境，也不需要先写规则。提交 GitHub 仓库或源码包，MonkeyScan 会完成仓库分析，并给出可以继续复核的风险结果。
当然，我们并不认为 AI 可以取代专业安全人员。对于关键业务和高风险系统，最终结论仍然需要结合运行环境、业务条件和人工验证。但一套高检出率、低误报、能够解释漏洞链的扫描系统，可以显著降低安全检查的门槛，把很多问题提前到上线之前。
现在可以免费体验
MonkeyScan 目前提供免费积分。注册后可以直接创建扫描任务，用自己的真实项目测试效果。
建议不要专门准备一段“漏洞演示代码”，直接选择一个你正在开发的项目、一个准备引入的开源仓库，或者一份由 AI 生成并准备上线的代码。真实项目最能体现 Harness 在仓库理解、跨文件分析和漏洞验证上的价值。
大模型决定了安全审计能力的上限，而 Harness 决定了这种能力能否稳定地落到真实项目里。
MonkeyScan 做的，就是把两者真正连接起来。
