被反复确认的一类供应链事故
把 Coding Agent 推到生产环境一段时间后,几乎所有认真做过事后安全审计的团队都会观察到同一类事故——AI 生成的代码里包含已知漏洞的依赖版本,这些版本在 OWASP 公开漏洞库里被追踪、在主流扫描器里有明确规则,但 Coding Agent 在生成代码时仍然把它们写进了 package.json、pom.xml、Cargo.toml 等依赖清单。这类事故不是个别失误,而是 Coding Agent 自身训练数据和评估流程的系统性偏差——模型在训练时见过的"标准"代码里,经常就是这些老版本。
两类相互独立的事故样本在同一时段公开:一份来自生产事故的事后复盘,一份来自正式基准的对照实验,两者指向同一个工程结论——OpenAI、Anthropic 这两家头部厂商的 Coding Agent,在写代码时不调用、或者调用错了对已知漏洞的检查。事故样本里,在真实的部署里被攻击者利用;基准样本里,在标准化的 CVE 测试集上显著落后于专业工具。这两条独立证据足以说明,这个偏差不是个例,是当前 Coding Agent 能力边界的一个稳定缺口。
事故样本:从 AI 生成到被攻击利用的真实链路
2026 年 3 月公开的一份事故复盘,记录了从 AI 生成代码到真实被攻击利用的完整链路。这份复盘的当事团队用主流 Coding Agent(包括 Claude Code 和 OpenAI Codex)生成了一整套 Next.js 应用,应用按预期工作、功能测试全部通过、团队对此满意。但在生产部署后不到几小时,自动化扫描器报告了一个严重漏洞——CVE-2025-29927,这是一个 Next.js 的中间件绕过漏洞,允许攻击者绕过中间件保护直接访问内部端点。
漏洞的根因是 AI 在生成代码时,把一个已知有漏洞的 Next.js 依赖版本固定在了 package.json 里。AI 生成的代码功能完整、测试通过,没有任何功能性 bug;但依赖版本是老的、带漏洞的版本。自动化扫描器在几小时内就发现了这个漏洞,而功能测试团队没有发现,因为功能测试只验证代码逻辑,不验证依赖安全性。攻击者利用这个漏洞绕过了中间件保护,直接下载并执行了挖矿程序,生产服务器 CPU 持续接近 100%,直到运维团队介入才发现并修复。
这份事故复盘里有一条值得专门指出的工程教训:"AI 增加了开发速度,但也增加了每次部署的安全债务。传统开发里,版本会被人工仔细检查;用 AI 生成脚手架时,这一步很容易被忽略。" 这条教训的工程含义是,Coding Agent 的代码生成能力是"双刃剑"——它能在几小时内生成一个完整应用,但同时也会引入一类传统开发里没有的、依赖版本相关的系统性安全风险。这条风险无法靠功能测试捕获,只能靠专门的依赖审计捕获。
基准样本:OpenSSF CVE 评测上的系统对照
同一年稍早些时候公开的另一份独立工程实验,在一个标准化的公开基准(OpenSSF CVE Benchmark,200 多个真实 JavaScript/TypeScript 漏洞)上对多种代码审计工具做了系统对照。这个基准的特点是,所有漏洞都是真实存在的、已经在 CVE 数据库里登记的、有官方修复版本对照的——不是合成的、不是模拟的。
对照实验的具体结果有几个清晰的工程信号。第一,纯 LLM 工具(包括 Claude Code)在 OpenSSF CVE 基准上的准确率大约 71.5%——比传统静态扫描器 Semgrep CE 的 56.9% 高出 14.6 个百分点,但比专用安全扫描工具 Cursor Bugbot 的 74.5% 低 3 个百分点。这意味着 LLM 在漏洞识别上有进步,但还没有超过专用工具。第二,纯 LLM 工具在误报率上显著偏高——它的 F1 分数 62.99% 远低于 Cursor Bugbot 的 77.42% 和 Semgrep CE 的 38.26%。这意味着 LLM 倾向于"宁可误报不可漏报",这对生产环境是负担。第三,把 LLM 和静态扫描器组合起来的混合架构,准确率可以推到 81.2%、F1 推到 80.0%——同时超过纯 LLM 和纯静态扫描器,这是混合架构相对单一架构的核心优势。
这份对照实验背后有一个独立观察值得专门讲清楚:"LLM 在漏洞识别上的失败,大部分发生在 LLM 被代码风格问题分散注意力时。" 这条观察在工程上指向一个具体设计模式——如果 LLM 在做漏洞审查时,先接收静态扫描器的高精度信号作为"锚点",LLM 就可以跳过代码风格的细节,直接聚焦在被静态扫描器标记过的可疑区域,显著提升漏洞识别的精度和召回。这套"静态+LLM 混合"模式,正是基准里 81.2% 准确率的实现路径。
为什么 Coding Agent 漏报 curl 之类已知漏洞
把事故样本和基准样本合并,可以提取 Coding Agent 漏报已知漏洞的三个具体工程原因。
第一个原因是训练数据的"时间断点"。Coding Agent 训练时见过的"标准代码"样本里,经常包含某个老版本的依赖——这在当时是合理的代码,但训练截止日之后漏洞被披露时,模型并不会自动更新"标准代码"的认知。结果是,模型在生成新代码时,倾向于沿用训练时见过的"标准版本",而这些版本恰好就是已披露漏洞的版本。这条原因对所有训练截止日之后披露的 CVE 都成立,不限于 curl,也不限于特定厂商。
第二个原因是"代码能跑"的反馈偏差。模型在生成代码后,Coding Agent 流程里的反馈信号是"代码能编译、测试能过、运行正常"——这些反馈都是正向的,不会告诉模型"你用的依赖版本是有漏洞的"。结果是,模型根据"代码能跑"这个反馈调整自己的代码偏好,反而把"使用老版本依赖"这个模式固化了。这条原因在传统开发里也存在,但人会被 code review 拦住,AI 不会主动要求做这件事。
第三个原因是"提示词不要求"。Coding Agent 的提示词通常包括"实现这个功能"、"写一个干净的代码"、"通过单元测试",但很少包括"用最新版本的依赖"、"避开已知 CVE"、"检查依赖安全"。模型在没有被明确要求时,不会主动做这些事。结果是,提示词里没写的事,模型就不会做。这条原因是最容易修复的——只要在提示词里加上"使用最新安全版本"这一条,就能消除大部分这类漏洞,但默认提示词都不会加。
供应链治理的工程新基线
把上述分析汇总,可以画出 Coding Agent 时代供应链治理的工程新基线。这条基线由五条构成,缺一不可。
第一条,依赖审计必须自动化。任何 Coding Agent 项目都必须有自动化依赖审计,审计工具扫描所有依赖项、检查已知漏洞、阻止已知有漏洞的版本被引入。审计必须在 PR 阶段执行,而不是在生产部署之后;审计必须自动阻断,而不是只警告;审计规则必须基于权威漏洞数据库(OSV、NVD、GitHub Advisory),而不是基于模型自己"认为"的判断。这条基线把"已知漏洞在生产前被阻断"作为硬约束,而不是作为最佳实践。
第二条,模型审计必须与静态扫描器组合。纯 LLM 的漏洞识别能力在公开基准上落后于专用安全工具,但 LLM + 静态扫描器的组合架构显著优于两者各自独立。这条基线意味着,Coding Agent 写完代码后,不能直接把代码交给用户,必须先经过静态扫描器的高精度锚点,再交给 LLM 评审被标记的区域;两个步骤的顺序是固定的,不能跳过任意一步。这条基线解决了 LLM 在"代码风格问题分散注意力"上的失败模式。
第三条,提示词必须显式要求最新安全版本。Coding Agent 的提示词模板里必须包含"使用最新安全版本"、"避开已知 CVE"、"检查依赖安全"这类硬性约束,不能依赖模型自己推断。这类约束应当由治理侧集中管理,不能由工程师各自决定;工程师在写提示词时,这些约束会自动注入,不需要手工追加。这条基线解决了"提示词不要求"这个最容易修复的原因。
第四条,部署环境必须隔离。即便前三条都做到,仍然会有漏洞进入生产——攻击面总是存在;部署环境隔离是兜底。具体来说,每个应用跑在独立的容器/沙箱里,容器之间网络隔离,任何漏洞利用都局限在单个容器,不会传染到宿主或其他容器。这条基线对应着事故样本里"被攻击者利用后整个生产服务器受影响"的实际后果——如果当时容器之间有网络隔离,挖矿程序最多影响单个容器,不会持续消耗整个宿主 CPU。
第五条,运行时必须监控。即便前四条都做到,漏洞仍然可能绕过审计进入生产;运行时监控是最后一道防线。运行时监控应当包括异常进程检测、异常网络连接检测、异常资源消耗检测——任何偏离正常模式的运行时表现都应该被自动告警并隔离。这条基线对应着事故样本里"CPU 持续接近 100%"的诊断过程——如果运行时监控告警,事故能在分钟级而不是小时级被识别。
从 Coding Agent 供应链推到企业 Agent 全景
把视野拉宽到企业 Agent 全景,供应链治理的工程基线具有普遍意义。任何企业内部使用 Coding Agent 或类似能力的 Agent 生成代码——不只是写应用,也包括写 ETL、配置 IaC、写测试——任何最终都要进入生产环境的代码,都面对同一组"已知漏洞被 AI 写入"的风险。这条风险不是 Coding Agent 独有的,是所有"AI 自动生成代码"系统的共性问题。
企业 Agent 治理负责人现在应当把 Coding Agent 供应链治理的工程新基线作为整个企业代码供应链治理的样板工程。具体来说,"依赖审计自动化、静态扫描器与 LLM 组合、提示词硬性约束最新版本、部署环境隔离、运行时监控"这五条规则应当通用化,覆盖企业内部所有 Agent 生成的所有代码路径,而不是只针对 Coding Agent。每一条规则对应一个独立的工程组件——可以是 SCA 工具、可以是 Semgrep + LLM 评审、可以是治理侧集中维护的提示词模板、可以是 Kubernetes namespace 隔离、可以是 Falco 这类运行时监控——实现形式各异但原则一致。
企业 Agent 治理负责人现在必须回答的三个问题
面对上述基线,企业 Agent 治理负责人现在至少要直接回答三个问题。第一个问题:你企业内部 Agent 生成的代码,有没有自动化的依赖审计?如果有,审计规则覆盖了哪些已知漏洞数据库;如果没有,漏洞会随代码生成一起进入生产。
第二个问题:你企业内部 Agent 生成的代码,有没有经过 LLM + 静态扫描器的组合审查?如果有,审查是在 PR 阶段执行还是人工 review 时执行;如果没有,纯 LLM 评审的漏报率会和基准样本一样,在已知 CVE 上有显著盲点。
第三个问题:你企业内部 Agent 生成的代码,部署环境之间有没有网络隔离、运行时有没有异常告警?如果有,单个应用的漏洞利用局限在单个容器;如果没有,漏洞一旦被攻击者利用,会扩散到整个生产基础设施。
结语
Coding Agent 的能力边界在过去一年被显著推前,从"按 prompt 写代码"演化到"按 prompt 自主完成复杂任务"。每推前一步,工程侧的供应链治理基线就必须同步推前一步。把"Agent 生成的代码不需要审计"作为主要假设的部署,在事故样本里被反复证伪。把"依赖审计自动化、静态扫描器与 LLM 组合、提示词硬性约束最新版本、部署环境隔离、运行时监控"作为基线,重新设计供应链治理方案,是当下能落地的工程基线。
任何企业 Coding Agent 项目,只要涉及代码生成、依赖引入、生产部署,工程基线就必须做到这五条——依赖审计自动化、静态扫描器与 LLM 组合、提示词硬性约束最新版本、部署环境隔离、运行时监控——否则,今天不是某次已知漏洞被攻击的主角,也会是下一次的主角。
