CodeBuddy Security

方法

情报越细，检出越稳

把一份真实漏洞报告连同代码交给任意一个 Coding Agent，报告里有漏洞类型、精确位置、成因和触发路径，它一定能「找到」：验证一个已经被告知的答案，远比从无到有发现答案容易。完备情报下人人满分，能力的分水岭在中间地带：只告诉它一类漏洞、一个大概的模块，它还能不能找到？大量真实审计观察下来，可以总结出一条经验规律：

对具备基本工具调用能力的 AI Agent，只要情报是真的，它检出漏洞的概率随情报详尽程度单调不减。

漏洞发现是一场搜索，搜索的单位是一个个待检验的猜想：某处的输入，经由某条路径到达某个危险操作，并因缺少某道校验而失控。对有一定规模的仓库，猜想的数量远超 AI 在有限预算内能逐项验证的范围。每一条有效情报都在给这个集合加约束，集合越小，预算越有可能覆盖它。

引擎据此分成前后两段，中间以「模块」衔接。模块是围绕同一职责、代码紧密关联的功能单元：如果审计其中一个单元时必然要反复阅读另一个单元的代码，两者就不该拆开。模块是审计的入口，不是边界，Agent 从这里进入，可以沿调用链跨文件、跨子系统继续追下去。

一次对 React 的审计中，威胁情报发现某模块刚修复过一个反序列化问题，系统据此专项排查同类路径，最终找到了官方修复遗漏的另一条路径。刚发生过安全修复的模块往往更值得继续检查，这类项目级先验，传统静态规则引擎很难从代码历史中自动获得。

这就是「从模型到平台」：模型是流水线中可替换的一环，情报构造、任务调度、对抗复核、真实复现和全链路计量共同组成了系统。

评测

在答案已知的真实项目上评测

在内部开发体验环境中，引擎累计约 800 万次模型调用，积累 25,000 余条漏洞线索，其中 3,200 余条由引擎自动生成 PoC 并在真实环境复现成功。不过，真实扫描只能告诉我们找到了什么，无法告诉我们还有多少没找到；要衡量检出能力，需要答案已知的测试集作为参照。

测试集怎么设计，决定了测到的是哪一种能力。业界常用的 CyberGym 默认会同时提供易受攻击的源码和漏洞描述，要求系统生成能触发目标漏洞的 PoC，测的是「已知漏洞怎么复现」。人工靶场则是另一回事：靶场的漏洞是设计出来的，真实项目的漏洞是演化出来的。靶场的漏洞密度通常远高于真实项目，类型也多按已知模式植入，更适合衡量枚举和模式识别能力。

因此，测试团队维护了一套内部测试集：从知名开源项目中选取包含多个已确认历史 CVE 的版本快照，让系统在没有任何提示的前提下自行发现问题，考的是「未知漏洞怎么发现」。发现加上复现，才是漏洞挖掘的全貌。

三道防污染机制

1. 评估全程断网，Agent 无法在线检索外部信息。
2. 记忆检测：未读代码就直接报出 CVE 编号，或未访问根因文件就给出精确位置的，进入人工复核，确认属于背诵后从基准中剔除。
3. 用引擎的运行结果反向审计基准本身，人工复核中发现的遗漏漏洞、范围错误和重复发现都会被修正，样本持续迭代。

• 端到端检出率 73.2%

  输入只有代码仓库，线索由系统通过威胁情报和攻击面分析自行生成，全程禁止联网。四个系统统一使用 GLM-5.2 以排除模型变量：对照组中表现最好的 Claude Security 检出率为 42.7%，CodeBuddy Security 为 73.2%，是前者的 1.7 倍。

• 给出模块级情报后 90.2%

  人工为目标漏洞写模块级情报，只指出功能模块和风险类型，不提供文件、函数或调用链，例如「curl 的 HTTP/2 流依赖树模块存在释放后使用风险」「curl 的 .netrc 凭据查找模块存在密码泄露风险」。定位代码、分析路径和确认漏洞都由 Agent 自行完成，全程禁止联网。这组实验测的是 Agent 能否把不完整的情报转化为真实发现。