会员专区

AI开始批量寻找0-day：软件漏洞治理如何应对机器规模的发现能力

, , , , , , ,

摘要：漏洞发现智能体开始把代码理解、静态分析、模糊测试和复现验证串成自动流水线。发现吞吐快速提升后，误报确认、协调披露、补丁回归和下游升级成为新的安全瓶颈。

AI开始批量寻找0-day：软件漏洞治理如何应对机器规模的发现能力

2026年8月，Z.ai 发布 GLM-5.3，把网络安全能力放到了模型更新的显眼位置。官方称，团队从 GLM-5.2 时期起与多家安全机构合作扫描真实代码库，经专家复核、筛选和去重后，建立了一个覆盖269个开源项目的漏洞账本。账本当前显示2436条发现，其中1097条被标为严重或高危，53条已经公开，其余仍处于披露流程中。[1][2]

这些数字很抓人，也需要克制使用。2436和1097目前主要来自Z.ai自己的发布材料与账本，大量条目仍在embargo（披露禁运）状态，外界看不到复现脚本、厂商确认、去重规则和影响版本。发布页还把1097写成“medium-to-high”，账本的分布却是107个Critical加990个High，口径存在一处明显不一致。更稳妥的表述是：Z.ai声称其模型参与了大规模漏洞发现，部分公开案例已有独立CVE记录支撑，但总量尚未得到外部逐项核验。

抽样结果足以说明趋势并非发布会幻觉。FreeBSD的CVE-2026-45253由FreeBSD CNA发布，记录明确致谢使用Z.ai GLM-5.1的清华大学研究人员；该漏洞可让无特权本地用户借ptrace参数校验缺失触发内核代码执行。GStreamer的CVE-2026-59691由Red Hat CNA确认，记录致谢Clouditera、绿盟和Z.ai Security。另一方面，Z.ai账本列出的若干CVE虽能在官方库中找到，CVE记录并未注明AI归因；还有编号在核验时尚无公开记录。53个公开条目不能自动为其余2383个背书。[3][4]

“发现”也不应直接换算成“0-day”。一个候选可能是重复报告、不可达代码、仅在异常编译选项下出现的崩溃，或维护者已知但尚未公开的问题。0-day还涉及此前未知、缺少可用修复以及攻击窗口等条件。CVE只是编号体系，不代表漏洞必然严重，更不证明可稳定利用。

AI批量发现漏洞后的验证披露补丁与下游升级治理流程

漏洞发现智能体如何工作

今天的漏洞智能体更接近一支自动化研究小组：先读仓库历史和架构，标记外部输入、危险操作与信任边界，再调用编译器、代码搜索、调试器、sanitizer、测试框架和容器，反复生成假设、构造输入、观察失败、修正路径。模型负责语义推理和任务编排，工具负责提供可重复的事实。

静态分析适合做广度搜索。它能沿调用图和数据流追踪用户输入，寻找越界访问、命令注入、路径穿越、鉴权遗漏，也能从一次补丁反查同类变体。它的弱点同样清楚：宏、动态分派、框架约束和运行时配置会制造大量“看起来可疑”的路径。

动态分析负责把候选压成证据。固定源码提交、依赖和构建参数后，用ASan、UBSan、MSan、KASAN或调试器复现崩溃，记录最小输入、栈、根因和受影响版本。没有这一步，一份语言流畅的报告仍只是推测。

Fuzzing则提供高吞吐的输入探索。它已在开源生态运行多年；OSS-Fuzz截至2023年已帮助发现并修复上万项漏洞。瓶颈常常落在fuzz harness是否覆盖了目标代码、语料能否通过复杂语法、字典是否包含关键令牌。Google Project Zero披露的Big Sleep案例很典型：智能体在SQLite中找到一个此前未知的可利用内存问题，已有测试与OSS-Fuzz都没有命中；研究者随后让AFL运行150个CPU小时仍未发现，原因与构建配置、扩展未启用及覆盖率反馈不足有关。[5][6]

模型和fuzzer的长处可以拼接：模型生成或修复harness，理解文件格式与协议状态，构造语法有效的种子；fuzzer负责大规模变异和确定性触发；智能体再做根因分析、变体搜索与报告整理。高质量流水线还会让独立验证器在干净环境重放PoC，避免同一个模型既提出漏洞又独自宣布成立。

运行环境也必须按恶意代码实验室来设计。被扫描仓库、依赖安装脚本和智能体生成的PoC都不可信，研究节点应采用容器与虚拟机多层隔离，限制网络出口、凭据、文件挂载和内核能力，并保存完整操作日志。否则，批量扫描可能触发仓库中的供应链恶意代码，或让生成的利用样例越过测试边界。发现规模扩大后，权限最小化和证据保全会成为流水线的基础设施，而非附加选项。

从崩溃到exploit chain

能触发异常，与能完成攻击相隔很远。内存破坏要继续判断数据是否可控、能否形成稳定读写原语、是否需要地址泄露；Web漏洞要检查身份、租户和部署前提；浏览器漏洞还可能面对渲染器沙箱与内核边界。GLM-5.3官方给出的ExploitBench成绩虽然较上代翻倍，仍低于其列出的两款闭源模型，也提醒我们不要把“找到了代码缺陷”写成“已经获得远程代码执行”。[1]

更棘手的是组合能力。浏览器中的中危越界读、沙箱中的权限错误、内核中的释放后使用，单独看都可能受限，串起来却可能形成完整链条。智能体可以跨仓库检索相邻组件、自动搭建多个版本并长时间试错，exploit chain的搜索成本会继续下降。防守方因此需要把链条信息纳入优先级：可利用性、外网暴露、所需权限、资产关键性、是否存在在野利用，都比单看CVSS更接近实际风险。

披露系统会先遇到吞吐危机

机器可以并行扫描数千个仓库，维护者仍要逐份读报告、复现、判断影响、写补丁、回补旧分支、发版本和公告。OpenSSF漏洞披露工作组已把低质量AI报告形容为对维护者的“DDoS-like”压力，并记录了curl、Node.js等项目提高门槛或调整漏洞计划的情况。[7] 当报告数量骤增，缺少证据的自动投稿会消耗最稀缺的资源：熟悉代码和威胁模型的人类时间。

报告入口需要机器可读的准入门槛。最低证据包应包含精确commit、可重复构建环境、最小PoC、sanitizer或调试日志、受影响与不受影响版本、威胁前提、根因位置、去重指纹，以及回归测试或补丁候选。提交者应披露AI参与方式，并由可联系的人类复核者承担质量责任。平台可以限速、按项目容量分批投递，让验证充分的少量高风险问题先进入队列。

确认环节还应有明确的否证路线。静态报告声称存在越权时，要证明攻击者确实能到达该接口，且上游代理、框架中间件或默认配置没有阻断；崩溃报告要区分断言失败、拒绝服务和可控内存破坏；依赖漏洞要验证易受攻击函数能从下游应用到达。将这些检查自动化后，智能体可以先淘汰一批表面合理的误报，把维护者的注意力留给仍有完整证据链的候选。

responsible disclosure也要从单封邮件升级为流水线。项目应维护SECURITY.md和私密报告入口；协调方按“已复现、已确认、修复中、补丁可用、公开”管理状态。CERT/CC强调，参与方越多，供应链协调和保密越困难。Project Zero的90+30政策提供了一种时间框架，但几千条发现若机械套用同一截止日，只会制造披露拥塞。embargo应结合严重度、在野利用、维护资源和下游扩散范围分层，必要时引入CERT/CC、CNA或基金会充当协调者。[8][9][10]

补丁发布只是治理中段

智能体生成补丁的速度也会上升，合并前仍需双向验证：原PoC必须失效，正常功能与性能不能回退；随后扫描相邻调用点和同类变体，检查修复是否只遮住一个触发条件。OSS-Fuzz已经实践了修复后自动重放并关闭问题的机制，这类门禁应进入普通CI。[6]

开源供应链还会放大传播时差。上游主干修复后，长期维护分支、Linux发行版、容器基础镜像、设备固件和私有vendoring副本可能数月未更新。企业需要用SBOM、包URL、锁文件和可达性分析定位受影响资产，同时记录“发现—确认—上游修复—下游发布—生产部署”各阶段耗时。治理指标也应从收到多少CVE，转向高风险问题的确认时长、补丁覆盖率和暴露窗口。

商业使用方也不能把处置成本全部留给志愿维护者。大规模扫描机构可以随报告提供复现工程师、补丁草案、回归测试和长期分支回补；大量依赖某个组件的云厂商与设备厂商应投入维护资金或专职安全人员。机器发现带来的安全收益覆盖整个下游生态，相应的人力与算力成本也需要沿供应链共同承担。

漏洞发现能力正在进入机器规模，处置能力却仍按人工工单设计。接下来最有效的投入会落在验证、协调和补丁传播：让智能体交付可重放证据，让披露平台保护维护者带宽，让下游用户能够迅速判断自己是否可达、何时完成修复。找到更多缺陷当然有价值；只有把发现稳定地转成修复，防守方才会获得持续优势。

来源

  1. Z.ai, GLM-5.3: Frontier Coding with Emergent Cyber Capabilities：https://z.ai/blog/glm-5.3
  2. Z.ai Security Disclosure Ledger：https://cvd.z.ai/
  3. CVE Program, CVE-2026-45253：https://cveawg.mitre.org/api/cve/CVE-2026-45253
  4. CVE Program, CVE-2026-59691：https://cveawg.mitre.org/api/cve/CVE-2026-59691
  5. Google Project Zero, From Naptime to Big Sleep：https://projectzero.google/2024/10/from-naptime-to-big-sleep.html
  6. Google OSS-Fuzz, Architecture：https://google.github.io/oss-fuzz/architecture/
  7. OpenSSF Vulnerability Disclosures WG, issue #178：https://github.com/ossf/wg-vulnerability-disclosures/issues/178
  8. CERT/CC, CERT Guide to Coordinated Vulnerability Disclosure：https://certcc.github.io/CERT-Guide-to-CVD/print_page/
  9. Google Project Zero, Vulnerability Disclosure Policy：https://projectzero.google/vulnerability-disclosure-policy.html
  10. GitHub, What to do when you receive a vulnerability report：https://github.blog/security/vulnerability-research/a-maintainers-guide-to-vulnerability-disclosure-github-tools-to-make-it-simple/
分享到