只把代码交给大模型,为什么还做不好安全审计?

📅 2026/7/14 19:35:35
只把代码交给大模型,为什么还做不好安全审计?
过去两年大模型的代码理解能力进步得很快。于是一个看起来很自然的想法出现了把整个代码仓库丢给模型让它找漏洞。我们在研发 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 做的就是把两者真正连接起来。