Semgrep基准测试：GLM 5.2超越Claude的场景启示

Semgrep基准测试：GLM 5.2超越Claude的场景启示 | 前端进阶之旅

Full translation

完整中文译文

我们使用 IDOR 基准测试评估了一组热门开源模型，采用的 dataset 和 prompt 与此前评估前沿 coding Agent 时完全相同。结果出乎意料：智谱 AI 推出的 open-weight 模型 GLM 5.2，在 IDOR 检测中取得了 39% 的 F1，超过 Claude Code（32%），平均每发现一个漏洞的成本约为 0.17 美元。它仍落后于 Semgrep 的 multimodal pipeline（F1 为 53%–61%），但这套 pipeline 运行在专门构建的 harness 中，而 harness 承担了大量工作。在只获得一个 prompt 的模型中，表现最好的 open-weight 选手不再是显而易见的弱者，它甚至击败了 Claude Opus 4.8。

说实话，我们并不是想评选出 open-weight 模型中的冠军。我们真正想回答的是一个范围更窄、也更无聊的问题：漏洞检测能力究竟有多少来自模型本身，又有多少来自包裹在模型外围的 harness？对于 Semgrep 而言，这是一个非常重要的问题，因为我们接触的许多客户都在安全任务中大量使用 AI Agent。harness 是包裹模型的一整套脚手架：它负责把 repository 提供给模型，决定模型能看到什么，解析模型输出，并驱动模型循环执行任务。我们的内部 multimodal pipeline 就运行在一个专为 static analysis 构建的 harness 中。我们已经在内部测试这套方案有一段时间了，其中包括一个用于发现 IDOR（Insecure Direct Object Reference，不安全的直接对象引用）的工作流。它们属于访问控制问题，大致可以理解为：“你正在访问属于另一个用户的东西。”

我们的 harness 会枚举应用程序的 endpoint，并通过代码筛选出真正重要的 context，再让模型直接检查这些内容。这里确实包含大量结构化辅助，但还记得我说过，我们其实并不是要回答“最好的 open-weight 模型是哪一个”吗？本次测试中的模型得不到这些辅助。它们运行在一个简单的 Pydantic AI harness 中，使用的 IDOR prompt 与我们提供给其他所有 LLM provider 模型的完全相同：没有 endpoint discovery，也没有引导式导航。我们确实给了一点点帮助，比“代码在这里，找出 bug”稍微多一些，提供了一套搜索策略，以及一些用于判断 IDOR 特征的提示。

所以，这项研究最初只是一个 prompt 与 harness 的对比实验，但在运行过程中，我们真的震惊了。其中一个 open-weight 模型在完全没有使用我们任何脚手架的情况下，超过了一个前沿 coding Agent。

编辑注，2026 年 7 月 17 日：本文发布后，我们回过头来追问了一个棘手的问题：当这些模型标记出 IDOR 时，它们真的在进行推理，还是只是在做模式匹配，寻找看起来熟悉的东西？为此，我们构建了一套专门的 grounding benchmark。简短结论是：它们的判断确实有依据，并不是靠钻 benchmark 的空子，但所有模型的 recall 仍然不够理想。阅读 grounding audit →

如果你从没听说过 GLM-5.2，也不用担心，我们之前同样没听说过。直到在社交媒体上看到它，我们才想到把它加入 benchmark。GLM 5.2 是智谱 AI（Z.ai）推出的最新模型，于 2026 年 6 月 13 日星期六率先向 GLM Coding Plan 会员开放；三天后的 6 月 16 日，open weights 和 release notes 正式发布，我们也是在那时注意到它的。它有三个特点，使其尤其值得安全领域关注。

第一，它是 open weight。这意味着模型参数以 MIT license 发布，你可以下载这些参数，在自己的硬件上运行模型、对其进行 fine-tune，也可以检查它们。对于许多处理敏感业务的安全团队来说，这一点非常重要，因为 open-weight 模型可以完全运行在自己的环境中。但需要注意，“open weight”并不等同于“open source”：公开的是训练完成后的 weights，而 training data 和完整 pipeline 通常并不公开——不过 Z.ai 确实发布了它的 RL training framework。

第二，它在 coding 方面确实很有竞争力。GLM 5.2 是一个 Mixture-of-Experts（MoE）模型，总参数量约为 7500 亿，但每个 token 只会激活约 400 亿参数，因此相对于模型规模，它能将 inference 成本控制在较低水平。它把可用 context 从 200K 一路扩展到 1M tokens。Z.ai 强调的并不只是模型能够接收更多输入，而是这些 context 在漫长、混乱的 Agent 执行轨迹中依然可靠。对安全任务来说，这一点同样重要，因为 IDOR 等安全问题要求模型能够跨越不同文件，并穿透 authorization framework 进行推理。在标准 coding benchmark 上，它交出了目前 open-weight 模型中最强的一批成绩：Terminal-Bench 2.1 得分为 81.0（GLM 5.1 为 63.5，与 Claude Opus 4.8 的 85.0 仅相差几分）；SWE-bench Pro 得分为 62.1，超过了一些闭源前沿模型，与最顶尖模型的差距也只有个位数百分点。

第三，成本。tokenomics 正迅速变得与 LLM 本身的能力同样重要。公开价格约为同等级前沿模型的六分之一，而长期跟踪 open model 的评论者，则把 GLM 5.2 引发的关注与 DeepSeek 相提并论。GLM-5.2 发布时恰逢一个高度敏感的时间点，这不仅是因为 tokenomics，还因为此前有报道称前沿闭源模型遭到 jailbreak，随后它们又受到了新的出口限制。release notes 中还有一个细节，值得所有准备让该模型分析代码的人注意：Z.ai 表示，GLM 5.2 比 GLM 5.1 表现出更多 reward-hacking 行为。在训练期间，它会读取受保护的 evaluation 文件，或者通过 curl 获取参考答案，以此抬高自己的分数，这促使团队构建了一套专用的 anti-hacking guard。这是团队一次坦诚的披露。不过，如果你要打造一个用于 hacking 的模型，那么……还有什么能比一上来就试图绕过测试更有 hacker 精神呢？

在深入细节之前，有必要先回顾一下我们究竟想做什么，以及实验具体是怎样进行的。先快速复习一下 IDOR：Insecure Direct Object Reference 是一类漏洞，应用程序会在请求中暴露 user ID 等内部标识符，却没有检查调用者是否真的有权访问对应对象。修改标识符，就能拿到其他人的数据。

@app.route('/user/<int:user_id>')
def get_user(user_id):
    user = User.query.get_or_404(user_id)
    return jsonify(user.to_dict())

这个 Flask route 直接根据 URL 中的 ID 获取并返回用户记录，却没有检查请求者是否拥有该记录。任何已登录用户只需修改 user_id，就可以读取其他人的记录。IDOR 介于业务逻辑缺陷与配置错误之间，它并不是 taint-flow bug。正因为如此，无论 static analysis 还是 LLM 都很难检测它：这里没有可以直接标记的危险函数，只有一个缺失的检查。它也是现实环境中最常见的漏洞之一——目前在 HackerOne 的热门漏洞类型榜单中排名第 4——这正是我们不断将它用作 benchmark 的原因。

回到我们的实验：按照标准实验条件，我们保持三个因素不变，只改变一个因素。保持不变的是：IDOR dataset（与此前研究中使用的真实开源应用程序相同）、评估方法（将结果与一组已知 true positive 对照并计算 F1），以及 IDOR system prompt 本身。改变的是模型及其 harness。具体如下：

Semgrep Multimodal 运行在我们的自定义 harness 中，也就是会枚举 endpoint 并引导模型检查这些 endpoint 的那一套。我们测试了两种在其背后运行的前沿模型。
Semgrep Multimodal 运行在我们的自定义 harness 中，也就是会枚举 endpoint 并引导模型检查这些 endpoint 的那一套。我们测试了两种在其背后运行的前沿模型。
但我们也通过 Claude Code SDK 直接运行了 Claude Code，并通过其他 provider 各自的原生 SDK 运行其模型，所有模型使用相同的 prompt。
但我们也通过 Claude Code SDK 直接运行了 Claude Code，并通过其他 provider 各自的原生 SDK 运行其模型，所有模型使用相同的 prompt。
包括 GLM 5.2、MiniMax M3 和 Kimi K2.7 Code 在内的 open-weight 模型，都运行在简单的 Pydantic AI harness 中，除了 IDOR prompt 之外没有任何其他辅助。
包括 GLM 5.2、MiniMax M3 和 Kimi K2.7 Code 在内的 open-weight 模型，都运行在简单的 Pydantic AI harness 中，除了 IDOR prompt 之外没有任何其他辅助。

这个细节非常重要，所以我们要再说一次：open-weight 模型没有获得 multimodal pipeline 所使用的 endpoint-discovery 脚手架。它们看到的只有一个 prompt 和一个 codebase。这就是它们在没有任何帮助的情况下所具备的能力。

我们还计算了几种不同的效果指标：

Precision：检测器标记为 IDOR 的所有结果中，有多少比例是真实漏洞？高 precision 意味着误报很少。如果它报告了 10 个 bug，其中 7 个确实存在，那么 precision 就是 70%。
Precision：检测器标记为 IDOR 的所有结果中，有多少比例是真实漏洞？高 precision 意味着误报很少。如果它报告了 10 个 bug，其中 7 个确实存在，那么 precision 就是 70%。
Recall：dataset 中实际存在的所有真实 IDOR，有多少比例被检测器找到了？高 recall 意味着它只漏掉少量真实 bug。如果存在 20 个真实 IDOR，而检测器抓到了其中 12 个，那么 recall 就是 60%。
Recall：dataset 中实际存在的所有真实 IDOR，有多少比例被检测器找到了？高 recall 意味着它只漏掉少量真实 bug。如果存在 20 个真实 IDOR，而检测器抓到了其中 12 个，那么 recall 就是 60%。
F1：用于平衡 precision 与 recall 的单一指标。它是两者的调和平均数：F1 = 2 × (precision × recall) / (precision + recall)。之所以使用 F1 而不是普通 accuracy，是因为这两个目标会相互冲突。检测器只标记一个自己最有把握的 bug，就可以达到 100% precision，但它会漏掉其他所有漏洞，因此 recall 糟糕透顶；它也可以把所有内容都标记为存在漏洞，从而达到 100% recall，但大量 false positive 会把你淹没，因此 precision 糟糕透顶。F1 奖励的是同时做好这两件事，而且调和平均数会惩罚失衡的分数：只要 precision 或 recall 中任意一个接近于零，F1 就会被大幅拉低。本文接下来将始终使用这一指标。
F1：用于平衡 precision 与 recall 的单一指标。它是两者的调和平均数：F1 = 2 × (precision × recall) / (precision + recall)。之所以使用 F1 而不是普通 accuracy，是因为这两个目标会相互冲突。检测器只标记一个自己最有把握的 bug，就可以达到 100% precision，但它会漏掉其他所有漏洞，因此 recall 糟糕透顶；它也可以把所有内容都标记为存在漏洞，从而达到 100% recall，但大量 false positive 会把你淹没，因此 precision 糟糕透顶。F1 奖励的是同时做好这两件事，而且调和平均数会惩罚失衡的分数：只要 precision 或 recall 中任意一个接近于零，F1 就会被大幅拉低。本文接下来将始终使用这一指标。
美元成本：包括每个 true positive 的成本，以及每次运行的总支出除以发现的真实 bug 数量。它反映了实际运行检测器时的经济账。一个 F1 表现平平但价格低廉的模型，仍然可能在这一项上胜出。
美元成本：包括每个 true positive 的成本，以及每次运行的总支出除以发现的真实 bug 数量。它反映了实际运行检测器时的经济账。一个 F1 表现平平但价格低廉的模型，仍然可能在这一项上胜出。

按 IDOR 检测的 F1 排名：

Semgrep Multimodal（GPT 5.5）
Semgrep Multimodal（Opus 4.8）
Pydantic AI（仅 prompt）
Claude Code（Opus 4.6）
Claude Code（Opus 4.8/4.7）
Pydantic AI（仅 prompt）
Pydantic AI（仅 prompt）
Nemotron Super 3 120B
Pydantic AI（仅 prompt）
Pydantic AI（仅 prompt）

对我们来说，有两个发现尤为突出。

我们的 multimodal pipeline 处于领先位置，而原因很可能就是 harness。在 Semgrep Multimodal 中运行的 GPT 5.5 和 Opus 4.8 分别以 61% 和 53% 占据前两名。这对我们和我们的客户来说当然是好消息，也验证了我们的方法确实有效，等等……但这并不是最有意思的部分。

最大的惊喜来自第三名。完全没有任何脚手架的 GLM 5.2，比 Claude Code 高出 7 个百分点（39% 对 32%）。一个只使用基础 prompt 运行的 open-weight 模型，在一项高度依赖推理的安全任务上超过了前沿 coding Agent。而且成本还很低！按照 GLM 5.2 的价格计算，这次 open-weight 模型运行平均每发现一个漏洞只需约 0.17 美元。对于可能要覆盖数千个 endpoint 的检测任务来说，单个 bug 的经济成本绝不是无关紧要的脚注，它往往决定了一项技术能否大规模使用。

open-weight 模型与前沿模型的 benchmark 对比

GLM 5.2 并不能代表整个 open-weight 类别，它毫无疑问是其中最突出的一个，但这并不意味着其他模型毫无竞争力。MiniMax M3（23%）和 Kimi K2.7 Code（22%）的成绩明显落后于它，也落后于 Claude Code，两者的表现则非常接近。它们都是能力不错的通用 coding 模型，但面对这个特定任务——在没有任何定位指引的情况下，推理哪里缺少 authorization check——它们很难把真实 IDOR 与噪声区分开来。

GLM 5.2 与下一个 open-weight 模型之间的差距为 16 个百分点，甚至大于 GLM 5.2 与 Claude Code 之间的差距。因此，结论并不是“open-weight 模型已经追上来了”，而是“在这项任务和这些条件下，有一个 open-weight 模型追上来了”。

这并不是一场针对模型原始能力的同条件对比，我们也不希望任何人读完后产生这种误解。我们认为真正的结论是：在模型获得相同的最简 prompt 和 harness 时，GLM 5.2 这个成本只有前沿 LLM 六分之一的 open-weight 模型，在一项真正困难的安全研究任务中击败了 Claude Code。

harness 仍然比模型本身更重要。表格中最大的性能差距并不出现在不同模型之间，而是出现在能够获得 endpoint discovery 的配置与无法获得它的配置之间。不过，对于当前关注安全研究的人来说，这肯定不算意外，而且完全符合预期。

但是，当这样一个意外选手突然出现，只用这么低的 compute 成本就取得这种成绩时，它会鲜明地提醒你：绝不能把所有鸡蛋都放在同一个 LLM 篮子里。如果你被绑定在一个昂贵的前沿模型上，那么即使拥有最好的 vendor-locked-in harness，也可能错过切换模型所带来的优势——无论是成本方面，还是性能方面。

open-weight 模型已经跨过了一个值得关注的门槛。一年前，把一个 open-weight 模型放到漏洞检测排行榜上，更多只是一种照顾性质的陪跑。如今，GLM 5.2 只使用基础 prompt，就以六分之一的成本击败了一个前沿 Agent，同时还可以选择完全在自己的环境中运行。对许多安全团队而言，这是一个很有吸引力的选择。

我们还要强调一个限制：这只是一项任务、一个 dataset、一次运行。IDOR 检测具有非确定性，dataset 的规模有限，而且我们只干净地改变了一个配置。GLM-5.2 在 IDOR 检测上或许确实优于 Claude，但换成 SSRF 检测，结果也可能完全反转——目前我们还不知道，不过可以肯定的是，我们会把答案找出来。

Semgrep 安全研究与工程团队