AI 开始替人审代码了：Chainguard Harness 发布，首战挖出 vLLM 真漏洞

今天（2026 年 10 月 14 日），开源供应链安全公司 Chainguard 发布了一个新产品：Chainguard Harness。一句话概括——它把"用前沿 AI 模型找漏洞"这件事，从少数机构才能玩的研究，变成了一个可以购买、按流程交付的服务：模型在隔离的 microVM 里对你运行中的应用做漏洞猎杀，只交付可复现的漏洞，每条都附带可直接合并的修复。

先澄清一个容易混淆的点：这个 Harness 不是 DevOps 公司 Harness.io（那家上周刚收购了 Augment Code，本站发过），而是 Chainguard 的新产品。名字撞车，赛道完全不同。

而在发布前一天，Chainguard 已经先亮出了 Harness 的"首个公开战绩"：它在开源大模型推理引擎 vLLM 里挖到了一个真实漏洞——一个在 issue tracker 里躺了四个半月、被标记为"普通 bug"、官方评级为 Low 的问题。AI 猎手只用了一次运行，就把它从"普通 bug"升级成了安全事件。

Harness 是怎么工作的

根据 Chainguard 官方新闻稿（美东时间 10 月 14 日凌晨发布），Harness 的核心是一个"模型 + 脚手架"的流水线，整个流程分六步：

第一步，接入代码。客户通过 Chainguard 的 GitHub App（Guardener，只读权限）连接仓库，或者直接上传源码包。注意是只读——Harness 从一开始就不拿写权限。

第二步，构建。一个独立的"setup 模型"负责把应用按真实发布形态构建出来、拉好依赖和工具链、跑起来，然后把整个 microVM 挂起。构建和猎杀是两个模型、两个阶段，这是刻意为之的隔离设计。

第三步，猎杀。microVM 恢复后，Anthropic 的 Claude Mythos 5.1 开始探查这个运行中的应用。它手里有源码、git 历史、依赖源码、构建配置，同时观察应用运行时的真实响应，寻找逻辑缺陷、注入漏洞和资源耗尽问题。这个阶段的隔离条件非常严格：microVM 没有网络出口、内部没有任何凭据，模型只有 shell 和 Chainguard 构建的软件包可用；agent 的循环跑在沙箱之外，模型发出的每一个 tool call 和命令都被完整记录。更关键的一句：被测代码被视为不可信数据——这是为了防住藏在被分析代码里的 prompt injection，反过来劫持猎手模型。

第四步，复现验证。这是整个产品最有含金量的一步：每一个 finding 都要在全新的隔离环境里重放，直到每次都能复现，复现不了的不会出现在报告里。修复的验证同样严格——exploit 必须在客户当前代码上成功、在打上修复后失败。

第五步，人工审核。一位具名的 Chainguard 工程师在交付前逐条审核每份报告和每个修复。

第六步，交付。报告包含执行摘要、每条漏洞的严重性与影响、复现步骤，以及为客户代码库量身写的修复。如果漏洞出在开源依赖而非客户自己的代码里，Chainguard 会通过自家的协调披露流程 Athena 把漏洞交给上游维护者，解决后经 Chainguard Repository 发布打好补丁的构建。

商业上，Harness 目前只开 beta waitlist，发布初期全程由 Chainguard 工程师代为操作。值得注意的一个细节：它上架了 Claude Marketplace by Anthropic——Anthropic 负责开票，企业客户可以直接用已有的 Anthropic 采购额度购买。安全能力开始跟着模型厂商的账单走了。

首个公开战绩：在 vLLM 里挖到的跨请求污染

10 月 13 日，Chainguard 发表研究帖，公开了 Harness 的第一个公开 finding：vLLM 的 allowed_token_ids 漏洞。

allowed_token_ids 是一个请求参数，用来限制模型本次请求可以生成哪些 token。漏洞的机理很干净：在共享的限制表里，当一个请求结束、它占用的行被重分配给后续请求时，旧的限制没有被清空——于是后来的请求继承了上一个客户端的 token 限制。在共享推理引擎上，这意味着一个客户端可以操纵另一个客户端请求的输出。

时间线值得细看：

2026 年 5 月 28 日，这个问题就以"普通 bug"的身份进入了 vLLM 的公开 issue tracker，在那里躺了四个半月。9 月 23 日，Chainguard 向 vLLM 维护者报告了它的安全影响；10 月 2 日修复随 v0.31.0 发布；10 月 6 日安全公告 GHSA-6cxc-2vcg-w5qc 公开；10 月 13 日 Chainguard 发表研究帖，把它作为 Harness 的首个公开战绩。vLLM 官方给这个问题的评级是 Low，而修复本身只是一行代码改动加一个相关修复。Chainguard 称 exploit 复现成功率是三投三中。

这次运行的统计数字也很说明问题：单次运行耗时 10 小时 48 分钟，处理了约 1.15 亿 token，探查了项目的 30 个部位；37 个候选 finding 在干净主机上复现成功，13 个通过了工程评审。Chainguard 还披露，Harness 已在 65 个以上项目上跑过，验证了 680 多个 finding，其中一部分正在走协调披露。

判断一：攻防的天平正在倾斜，"写得快"不再是护城河

官方新闻稿的标题很直白："Finding vulnerabilities is no longer the hard part"（找漏洞不再是难事）。CEO Dan Lorenc 在稿子里说，每次把 Harness 指向代码，它都找到了严重的、可利用的漏洞——包括那些"已经被扫描过很多遍"的软件和跑着关键基础设施的代码。

这句话至少有一半是营销口径：样本是 Chainguard 自己选的，"每次都找到"存在明显的选择偏差，680 多个 finding 的分母（跑了多少次、多少项目空手而归）也没有公开。但方向是实的——AI 找 bug 的能力正在商品化。过去这是少数做关键基础设施防御的机构才有的能力（比如需要前沿模型访问权限和配套工程团队），现在它被打包成了一个"连 GitHub 仓库、等报告"的服务。

对 vibe coder 来说，这个信号比产品本身更重要：你用 AI 一天生成的代码，别人也能用 AI 一天审完。过去"写得快"是 AI 编程最大的红利；当"审"也被 AI 接管后，红利会快速贬值，新的分水岭变成"经得起 AI 审"。你的下一个 side project 上线前，不妨先问自己一句：如果有个 Harness 对着我的仓库跑一晚上，我慌不慌？

判断二：从静态扫描到运行时猎杀，是代际差

传统安全扫描仪最大的问题不是漏报，而是误报：它们分析静态代码，标出一堆"可能永远不可达"的问题，工程师花几小时 triage，最后发现是噪音。Harness 的解法很粗暴但有效——只测运行中的应用，复现不了的不进报告。

这个"可复现才交付"的标准，加上"exploit 在原代码成功、在修复后失败"的双向验证，是整篇新闻稿里工程含金量最高的设计。它把安全报告从"风险清单"变成了"可执行的修复"。Anthropic 商业网络安全负责人 Daniela Hurtado 在稿子里的话点出了关键：模型能挖出"潜伏多年"的漏洞，但"这种能力以什么方式部署，和能力本身同样重要"——隔离、复现、人工审核这三层脚手架，缺一不可。

但也要泼一盆冷水：目前 Harness 全程由 Chainguard 工程师代操作，普通开发者连排队都还在 waitlist，价格也未公布。短期内它不是独立开发者的工具，而是企业的采购项。它的真正意义是定价和交付形态——当"AI 猎杀漏洞"有了明码标价的 beta 产品，意味着这条赛道从论文和内部工具，进入了商业竞争阶段。

判断三：vLLM 案例最扎心的一课——"Low"正在被重新定义

这个案例里最值得玩味的不是漏洞本身，而是一连串的"误判"：在 issue tracker 躺了四个半月没人觉得它是安全问题；官方评级 Low；修复只用了一行代码。

站在 AI hunter 的视角看，这三个误判其实是同一个 blind spot：人类评审在用"代码改动大小"估算风险，而 AI 在用"可利用性"估算风险。一行代码的修复，对应的是"共享推理引擎上租户之间可互相操纵输出"的影响——在多租户推理服务上，这绝不是 Low。这提醒所有开源维护者：severity 评级体系可能要为"AI 视角"打补丁了，那些躺在 issue tracker 里被标记为"普通 bug"的历史遗留问题，值得用新的眼光重扫一遍。

另一面是维护者的负担。本站前几天刚发过 Anthropic 的 OSS Scanner（一文回顾：AI 免费给开源项目扫漏洞，报告不经人工审核直接发邮件）。两件事连起来看，趋势很清楚：AI 生成的漏洞报告潮正在到来，开源维护者很快要学会"接 AI 的报告"——分辨哪些是真 finding、哪些是幻觉、哪些只是换了个说法的已知问题。Harness 的"复现才报告"至少在方法论上给出了一个筛选标准。

判断四：两个生态信号，值得记在小本子上

信号一：安全产品开始搭模型厂商的分发。Harness 上架 Claude Marketplace、走 Anthropic 账单，意味着企业采购 AI 安全能力的路径变了——不再是单独的安全预算、单独的供应商谈判，而是"模型账单的一个附加项"。Claude 正在从"模型供应商"变成"AI 服务分发平台"，安全是第一批上架的品类。这对独立开发者暂时没影响，但对做安全工具创业的人是个明确的渠道信号。

信号二："Agent = 模型 + 脚手架"在这里具象化了。本站之前发过 Stack Overflow 的讨论（Agent 只占一成，模型之外全是脚手架），Harness 就是这句话的产品形态：Claude Mythos 5.1 只是"眼睛"，真正的产品是 microVM 隔离、挂起/恢复的两阶段设计、沙箱外的全审计日志、重放验证流水线和人工审核。做 AI 应用的 vibe coder 可以照抄这个思路——你的 agent 产品里，模型负责智能，脚手架负责可信，而客户愿意付钱的往往是后者。

给 vibe coder 的三条行动建议

第一，依赖项尽量用 hardened 制品。Harness 发布初期就是先对 Chainguard 自己分发的开源制品跑、再经 Chainguard Repository 发补丁构建——思路很直白：你拦不住 AI hunter 扫开源代码，但你可以选择站在"第一时间拿到补丁构建"的那一边。给项目选基础镜像和依赖时，把"安全更新速度"放进选型标准。

第二，给 AI 写的代码补上运行时安全视角。vibe coding 最大的安全债不是"代码写得丑"，而是"没人想过它跑起来是什么样子"——恰好 Harness 测的就是"跑起来的样子"。在 prompt 里给 agent 加安全约束（输入校验、最小权限、密钥不进代码），上线前至少跑一遍基础扫描，这些习惯的成本远低于一次 incident。

第三，关注 Athena 这类"AI 挖到开源依赖漏洞"的披露通道。你的项目依赖的库，可能明天就被某个 AI hunter 点名。把 npm audit / Dependabot 这类自动化依赖更新真正打开，而不是装了不用——在 AI 猎杀时代，依赖的"补丁延迟"就是你的暴露窗口。

最后说句大实话：Harness 今天还不是独立开发者的玩具，它是企业 beta 产品。但它宣告了一件事——AI 写代码的下半场，是 AI 审代码。而先被 AI 审到的，总是那些跑在共享基础设施上的开源项目。vLLM 只是第一个被公开点名的，不会是最后一个。