文章总结： 本文介绍作者自研的代码自动化审计工具codecheck，采用sast工程化与llm研判结合思路，实现自动化反编译、污点追踪、白名单路由提取等功能。实测对116MB约172万行代码系统，发现25个前台漏洞，token成本约10元。作者认为sast兜底能力与llm逻辑研判互补是核心，未来将迭代逻辑漏洞分析能力。 综合评分： 85 文章分类： 代码审计,安全工具,AI安全

代码自动化审计落地的一个答卷与思考

原创

goddemon goddemon

goddemon的小屋

2026年9月25日 02:52 四川

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

前言：

写自动化审计这玩意写了好久了，一边玩一边写，断断续续摸鱼终于是差不多基本上能达到自己的预期了，剩下的就是无限迭代优化+新功能的过程了。

内置了 agent交互模块，sink，数据审计模块，sast模块，威胁情报模块，其中agent交互模块还有很多bug任重而道远这里需要慢慢迭代优化。

llm 研判模块也需要优化很多，目前尝试了很多方案 但是有些方面还是没达到自己的预期。

正文：

写了很多模块，具体多少就不好说了，目前在迭代优化接口组合分析的接口差不多这个样子

即多个接口组合实现getshell 或者拿到权限

思路采用llm+工程化+因果图的思路去做的，还在优化迭代中。

其他的代码审计效果，因为本身目的是为了不漏报的基础上去做误报优化。

测评：

以下的均为8月24日测评结果：代码大小116m 小体量代码，且该系统不存在特殊trick，拿来做测试。

这里具体哪个系统就不说了 涉及很多未公开0day，这里不做泄露，因此严格打码。

当时部分功能未完全写，纯sast审+llm最终研判报告审的

实际上到现在又修复了很多bug和增加了一些功能

、

从以下角度来测评

1、代码大小：

codecheck由于是代码工程化的思路去做的，因此不论是几百m或者说几个g都是没啥影响的。

实测

而如果说是用agent的代码审计大小问题大家懂的都懂，代码体量一大有多难搞懂得都懂。

下面的就拿某闭源系统举例：

代码大小116.32mb

拿某小代码举例，代码规模（实测数据）：

合计172w行代码

| 层级 | 行数 | 文件数 | | — | — | — | | 服务端 C#（25个自研DLL反编译） | 499,910 | 3,649 | | 前端 JS/HTML/CSS | 1,146,455 | 1,715 | | ASPX/ASCX 模板 | 62,578 | 463 | | 配置/XML | 14,379 | 202 | | ASHX/ASMX 处理器 | 402 | 34 | | 总计 | ~1,723,724 | 6,063 |

2，自动化的角度：

codecheck上传zip然后点击扫描即可，就可自动化的去进行反编译代码，自动定义白名单路由等等，然后第二天起来开报告即可。

全程不需要其他的操作

3，token成本：

codecheck：

只有2个地方会用到token 白名单路由研判阶段，llm漏洞接口研判。

严格来说这两个接口可全进行不配置，这样只需要后面的分析阶段手动去分析，减少误报自动化捡漏洞罢了。

而对于自动化反编译，污点追踪，白名单路由提取等等全是sast工程化全做了的，这些所有全都不需要使用到token 不需要llm。

如果是算上最终研判的token成本的话 大概就10块钱左右，具体看后选的代码体量。

deepseek和claude的话这个有点忘了 当时没咋记录，但是估计10来轮 应该差不多几十块钱的样子，毕竟只是做测试，让他完全人工不接入的情况下，去跑看得到的效果。

4，前台漏洞数：

这里是用的codecheck产生的漏洞后，对接的llm api让他做的二次确认的，因为比较懒，并且也想测下当时工具的真实水平。

只谈直接判定出了25个 实际上待人工研判里面16个里面还有一些是真实的漏洞，但是由于证据不足，需要接入人工复审的。

这里随意贴几张审计报告的图

由于codecheck的原则是不漏报的原则上去做

这里只谈实际上跑的，当然这里给claude和deepseek实际上是降低了要求了，

比如

①给的他完整反编译完成后的代码和剔除了非业务包的代码给他让他审的

②产生漏洞是经过了多轮的询问，且每种漏洞类型都基本上询问了的，具体多少轮忘了，至少是10来轮是有的，这是最终得到的东西。

| 漏洞类型与漏洞数 | codecheck | Claude | DeepSeek | | — | — | — | — | | 漏洞数 | 前台 25个 | 37个 | 44个 | | SSO自动登录 | – SSO自动登录：8个 真实sso登录漏洞：4个 误报1个： 漏洞类型归类错误：3个 （这个bug在最新的已经修了） | sso自动化登录：0个 | sso自动化登录：0个 | | 认证绕过实现任意登录(DFA) | – 认证绕过实现任意登录(DFA)：3个 真实 3个 | – 认证绕过实现任意登录(DFA)：1个 | – 认证绕过实现任意登录(DFA)：2个 | | SQL注入 | – SQL注入：6个 真实6个   其中3个可前台 3个为后台 | 1个（误报） | 4个 2个说的是前台sql注入 1个说的是后台sql注入 其中前台3个为误报 | | 不安全反序列化 | – 不安全反序列化：3个 真实3个 其中1个为前台 2个为后台 | – 不安全反序列化：4个 真实3个 | – 不安全反序列化：5个 真实3个 误报2个 | | 文件操作 | – 文件操作：2个 1day已修复   任意文件写入1个 任意文件读取 1个 | | 1个 | | XXE | 1个  真实存在 1个 | 0个 | 1个 | | 其他 | 2个 | 31个 误报多少没测，一堆乱七八糟的漏洞比如cors，硬编码等等 | 31个 误报多少没测，一堆乱七八糟的漏洞比如cors，硬编码等等 |

claude的：

习惯性的cors 配置业务等等都在审

deepseek：

攻击链看着挺牛逼 实际上第一个download的就是误报，后面的链不知道怎么通

任意文件写入的：

最新版,已修复，但是证明老版本确实存在漏洞

思考：

1、在sast代码审计领域，真的纯llm的能力的话是肯定会导致很多漏报和误报的这个是必然的问题，毕竟代码审计和黑盒不太一样，黑盒是存在一个可交互的环境去测试的，但是对于代码审计而言大部分情况是不会拥有交互环境的，而llm最擅长的就是骗人。

因此sast做兜底是必然重要的能力，这个工程化在整个过程中一定是很重要的。

2、llm本身有很多可取之处也是sast做不到的，所以如果组合拿来进一步研判功能是干啥的 做逻辑漏洞的研判和组合分析的研判一定会大于纯sast的 因此sast+llm能力互补才是最重要的。

3、sast做到极致 比如漏洞样本去无限增加训练，trick去增加，这个方面的能力一定是llm 替代不了的。

4、未来需要去迭代的，逻辑漏洞这块的这块能力似乎可以结合llm来组合。

后文：

算是给自己一个答卷吧，以及也算是提升了自己的工作效率，以前审计一套系统 需要几天，现在确实晚上睡前挂着跑，第二天起来几个小时就能基本看完一套大代码。

比如 昨天摸鱼审的一套

免责声明：

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

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

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

本文转载自：goddemon的小屋 goddemon goddemon《代码自动化审计落地的一个答卷与思考》