这周做后端的朋友应该都被刷屏了：Fastjson 又曝出 9.8 分的远程代码执行漏洞（CVE-2026-16723），PoC 已经公开，全网批量扫描已经开始；紧接着 Redis 的补丁绕过漏洞（CVE-2026-23479）也把 EXP 放了出来；GitLab、用友 U9Cloud 各有一个高危在列。知乎专栏知乎专栏
更扎心的是 Fastjson 这条。很多人第一反应是"我早就不用 Fastjson 了"，但它很可能正以间接依赖的形式躺在你 Spring Boot 项目的依赖树里，你压根不知道。用 `mvn dependency:tree` 搜一下，版本落在 1.2.68~1.2.83 之间的，就得处理。知乎专栏
这件事本身够写一篇快讯了。但我想借这波多聊一层：如果你的项目里有相当比例的代码是 AI 写的，那么"组件出漏洞"和"代码有漏洞"这两件事，正在以比以往快得多的速度同时发生。这篇文章把最近一周密集出现的研究报告、工具实测和行业数据整理到一起，回答一个问题——AI 写的代码，上线前到底该怎么扫。
先看数据：AI 写代码的安全成绩单，比想象的难看
最近几个月有几份研究，结论互相印证，放在一起看冲击力不小：
应用安全公司 Veracode 过去一年做了四轮测试、覆盖 100 多个模型版本，发现 44% 的 AI 生成代码至少包含一个 OWASP Top 10 已知漏洞。表现最好的前沿模型，安全通过率也没超过 68%。知乎专栏更值得注意的是：四轮下来，平均安全通过率几乎没有提升——而同一批模型的语法正确率高达 99%。用 Veracode 首席安全布道师 Chris Wysopal 的话说：“它们写漏洞利用代码越来越强，却写不出更安全的代码。”
荷兰软件质量公司 SIG 的《2026 年软件状况报告》测试发现，AI 生成代码的安全风险违规大约是人工代码的两倍，而且所有代码里有 71% 的安全控制程度偏低。他们 CTO 的说法很克制也很到位："AI 不是问题的制造者，而是放大器。"在有质量度量基础的企业，AI 加速交付；在没有基础的地方，AI 只是加速技术债和安全暴露。
Theori 旗下 Xint.io 的研究人员 7 月用 Anthropic 和 OpenAI 的 5 款新模型 vibe-coding 出 28 个应用变体，验证出 434 个安全缺陷——既有密钥硬编码这类老问题，也有"代码能跑、规模化就出事"的隐性坑。他们观察到的一个原因很真实：开发者下需求时只要功能，很少同时要求"加上安全护栏"。
修复端也不乐观。1Password 的 Off-By-1 实验室针对复杂开源项目的 6 个已知漏洞，跑了 6000 多次测试：模型生成的补丁能完全解决漏洞、又不改变应用行为的平均成功率只有 26%。知乎专栏超过一半的补丁要么没修好，要么引入了新漏洞。他们还发现一个结构性问题——模型的注意力机制让它往往只修补 PoC 触发的那一条代码路径，对相邻路径上字符级几乎相同的同类漏洞视而不见。
把这几组数据翻译成人话：模型的默认优化目标是"让代码能运行"，不是"让代码安全地运行"。这两个目标大部分时候不冲突，但在安全边界上存在系统性偏差。你的 AI 助手每多写一万行代码，这个偏差就多沉淀一分。
再看另一边：AI 找漏洞的能力，已经跑到前面了
有意思的是，同一批技术在进攻端完全是另一个故事。
有知乎安全从业者实测整理：OpenAI 的 Codex Security 扫了 120 万次 commit，找出 1 万多个高危问题，误报率比传统扫描器低一半以上（但深度绑定 OpenAI 生态，国内用不了）。知乎国产开源项目 AutoCVE 更直接——7 天测试期，在 14 个开源项目里挖出 30 个带编号的真实 CVE，最高 CVSS 9.9，靠的是五个专项 Agent 组成的"选目标→审代码→滤误报→写报告"流水线。知乎专栏这周的用友 U9Cloud 反序列化漏洞，就是 360 漏洞挖掘智能体复现出来的。
资本市场的嗅觉一向诚实。8 月 17 日，AI 代码审查工具 CodeRabbit 完成 1.43 亿美元 C 轮，估值超过 15 亿美元（约 108 亿人民币）。36氪它披露的两个数字值得记住：今年代码提交量预计达到往年的 14 倍以上；在编码智能体渗透率前 10% 的企业里，35% 的 PR 已经由自主智能体生成。
于是一个清晰的图景出现了：AI 一边以历史新高密度制造带漏洞的代码，一边以前所未有的速度发现漏洞。漏洞检测的瓶颈，已经从"发现不了"悄悄变成了"判断不过来"。
极狐 GitLab 在介绍自家 AI 安全能力时的开场白很能代表一线体感："团队不再担心发现不了漏洞，而是担心漏洞来得太密、读得太多、跟得太慢。"一次合并请求可能触发十几个 SAST 高危提示，中大型项目每周可能产生上百条高危告警，其中相当一部分是误报或低优先级噪声。知乎专栏每条都人工排查，安全团队会被淹死在工单里；全部忽略，就是赌博。
所以现在的真问题不是"要不要上 AI 检测"，而是：检测做了一堆，谁来做最后那个判断？
三个最容易踩的坑
坑一：让写代码的 AI 给自己打分。
很多团队的现状是 Cursor 写完代码，再问一句同一个助手"这段代码有没有安全问题"，得到一句"看起来没问题"就合并了。这相当于让考生自己批卷。多位受访专家的一致建议是：保留现有的安全控制措施，把 AI 代码审查当作补充，而不是替代品。AI 发现的候选问题，要经过入口可达性、触发条件、影响资产的验证才算数——AI 负责发现，工具和人负责证明。
坑二：把 AI 生成的补丁直接当修复完成。
26% 的完全修复率上面说了，再补一个实测：有开发者用开源审计工具 DeepAudit 扫了一个 2 万行的开源项目，10 个发现里只有 2 个是工具自己写攻击脚本在沙箱里跑通的真漏洞，其余 8 个是"疑似"。知乎工具方把没跑通的老实标成"未验证"，这个设计值得点赞——它承认了 AI 检测输出的正确形态是"待判断的候选清单"，不是"漏洞结论"。对 AI 补丁同理：收下的每个 AI 补丁，至少要重新跑一遍相关测试，并检查相邻代码路径有没有同类问题。
坑三：只盯着自己写的代码，不看依赖树。
这周的 Fastjson 就是活教材：你不用它，你的依赖可能在用。Redis 那个补丁绕过也一样，8.10.0<=Redis<8.10.18 的版本区间，很多人升过一次就以为自己安全了。知乎专栏AI 时代的依赖风险只增不减——AI 助手基于历史语料训练，推荐起依赖来未必挑最新的。建议把依赖扫描从"出了事才查"变成例行动作，具体命令下面会讲。
实操：一套按团队规模裁剪的检测组合
先做两个判断题，再抄作业：
判断题一：你的代码能不能出域？ 代码本身是核心资产（自研引擎、核心算法），或者公司有明确信息安全规定——只能本地部署模型和本地扫描器。普通 B/S 业务系统，代码价值不高但数据安全重要，用云端 API 做审计是一笔算得过来的账。另外别忘了：如果你已经在用 Cursor、Copilot 这类工具，代码本来就已经在云端走过一轮了。
判断题二：你要防的主要是什么？ 依赖漏洞（Fastjson 型）、常见注入（OWASP 型）、还是业务逻辑缺陷（架构型）？三者的主力检测手段完全不同。
三个人的小团队，最小可用组合：
第一层，生成端加约束，成本半天以内。在 AI 助手的配置文件里加入安全约束模块，要求参数化查询、输入校验、禁止硬编码密钥等。微软、Google、Red Hat 主导的 OpenSSF 在 2025 年 9 月发布的《AI 代码助手安全配置指南》测量过：系统提示嵌入安全约束后，安全代码通过率从 56% 提到 66%；有学术测试在特定模型上加安全感知 Prompt 后，安全通过率从 13.83% 提到 39.89%。知乎专栏有知乎开发者实测，给 CLAUDE.md 加 30 行安全约束后，AI 生成接口时开始自动带上输入验证和参数化查询。这是性价比最高的一步：漏洞在产生时就被掐掉一部分，比事后扫描便宜得多。
第二层，确定性门禁，拦截已知模式。两件事：一是依赖扫描，Java 项目在项目根目录跑 `mvn dependency:tree | grep fastjson`（npm 项目用 `npm audit`），把 Fastjson、Redis 这类本周热点先排掉；二是 SAST 双轨——Semgrep 挂 PR 门禁，秒级出结果，拦 SQL 注入、XSS、硬编码密钥这类已知高危模式；CodeQL 放夜间深扫，跑完整数据流分析抓跨模块漏洞链。规则引擎的误报可控、结果确定，是流水线里最不该省的一环。知乎专栏
第三层，AI 审查当"第二意见"。这一层才轮到 AI 发挥它的语义理解优势：传统规则扫不出的配置错误和逻辑漏洞，正是 AI 的强项。选项包括 GitLab Duo 的漏洞解释与误报检测（给每条告警配自然语言解释和置信度分档）、以及 DeepAudit（重，带沙箱验证）、ARM Metis（轻，CLI 一行命令）这类开源方案。使用原则就一条：AI 出初稿、给置信度，人做终审。涉及敏感代码的场景，选支持本地模型的方案，代码不出内网。知乎专栏
十人以上的团队，在这个骨架上补两个动作：给 AI 告警做分诊排序（外部可达性、权限要求、业务影响、是否已有在野利用），别把所有告警都当高危处理，否则只是把"漏报"换成"告警爆炸"；以及把每次修复沉淀成回归测试和扫描规则，让同一类漏洞不出现第二次。
接下来值得盯的信号
三件事值得放进你的关注列表：
一是 AI 补丁的"人机协作"范式。OpenAI 和 Trail of Bits 合作的 Patch the Planet 项目，让 AI 在专门搭建的安全工作流里给关键开源基础设施找漏洞、写补丁，截至 8 月 11 日已记录 1250 个问题、提交 271 个修复，其中 146 个被上游接受。知乎专栏"AI 找、AI 修、人审、上游验收"这条链路正在被验证。
二是"补丁半衰期"在变短。NDSS 2026 的一项研究显示，大模型分析 5140 个 Linux 内核补丁，能筛出 111 个疑似修复内存安全问题的提交，其中 90 个经人工确认属实。知乎专栏意思是：补丁本身就是浓缩的漏洞情报，AI 正在批量读懂补丁、反推漏洞、搜索变体。对你的实际影响是——高危补丁发布后的窗口期比以前短得多，打完补丁之后多做一步：在自己代码库里搜同类写法。
三是国产开源生态。AutoCVE（AGPL-3.0）这类多智能体漏洞挖掘项目刚起步就交出了 7 天 30 个 CVE 的成绩，值得关注它的迭代；360 漏洞挖掘智能体这周连续产出用友、Redis 等漏洞情报，国产 AI 漏洞检测的实战化节奏比很多人以为的要快。
最后
AI 把代码产量拉上去的同时，并没有降低漏洞密度——这就是眼下最基本的现实。漏洞检测要跟上，靠的不是再堆一个扫描器，而是把分工摆对位置：约束在生成端，确定性规则在门禁，AI 做语义补充，人做最终判断。
今天就能做的三件事：跑一遍依赖树，把 Fastjson 和 Redis 排掉；给你的 AI 助手配置加上安全约束；给 PR 挂一条最简单的 Semgrep 规则。漏洞不会等你准备好。
