本文内容参考自：腾讯云云鼎实验室AI代码审计研究成果

2026年春天，Anthropic发布的Claude Mythos Preview在OpenBSD中找到了一个潜藏27年的漏洞，又在FreeBSD NFS场景下自主构造了多数据包的利用链，在沙箱中成功触发。

这不是个案——Mythos在Firefox JS引擎漏洞利用测试中，成功拿到SHELL 181次，而上一代Opus 4.6仅2次；在OSS-Fuzz基准测试中，从Tier 3跃升至Tier 5（完整控制流劫持），对2024/2025年Linux内核N-day的自主式漏洞利用成功率超过50%。

Anthropic随即启动Project Glasswing项目，首月从系统级关键软件中挖出超10,000个高危漏洞，扫描1,000多个开源项目，人工复审误报率低于10%。其中超过99%的漏洞至今未修复——漏洞被挖出的速度已远超修复速度。

更值得关注的是，这种审计能力并非专门训练的产物。Anthropic的研究表明，Mythos未做漏洞挖掘的特化训练，其突破是代码能力、逻辑推理和自主执行能力整体提升后的自然涌现。

攻防天平正在加速倾斜。从漏洞披露到被实际利用的时间差已缩短至小时级。攻击门槛也在降低——通过自然语言交互即可生成复杂攻击脚本。传统防御体系面临阶段性过载风险。

面对这一变局，有必要对当前代码安全的三种路径做一次冷静的对比审视。

传统SAST：稳定但触顶

传统静态应用安全测试（SAST）通过语法解析生成AST、流程分析构建CFG、数据追踪构建DFG，再经规则引擎匹配与污点追踪输出结果。这套流程成熟、稳定、成本低——跑100次结果都一样，在已知特征漏洞的筛查上速度快、结果确定。

但其结构性短板同样清晰：

•逻辑漏洞盲区大：SAST缺乏语义理解，无法识别需要追踪多步状态变迁才能触发的复杂缺陷，如协议状态机中的整数溢出、跨模块越权路径、多条件耦合的竞态窗口。举个直观的例子：一个删除用户的接口没有鉴权，SAST看到没有SQL注入风险就判定安全，它不会想到检查“该做却没做的事”。

•误报率高：规则集缺乏上下文语义，在复杂调用逻辑中极易产生大量误报，开发团队信任度低。

•规则滞后：依赖专家手写规则，新漏洞模式响应慢，难以及时覆盖快速迭代的系统架构与业务逻辑。

•止步于发现：只输出告警，不具备验证可利用性和生成修复方案的能力。

裸跑大模型：能力强但不稳

大模型的语义推理能力善于发现SAST看不到的深层逻辑漏洞，但直接拿来做企业级代码扫描，会撞上三堵墙：

注意力稀释导致漏报。大型项目代码库动辄百万行，全量喂给模型，海量无关代码稀释注意力，漏报率反而飙升。腾讯云云鼎实验室的对比测试显示：传统规则扫描检出219个漏洞，大模型独立扫描仅检出28个——花更多的钱，漏更多的洞。

结果不稳定。同一个仓库、同样的提示词跑10次，检出率跟抛硬币差不多。问题不在分析能力，而在注意力——代码库太大，模型有时看到了，有时没看到。SAST逐文件逐规则扫，跑100次结果都一样。这种波动性使其无法进入对稳定性有硬要求的发布流水线。

验证鸿沟。白盒审计中，判断一个漏洞是否真实存在、攻击向量是否可达、安全边界是否被突破，往往涉及具体业务环境。实际操作中，“AI找洞3分钟，安全人员确认3天”，人工审查负担并未真正降下来。

混合方案：互补而非替代

从以上对比可以看出，SAST和AI并非替代关系，而是互补关系。SAST速度快、结果稳定、运行成本低，是不可或缺的基础防线；大模型的语义推理则覆盖了SAST无法触达的深层逻辑与设计盲区。问题的核心不在于“谁取代谁”，而在于如何用工程架构约束大模型的短板，同时释放两者的互补价值。

这一方向上，OpenAI的Codex Security和Anthropic的Claude Code Security也在各自推进：前者侧重Agent推理+沙箱动态验证，实现从威胁建模到自动修复的全自动闭环；后者强调自我证伪机制和长上下文语义理解，从而降低误报率，在真实场景中发现更多真实漏洞。

综合来看，将AI审计与SAST有效结合，需要一套工程化的方法论约束。从当前行业实践和产品方案中，可以提炼出五个关键环节：

第一步：威胁建模定向，避免盲扫。先从代码库内部提炼信号——分析目录结构、历史Commit中的安全事件、高危业务模块；再拉取外部情报——与项目相关的CVE记录、安全公告、已知漏洞修复补丁。两路合流后，识别项目的攻击面与威胁模型，将代码库按模块拆成聚焦任务，AI引擎每次只处理一个模块及其关联热点，多轮渐进覆盖。模型的注意力不被海量无关代码稀释，成本随轮次摊薄。

第二步：双引擎并行扫描，结果合并去重。 SAST与AI审计引擎并行独立扫描，SATS负责已知特征漏洞的快速筛查，AI引擎专攻跨模块内存安全缺陷、协议状态机问题及业务逻辑漏洞。两路结果合并去重，兼顾覆盖率与准确率。

第三步：对抗性审查，过滤“自我确信”的幻觉。 AI在定位到潜在漏洞后，引入独立的二次校验流程——完全不依赖前序分析上下文，从零开始重新校验漏洞代码是否真实存在、触发路径是否可行。校验Agent使用反向立场prompt（默认假设“这是误报，请证伪”），本质上是一个自我证伪的过程，消除单次分析中越分析越容易“自我确信”的幻觉。

第四步：PoC沙箱验证，从“疑似发现”到“漏洞验证”。静态分析的结论始终是推断。最后一关是在隔离沙箱中搭建目标环境，由AI引擎编写PoC并实际执行，拿到实打实的攻击证据。交付给安全人员的不只是待排查的疑似发现，而是带PoC的验证漏洞。通过验证的漏洞自动生成修复补丁，安全与开发团队完成闭环审核。

第五步：规则反哺，构建自我增强飞轮。 AI每确认一个漏洞路径，就自动生成对应的SAST检测规则，沉淀进规则库。每发现一个新的漏洞模式，SAST就多一条可复用的规则。AI找过的漏洞，下次由静态引擎直接拦截，不再重复消耗算力。这不是简单的“扫描+报告”，而是一条从发现到验证到规则沉淀的自我增强闭环。

这套方法论的有效性，已在开源项目实战中得到初步验证。以LiteLLM为例——这是GitHub上拥有48,000+星标的AI时代热门开源项目，作为数百万LLM应用的统一API网关，集中管理OpenAI、Anthropic、Google、Azure等厂商的API Key。打穿一个LiteLLM Proxy，意味着拿到它代理的所有LLM厂商凭证。

漏洞藏在仅占代码量0.01%的回退路径中：LiteLLM Proxy校验API Key时，主路径走Prisma ORM参数化查询，安全；但PostgreSQL偶尔抛出“cached plan must not change result type”错误，触发一条回退路径，该路径使用手写SQL拼接。更关键的是，不以“sk-”开头的输入，hash函数根本不处理，原样返回——攻击者可以通过精心构造的输入实现未授权远程SQL注入。

这个漏洞在主分支上横跨22个版本无人发现，核心团队加社区数千人都未注意到，所有传统SAST工具只扫主路径，直接放过。AI审计引擎之所以能定位到它，靠的不是“更聪明的扫描”，而是识别出ORM安全路径与raw query回退路径对同一输入处理的不对称性，生成模块级审计假设，再经双阶段验证（Phase 1追踪确认 → Phase 2红队反驳，三轮证伪失败才确认）。

在量化指标层面，AI+SAST混合方案在已知漏洞测试集上召回率提升超80%，在真实业务代码上漏洞准确率提升超70%。同时，通过多模型搭配和缓存机制（缓存命中率超70%），平均仓库Token消耗约31M，在效果与成本之间取得平衡。

在上述趋势下，腾讯安全于2026腾讯云AI产业应用大会上发布了CodeBuddy Security，将云鼎实验室自研的AI深度审计引擎与静态分析工具Xcheck结合，构建了前述五步闭环的工程化实现。

在技术路线上，CodeBuddy Security采用“双引擎协同+工程化约束”的思路：AI深度审计引擎以CodeBuddy（腾讯自研AI Coding Agent）为执行底座，Xcheck支持私有化部署、源码不出网，在已知特征漏洞筛查上速度快、结果确定。扫描策略上，系统通过威胁建模先定位高风险模块，AI引擎分轮次聚焦扫描；验证环节引入对抗性审查和PoC沙箱执行；确认的漏洞路径自动沉淀为Xcheck检测规则。

目前，该方案已在大量主流开源基础设施、深度学习框架和底层系统模块中得到验证，陆续向NVIDIA、Google、Meta、Apache、Mozilla、OISF等企业及社区提报了多个有效漏洞并协助完成修复，获官方确认与致谢。同时，该方案已逐步接入腾讯内部发布流水线，并面向企业开放试用。

从行业视角看，CodeBuddy Security代表了国内安全厂商在“AI+SAST混合代码安全”方向上的一个工程化落点。这一方向的国际竞品——OpenAI Codex Security和Anthropic Claude Code Security——也在快速演进，各自在全自动闭环和自我证伪机制上形成了差异化路径。代码安全的范式迁移才刚刚开始，AI能力仍在快速迭代，混合方案的最终形态和最佳实践，还需要在真实场景中持续验证。

腾讯云 CodeBuddy Security企业级AI代码安全扫描方案

试用可移步：腾讯云发布企业级Agent安全框架与代码安全产品CodeBuddy Security