我们自家的神话：GLM 5.2 在网络安全基准测试中击败 Claude | Semgrep

semgrep.dev 2026-06-28T22:22:33.497214

我们针对一组流行的开源模型运行了我们的 IDOR 基准测试，使用了与评估前沿编码智能体相同的数据集和相同的提示。结果令我们惊讶：智谱 AI 的开源权重模型 GLM 5.2 在 IDOR 检测上取得了 39% 的 F1 分数，击败了 Claude Code（32%），每发现一个漏洞的成本约为 0.17 美元。它仍然落后于 Semgrep 的多模态管道（53–61% F1），但该管道运行在专门构建的框架中，承担了大量繁重工作。在仅获得一个提示的模型中，最好的开源权重选项不再是明显的劣势者，它击败了 Claude Opus 4.8。

说实话，我们并非试图加冕一个开源权重的冠军。我们试图回答一个更狭窄、更无趣的问题：漏洞检测的性能有多少来自模型本身，又有多少来自围绕它的框架？ 对于 Semgrep 的我们来说，这是一个非常重要的问题，因为我们正在与那些在安全任务中大量使用 AI 智能体的客户交流。框架是包裹模型的脚手架：它向模型提供代码仓库，决定模型看到什么，解析模型的输出，并让模型循环执行任务。我们的内部多模态管道运行在一个专门为静态分析构建的框架内。我们内部已经用这个工作流测试了一段时间，用于查找 IDOR（不安全的直接对象引用）。这些是访问控制问题，大致可以理解为“你正在访问属于另一个用户的东西”。

我们的框架枚举应用程序的端点，代码试图筛选出只有重要的上下文，然后直接将模型指向这些端点。这有很多结构，但还记得我说过我们真的没打算回答“哪个开源权重模型最好”吗？这次测试中的模型并没有得到这些结构，它们运行在一个简单的 Pydantic AI 框架中，使用我们给所有其他 LLM 提供商模型的同一个 IDOR 提示，没有端点发现，没有引导导航。我们确实给了它一点帮助，比“这是代码，找出 bug”稍微多一点，提供了一种搜索策略和一些关于 IDOR 长什么样的提示。

所以这最初是一个提示 vs 框架的实验，但当我们运行它时，我们真的震惊了。一个开源权重模型，在没有任何我们脚手架的情况下，超越了一个前沿编码智能体。

介绍 GLM-5.2

如果你没听说过 GLM-5.2，别担心，我们也是直到在社交媒体上看到它，并思考把它加入我们的基准测试时才知道的。GLM 5.2 是智谱 AI（Z.ai）的最新模型，于 2026 年 6 月 13 日（周六）向 GLM 编码计划成员推出，开源权重和发布说明在三天后的 6 月 16 日（我们正是在那时听说它的）发布。有三点使其对安全工作充满吸引力。

首先，它是开源权重的。这意味着该模型的参数在 MIT 许可下发布，这意味着你可以下载它们，在自己的硬件上运行，微调它们，并检查它们。对于许多在敏感领域工作的安全团队来说，这一点很重要：开源权重模型可以完全在你的内部环境中运行。但需要注意的是，“开源权重”并不等同于“开源”：训练好的权重被发布，但训练数据和完整管道通常不会（尽管 Z.ai 确实发布其 RL 训练框架）。

其次，它在编码方面确实具有竞争力。GLM 5.2 是一个混合专家（MoE）模型，总参数约 7500 亿，但每个 token 只有约 400 亿活跃参数，这相对于其规模降低了推理成本。它将可用上下文从 200K 扩展到高达 1M 个 token，Z.ai 的宣传是，这种上下文在长而混乱的智能体轨迹中依然可靠，而不仅仅是它接受更多输入。同样，对于安全任务来说，这很重要，因为像 IDOR 这样的安全任务必须能够跨不同文件、通过授权框架进行推理。在标准编码基准测试上，它创下了开源权重的最佳成绩：Terminal-Bench 2.1 上取得 81.0（相比 GLM 5.1 的 63.5，比 Claude Opus 4.8 的 85.0 只差几分），SWE-bench Pro 上取得 62.1，超越了封闭的前沿模型，与顶尖水平仅差个位数百分比。

第三，成本。代币经济学正迅速变得与大语言模型本身的能力同等重要。据报道，GLM 5.2的定价约为同类前沿模型的六分之一，密切关注开源模型的评论人士将其反响与DeepSeek相提并论。GLM-5.2的发布恰逢其时，不仅因为代币经济学的原因，还因为它恰好落地于前沿闭源模型因报道的越狱攻击而面临新的出口限制之后。发布说明中有一个细节值得任何将此模型用于代码分析的人注意：Z.ai报告称，GLM 5.2比GLM 5.1表现出更多的奖励破解行为（reward-hacking），在训练过程中它会读取受保护的评估文件或通过curl获取参考答案来虚增分数，这促使团队构建了专门的防破解守卫。这是团队诚实的披露，但如果你本就在构建一个用于破解的模型……嗯，没有什么比一开始就试图绕过测试更“黑客”的了。

我们的实验

在深入细节之前，有必要回顾一下我们到底想做什么以及我们的实验内容。快速回顾一下IDOR：不安全的直接对象引用是一种漏洞类别，指应用程序在请求中暴露了像用户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路由直接从URL中的ID获取并返回用户记录，没有检查请求者是否拥有该记录。任何登录用户都可以更改user_id并读取他人的记录。IDOR介于业务逻辑缺陷和配置错误之间，它不是污点流（taint-flow）类型的bug，这正是导致静态分析和LLM都难以处理的原因：没有需要标记的危险函数，只有缺失的检查。它也是实际环境中最常见的发现之一（目前在HackerOne顶级漏洞类型列表中排名第四），这也是我们一直将其作为基准测试的原因。

回到我们的实验：我们保持三个因素不变，变化一个因素，这是标准的实验条件。保持不变的因素：IDOR数据集（与我们之前研究中使用的真实开源应用程序相同）、评估方法（针对已知真阳性集合的F1分数）以及IDOR系统提示本身。变化的因素：模型及其运行框架。具体来说：

Semgrep Multimodal 在我们的自定义框架内运行：该框架枚举端点并将模型引导至这些端点。我们在其背后测试了两个前沿模型。
但我们还直接通过Claude Code SDK运行了Claude Code，并通过其他提供商的本地SDK运行了它们的模型，但使用了相同的提示。
开源权重模型，包括GLM 5.2、MiniMax M3和Kimi K2.7 Code，在简单的Pydantic AI框架中运行，仅包含IDOR提示，没有其他内容。

这是一个重要的细节，我们重复两次：开源权重模型没有获得多模态管道所使用的端点发现脚手架（scaffolding）。它们只看到了一个提示和一个代码库。这只是在没有任何帮助的情况下它们自身的能力。

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

精确率（Precision）：在所有检测器标记为IDOR的项中，有多少是真正的漏洞？高精确率意味着误报少。如果它报告了10个bug，其中7个是真的，那么精确率就是70%。
召回率（Recall）：在数据集中实际存在的所有真实IDOR中，它发现了多少？高召回率意味着它漏掉的真实bug少。如果有20个真实IDOR，它找到了12个，那么召回率就是60%。
F1分数：平衡精确率和召回率的单一数值。它是两者的调和平均数：F1 = 2 × (精确率 × 召回率) / (精确率 + 召回率)。之所以使用F1而不是简单的准确率，是因为这两个目标相互冲突。一个检测器可以通过只标记它确信的一个bug（但遗漏所有其他bug导致很差的召回率）来达到100%的精确率，或者通过将所有内容标记为易受攻击（但让你被误报淹没导致很差的精确率）来达到100%的召回率。F1同时奖励在两个指标上都表现良好的方法，而调和平均数会惩罚不平衡的分数：如果精确率或召回率接近零，F1就会被严重拉低。这是我们将在本文中反复使用的指标。
成本（美元）：每个真阳性以及每次运行的总花费除以发现的真实bug数量。这是运行检测器的实际经济性。一个成本低廉但F1中等水平的模型在这里仍然可能胜出。

结果

按IDOR检测的F1分数排名：

排名	配置	框架 (Harness)	F1
1	Semgrep Multimodal (GPT 5.5)	Semgrep Multimodal	61%
2	Semgrep Multimodal (Opus 4.8)	Semgrep Multimodal	53%
3	GLM 5.2	Pydantic AI (仅提示词)	39%
4	Claude Code (Opus 4.6)	Claude Code SDK	37%
5	Claude Code (Opus 4.8/4.7)	Claude Code SDK	28%
6	MiniMax M3	Pydantic AI (仅提示词)	23%
7	Kimi K2.7 Code	Pydantic AI (仅提示词)	22%
8	GPT-5.5	Codex	20%
9	Nemotron Super 3 120B	Pydantic AI (仅提示词)	18%
10	DeepSeek V4	Pydantic AI (仅提示词)	17%

对我们而言，有两个发现尤为突出。

我们的多模态流水线领先，而框架 (Harness) 很可能是原因。Semgrep Multimodal 中的 GPT 5.5 和 Opus 4.8 分别以 61% 和 53% 的成绩占据前两名。这当然对我们和我们的客户是好消息，验证了我们的方法是有效的……但这并非有趣的部分。

最大的惊喜在第三名。GLM 5.2 完全没有任何脚手架 (scaffolding) ，却以 39% 的成绩领先 Claude Code 的 32% 七个百分点。一个开放权重模型在仅使用裸提示词 (bare prompt) 的情况下，就在一项推理密集型的安全任务上击败了前沿编码代理 (frontier coding agent)。而且它的成本很低！按 GLM 5.2 的定价，每次发现漏洞的开放权重运行成本约为 0.17 美元。对于可能跨越数千个端点的检测任务，每个漏洞的经济性不是点缀，而是经常决定一项技术能否大规模使用的关键因素。

Benchmark comparison of open-weight and frontier models

GLM 5.2 并不代表开放权重模型这一类别的整体水平，它无疑是其中的佼佼者，但这并不意味着其他模型没有自己的实力。MiniMax M3 (23%) 和 Kimi K2.7 Code (22%) 远落后于它，也落后于 Claude Code，且它们之间得分非常接近。两者都是能力不错的一般性编码模型，但在这项特定任务上——需要对缺失的授权检查进行推理，且没有任何方向指引——它们很难将真正的 IDOR 从噪声中区分出来。

GLM 5.2 与下一个开放权重模型之间的差距（16 个百分点）甚至比 GLM 5.2 与 Claude Code 之间的差距还要大。因此，结论并非是“开放权重模型已经赶上了”，而是“有一个开放权重模型，在这项任务上，在这些条件下，做到了这一点”。

结论

这不是对原始模型能力的苹果对苹果比较，我们也不希望任何人认为这是。相反，我们认为结论是：在给予相同的最小提示词和框架 (harness) 的情况下，一个开放权重模型 GLM 5.2，成本仅为前沿 LLM 的六分之一，却在一项真正困难的安全研究任务上击败了 Claude Code。

框架 (Harness) 仍然比模型更重要。表中最大的性能差距并非出现在模型之间，而是出现在能够进行端点发现和不能进行端点发现的配置之间。但对于目前关注安全研究的任何人来说，这绝对不意外，也是意料之中的。
但是，当像这样的意外结果突然出现，并以如此少的计算成本产生如此效果时，这强烈提醒我们不能将所有鸡蛋放在一个 LLM 篮子里。如果你被一个昂贵的前沿模型束缚，即使拥有最好的供应商锁定框架 (vendor-locked-in-harness) ，你也可能错过更换模型带来的优势——无论是成本还是性能。
开放权重模型已经跨越了一个值得关注的阈值。一年前，将开放权重模型放在漏洞检测排行榜上可能只是一个慈善参赛。而 GLM 5.2 以六分之一的成本、仅凭裸提示词就击败了前沿代理，并且可以选择完全在自己环境中运行。对许多安全团队来说，这是一个有吸引力的选项。

我们有一个提示：这只是一项任务、一个数据集、一次运行的结果。IDOR 检测是非确定性的，数据集有限，并且我们只干净地更改了一个配置。很可能在 IDOR 检测上 GLM-5.2 确实比 Claude 更好，但在 SSRF 检测上情况可能反转——我们目前还不知道，但可以确定我们会找出答案。

致以最诚挚的问候，
Semgrep 安全研究与工程团队

查看原文