Aikido 这次发布 Code Audit，最该看的不是“AI 又能扫代码了”。这句话已经被安全厂商说到发白。

它瞄准的是另一类问题：漏洞不在某一行，而在三四个文件、几个模块、一次权限判断缺席之后，拼出一条攻击路径。SAST 抓规则很强。人工渗透测试抓真实利用很强。中间那道缝，一直贵，也一直慢。

Code Audit 补的是 SAST 和 pentest 中间那块

Aikido 对 Code Audit 的定位说得比较克制：不替代 SAST，也不替代 pentest。

它基于源代码工作。不需要 staging 环境，不需要认证账号，也不需要真的对系统发起攻击。它会沿引用关系跨文件、跨模块追踪，找单点看不出、连起来才危险的逻辑漏洞。

每个发现会附带根因、代码证据，并可生成修复 PR。这个点很关键。安全工具如果只会报错，最后往往变成另一座告警坟场。

典型场景包括：

  • 多文件串起来的 IDOR 链；
  • 源码中可推断的 ReDoS；
  • 动态测试没覆盖到的管理员路径；
  • feature flag 后面的功能；
  • 还没部署、但已经进代码库的风险路径。

受影响最直接的是两类人。

安全工程师和 AppSec 负责人，可以把它放在重大版本发布前，作为一次源代码层面的逻辑审计。不是拿来替掉 pentest，而是提前把一批明显值得查的链路筛出来。

负责发布质量的研发负责人，更现实的动作是把它接进发布门禁或 PR 修复流程。重点不是“多一个扫描按钮”，而是减少上线前才发现权限链、管理路径、隐藏功能的问题。

移动应用、智能合约、遗留代码库也适合这类工具。原因很简单：这些项目很多时候不方便完整跑起来再打，或者动态测试覆盖不到所有路径。

Aikido 还给了几组自家数据：内部测试和早期用户显示，Code Audit 约能覆盖完整渗透测试发现项的 70%-80%，成本约低 10 倍；早期用户每个代码库中位发现约 25 个问题。

这组数字能看，不能拜。它仍是厂商口径，不是独立评测结论。

真正的分水岭：规则匹配，还是推理审计

过去很多安全工具的底层逻辑，是“我知道坏东西长什么样，所以我去匹配它”。这套方法稳定、便宜、可复现，也成了 SAST 的基本盘。

但逻辑漏洞麻烦在另一层。它经常没有固定长相。

授权检查少一次。参数穿过三层。某个管理员入口没有被测试账号触达。单独看都不像事故。串起来，就是事故。

这正是 AI 模型进入代码安全后比较有价值的地方：把上下文理解变成自动化能力。不是替你写 checklist，而是帮你沿着代码关系往下追。

三类工具的边界大概是这样：

工具擅长抓什么容易漏什么更适合放在哪
SAST已知规则、危险函数、依赖和模式跨模块逻辑链、业务语义日常开发与 CI
渗透测试真实攻击路径、可利用性验证未部署代码、feature flag、无账号路径重要上线前、合规或高风险系统
AI 推理审计静态代码里的多步逻辑漏洞运行时状态、真实权限、环境配置大版本发布前、复杂代码库审计

这张表也说明了边界：Code Audit 的价值不在“比谁都强”，而在把过去必须靠资深安全人员慢慢串线的工作，提前推到研发流程里。

《史记》那句“天下熙熙，皆为利来”放在这里不突兀。攻击者会用更强模型降低找洞成本，防守方就很难继续只靠旧工具省钱。攻防两边都在买推理能力。一边用来找门缝，一边用来提前补门缝。

这不是安全行业第一次发生这种事。早年的杀毒软件靠特征码，后来不得不看行为。Web 安全也从黑名单规则，走到上下文、权限、业务流。技术一旦把攻击成本压低，防守工具迟早要往前挪。

今天换成代码审计，也是同一个逻辑。

该观察的不是 25 个问题，而是三件硬事

我不太买账的是，把厂商 benchmark 直接当结论。

“覆盖 70%-80% pentest 发现项”“成本低 10 倍”“每个代码库中位发现 25 个问题”，这些话听起来都很漂亮。但安全团队最后要处理的不是 PPT 数字，而是工单、复现、修复和上线风险。

静态推理有天然盲区。

运行时状态、真实业务权限、环境配置、第三方服务行为，都可能改变漏洞性质。一个代码上看似可利用的问题，可能落地后是误报。一个代码里看着不重的问题，也可能在生产权限下变成高危。

所以接下来最该观察的变量，不是它能报多少问题，而是这三件事：

  • 误报率能不能压住，别让安全团队替模型擦屁股；
  • 证据链能不能复现，别只给一段像样的解释；
  • 修复 PR 能不能进开发闭环，别停在“建议修复”。

对 AppSec 负责人来说，采购不该只看覆盖率。更该要求供应商拿同一代码库做对照：SAST 报了什么，Code Audit 多抓了什么，pentest 最后验证了什么。

对研发负责人来说，也别急着把它变成强制拦截。更稳的做法是先放在重大版本、核心服务、遗留模块上试跑。看它能不能减少人工审计时间，而不是制造更多发布阻塞。

还有几个现实问题，目前从公开信息里看不清：支持语言覆盖、CI/CD 接入深度、私有代码处理方式、数据隐私边界、企业里的权限管理。这些不如“AI 推理审计”听起来亮，但会决定它能不能进大公司的生产流程。

我的判断比较简单：Code Audit 代表的方向是对的。代码安全正在从规则匹配，往推理审计挪。

但这类工具要真正站住脚，不能只证明模型会读代码。它还要证明自己能被安全团队信任，被研发团队接受，被发布流程消化。

能推理，只是入场券。能复现、能修、能闭环，才算工具。