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

原创

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行代码

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来轮是有的，这是最终得到的东西。

claude的：

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

deepseek：

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

任意文件写入的：

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

思考：

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

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

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

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

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

后文：

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

比如 昨天摸鱼审的一套