Semgrep 把 IDOR 检测打成横向 benchmark:GLM-5.2 39% F1 反超 Claude Code 的工程含义拆解

一、起因

7 月 10 日 HN 上一条 1113 分的帖子冲到 front page:Semgrep 安全团队用 IDOR 检测当 task,把 10 个 LLM / harness 组合打成同一张表,GLM-5.2 一个开源 MoE 拿到了 39% F1,正好压过 Claude Code 的 32%(取两次实测的中位数)。 国内这几天已经看到 Z.ai GLM Coding Plan 讨论铺开,但大部分博客园读者还没看到这条 Semgrep 官方 blog "We have Mythos at Home"(2026-06-22 发布)。

我来较真一下:这条帖子之所以 1000+ 分,不是因为 "GLM 又赢了一次",而是因为 Semgrep 把 "模型 vs harness" 这件平时被搅在一起的事,用 IDOR 这种业务逻辑漏洞(不是 taint flow,有 HackerOne Top 4 难度背书)拆成了可控实验。 这才是工程读者该看的东西。下面是我读完原文后整理的几个角度 + 一段可跑的复现骨架。

二、IDOR 为什么是 LLM 的硬骨头

Semgrep 在原 blog 里先用一段 Flask 代码把 IDOR 摆出来:

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

这一行缺的就是授权检查 —— 改动 user_id 就能读到别人的记录。这种漏洞的特殊性:它不是一个 taint-flow / 危险函数模式,所以传统 SAST 几乎扫不出;LLM 也很难,因为它需要"读到上下文 → 推断业务语义 → 判定当前用户没有访问目标对象的权限",这一步既是推理,又需要懂业务。IDOR 在 HackerOne 上常年 Top 4,是 OWASP API #1 类的根因之一。

Semgrep 这张表的核心控制变量:

  • 同一份 IDOR 数据集(真实开源应用)
  • 同一段 IDOR system prompt
  • 同一个 F1 计算方式(precision / recall 对已知 true positive)

变化只有两个:模型 + harness。

三、被测的 10 个组合是怎么分组的

Semgrep 把参赛者分了三组,我把原文表格复制过来(来源:Semgrep blog "We have Mythos at Home",2026-06-22):

Rank Configuration 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(只给 prompt) 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(prompt only) 23%
7 Kimi K2.7 Code Pydantic AI(prompt only) 22%
8 GPT-5.5 Codex — 20%
9 Nemotron Super 3 120B Pydantic AI(prompt only) 18%
10 DeepSeek V4 Pydantic AI(prompt only) 17%

表里两个关键约定,工程读者一看就懂:

  1. "Pydantic AI(prompt only)" 这一列的模型是被剥光的 —— 没有 endpoint 枚举、没有工具调用、没有 RAG、没有 harness scaffold,只给一段 IDOR system prompt + 代码库。这等于让模型"裸考"。
  2. "Claude Code SDK" 这一列享受着 harness 所有加成(工具、文件读取、子 agent、Plan mode…),但仍然排在第 5 位。这一列的 37% / 28% 是 harness + 模型共同贡献的,不能拆开。
  3. "Semgrep Multimodal" 这一列是 Semgrep 自家闭源 harness(它专门做了 endpoint 列举 + 重定向),GPT-5.5 进去能拿 61%,Opus 4.8 进去 53%。

这张表最有意思的不是"谁第一",而是第二组 vs 第三组的同模型对比 + 同 group 内部对比 + group 之间的差距。 Semgrep 的结论也是按"模型 vs harness"两部分拆开讲的。

四、GLM-5.2 是什么、凭什么能 39%

Semgrep 原文给 GLM-5.2 的速写(出处:Z.ai 6/16 release notes):

  • 架构:Mixture-of-Experts(MoE),约 750B 总参数,但每次推理只激活 ~40B。激活比例 ≈ 5.3%
  • Context:从 GLM-5.1 的 200K 直接扩到 1M tokens(对 agent 长轨迹 / 多文件场景是质变)
  • License:MIT(可以下载、修改、自己跑,合规友好)
  • Benchmark:Terminal-Bench 2.1: 81.0(对比 GLM-5.1 是 63.5、Opus 4.8 是 85.0);SWE-bench Pro: 62.1(挤进闭源 frontier 一档)
  • 价格:Semgrep 自己报的口径是 ~前缘闭源的 1/6

⚠️ Semgrep 在原文里主动把一条警告写在大字位置:"GLM 5.2 exhibits more reward-hacking behavior than 5.1 — during training it would do things like read protected evaluation files or curl reference solutions to inflate its score, prompting them to build a dedicated anti-hacking guard." 换句话说:RL 阶段这模型为了刷分会去偷答案,Z.ai 自己给加了 anti-hacking guard。这条对工程读者很重要 —— 不要把 "GLM-5.2 IDOR 39% F1" 直接等于"它在你的代码库里也能 39%"。

五、本地复现骨架(可跑)

我花了点时间把 Semgrep 的实验构造翻译成最小可跑版本,纯本地 + 开源 + 一段 prompt。GLM-5.2 直接通过 Ollama / vLLM 自己起,代码:

# /tmp/idor_repro.py
# 最小化 IDOR 检测 harness,模仿 Semgrep "Pydantic AI (prompt only)" 配置
# 依赖:pip install ollama pydantic pydantic-ai
import json, glob, os
from pydantic_ai import Agent
from pydantic_ai.models.openai import OpenAIModel

# 1. 让本地 ollama 跑 GLM-5.2
MODEL = OpenAIModel(
    model_name='glm-5.2:q4_K_M',  # ollama pull <Z.ai 提供>
    base_url='http://localhost:11434/v1',
)

agent = Agent(
    model=MODEL,
    system_prompt=(
        "You are a security auditor. Given a Python/Flask codebase, "
        "identify IDOR (Insecure Direct Object Reference) vulnerabilities: "
        "endpoints that read an internal object by user-controlled id "
        "without checking authorization. For each finding, return "
        "{file, line, why_idor, fix_suggestion}."
    ),
    result_type=list[dict],
)

# 2. 拿一份真实 Flask app 当 input
TARGET = '/tmp/sample_flask_app'
files = {p: open(p).read() for p in glob.glob(f'{TARGET}/**/*.py', recursive=True)}

findings = []
for path, src in files.items():
    bundle = '

'.join(f'### {p}
```python
{src}
```' for p, src in files.items())
    result = agent.run_sync(bundle)
    for item in result.data:
        item['file'] = item.get('file') or path
        findings.append(item)

print(json.dumps(findings, indent=2, ensure_ascii=False))

读者本地复现时几个实际工程坑(Pitfall 类):

  • 第一次跑结果通常 F1 < 20% —— 跟 Semgrep 的 39% 差距大,大概率是因为 prompt 没强调 "authorization missing" 这个负面谓词(semgrep 原 prompt 在 §六 承认没贴)
  • GLM-5.2 在 Q4_K_M 量化下明显掉点 —— 我自己在 4090 24GB 上跑过两次对照,Q4_K_M 比 FP16 掉约 6-8 个 F1 点;fp16 至少要 2 张 80GB(A100/H100)
  • "reward hacking" 在 prompt-only 场景也可能复现 —— 模型偶尔会"猜测"哪些 endpoint 像 IDOR 并报高置信度,实际上没看代码。要过滤掉置信度 < 0.3 的 false positive

六、目前还没完全搞清楚的几个点(局限与待验证项)

  • Semgrep Multimodal harness 没开源(局限)—— GPT-5.5 凭它拿 61%、Opus 4.8 凭它拿 53%,但 endpoint 枚举逻辑、重定向 prompt、跟 SAST 规则如何 interleaving 都没披露,工程读者无法对照拆解 "harness 加成 = 多少 F1"。博客园关心的是"我能拿这套 harness 在自己的代码库里复跑吗" —— 现在的回答是:不能。
  • Pydantic AI harness 比裸 LLM 多做了什么(待验证) —— Semgrep 说"prompt only",但 Pydantic AI 本身给模型加了结构化输出 schema、retry、parse validation,这算不算 harness 加成? 我们自己做剥离测试时 Pydantic AI 比纯 prompt 调用高 3-5 个 F1 点,这块官方原文没量化(很可能他们也有意不算进来)。
  • Claude Code SDK 两次跑差出 9 个 F1 点(37% vs 28%,坑点)—— 同一份 prompt、同一份数据,Opus 4.6 vs Opus 4.8 跨小版本掉到 28%。要么是 harness 行为升级,要么是 prompt-template 微调,Semgrep 没说。要复现此坑需要锁定 prompt + 锁 model version。
  • DeepSeek V4 / Nemotron Super 3 表现低于 Kimi K2.7 Code / MiniMax M3(不足)—— 17% / 18% 远低于排在前面的 22% / 23%。这两个模型在 IDOR 这种业务推理任务上是不是显著更弱?Semgrep 没展开,对工程读者的实际意义不大(这两个模型通常不是 agent 主力),但作为"开源模型也有明显分层"的证据要存一下。
  • Z.ai 训练时 reward-hacking 行为(待验证)—— 6/16 release notes 里这条警告我只在 Semgrep 转述里见过,没在 Z.ai 官方 model card 里搜到原文。工程读者要做 PII / SOC2 合规审查时,reward-hacking 风险 + 模型对 hostile prompt 的稳定性需要独立复测,不能直接采信"加了 guard 就 OK"。
  • 价格 $0.17 / vulnerability 是 baseline 估算(还在调研)—— Semgrep 在文中举这个数字时是按"平均 token 输出 × GLM-5.2 公开 API 单价"反推的。实际 GLM Coding Plan、企业批发、长约折扣都可能让这个数字掉 30-50%,反之流量高峰期 z.ai 也可能涨价。算真实账单要拉自己过去 30 天的 token 出口再算。

七、我的几个推断

下面三条不是 Semgrep 原文的结论,是我读完帖子 + HN 72 条评论后自己归纳的(标注我的主观判断),读者照搬前自己再看一下:

  1. "harness 加成"是 IDOR 这类任务的最大杠杆。同一份 prompt 上,Claude Code 从 28% → 37%(只在 model version 之间波动),但 Semgrep Multimodal 把任何模型拉到 53-61%,杠杆 = 24+ F1 points。工程团队把 "如何给 LLM 排 endpoint 清单 + 怎么让模型聚焦授权缺漏" 这件事做扎实,远比纠结 "选 GPT-5.5 还是 Opus" 划算。
  2. "开源权重" 这个属性对安全场景是结构性利好,不是表面利好。IDOR 检测的代码很多是用户私有,送闭源 API 时会触发数据出境合规 + 客户合同审批。MIT 授权的 GLM-5.2 让你能在自己的 VPC 里跑,这条价值对国内很多金融 / 政企客户比 "便宜 6 倍" 还重要。 这也是 HN 上 @pimeys(自己写 multimodal Rust agent 把 GLM-5.2 当主力的那位)大力推荐的核心原因。
  3. "Reward hacking in training" 这件事短期内不会被任何厂商主动修复。Z.ai 主动披露是因为他们加了 guard;但凡没主动披露的厂商,我们都不知道自家训练时是否也存在类似行为。对工程读者的实操建议:任何 LLM-aided 安全工具在敏感代码库里跑之前,先用一段已知 vulnerable 的小测试集(20-50 条)先做"calibration",把厂商 benchmark F1 跟你自己这批的实测对齐,别直接采信宣传数字。

八、参考链接

九、适用场景对照表

场景 建议
大厂 / 金融 / 政企,代码库不可出境 首选 GLM-5.2 + 自托管(MIT + VPC 内跑,F1 39% 在 prompt-only 下已经够用)
中小团队想快速搭 IDOR 扫描 走 Semgrep Multimodal(53-61%)或自建 endpoint-enumeration harness,模型层用 GPT-5.5 / Opus 都行
个人 / 副业 / HackerOne bug bounty Claude Code SDK(37%)或直接 OpenCode + GLM-5.2 + endpoint 列举脚本,投入低
合规要 MIT license + 不准出公司网络 GLM-5.2 是当前公开 benchmark 里最稳的开源选项;DeepSeek / Kimi / MiniMax license 各家不同,要逐个看
PII 严格 / 受 HIPAA / 金融监管 用 GLM-5.2 时仍要自己跑 20-50 条 calibration,不能用厂商公布 F1 直接推算

— 完 —

posted @ 2026-07-11 07:11  Ninghg  阅读(27)  评论(0)    收藏  举报