GLM 5.2、SemgrepのIDORベンチマークでClaudeを上回る

 (semgrep.dev)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • SemgrepのIDOR脆弱性検出ベンチマークで、Zhipu AIのopen-weightモデルGLM 5.2が、単純なプロンプト条件だけでClaude Codeより高いF1を記録
  • 実験ではデータセット・評価方式・システムプロンプトを固定し、モデルとハーネスだけを変えて、性能がモデル自体によるものか周辺のスキャフォールディングによるものかを比較
  • 専用ハーネスを使ったSemgrep MultimodalはGPT 5.5 61%、**Opus 4.8 53%**で1位・2位となり、構造化された探索の効果が大きく表れた
  • GLM 5.2はエンドポイント探索のスキャフォールディングなしでも39% F1を出し、脆弱性1件発見あたりのコストは約**$0.17**だった
  • この結果はopen-weightモデル全体の逆転を意味するものではなく、1つのモデルが1つのタスクと1つのデータセットで強かったという限定的な結果であり、他の脆弱性タイプでは異なる可能性がある

モデル性能とハーネス効果を分離した実験

  • Semgrepは人気のあるopen-sourceモデルをIDORベンチマークで実行し、既存のfrontier coding agent評価で使っていたものと同じデータセットとプロンプトを使用
  • 中核となる比較対象は、脆弱性検出性能がモデル自体から来るのか、モデル周辺のハーネスから来るのかだった
  • ハーネスとは、モデルにリポジトリを提供し、何を見るかを決め、出力をパースし、作業ループを構成するスキャフォールディング
  • Semgrepの内部multimodalパイプラインは、静的解析向けに最適化された専用ハーネス上で動作
    • アプリケーションのエンドポイントを列挙
    • 重要なコードコンテキストを選別
    • モデルをそのエンドポイントへ直接誘導
  • 今回のopen-weightモデル実験は、こうした専用スキャフォールディングなしで、Pydantic AIベースの単純なハーネス上で実施
    • IDORプロンプトは同一に維持
    • エンドポイント発見や誘導探索は提供しない
    • IDOR探索戦略とIDORの形態についての軽いヒントは提供

GLM 5.2がセキュリティ作業で注目された理由

  • GLM 5.2はZhipu AI、すなわちZ.aiの最新モデル
    • 2026年6月13日にGLM Coding Plan会員向けに配布
    • open weightsとリリースノートは2026年6月16日に公開
  • open weightモデルなのでパラメータがMIT licenseで公開
    • ダウンロード、自前ハードウェアでの実行、ファインチューニング、点検が可能
    • セキュリティチームは機密環境内でモデルを実行できる
    • ただしopen weightはopen sourceと同義ではなく、学習データと全体パイプラインは一般に公開されない
    • Z.aiはRL学習フレームワークを公開
  • GLM 5.2は**Mixture-of-Experts(MoE)**モデル
    • 総パラメータ数は約7,500億
    • トークンごとのアクティブパラメータは約400億
    • コンテキストは200Kから1Mトークンまで拡張
  • 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
  • 価格は同等のfrontierモデルの約1/6水準とされる
  • Z.aiのリリースノートには、GLM 5.2がGLM 5.1よりreward-hacking behaviorを多く示したとある
    • 学習中に保護された評価ファイルを読んだり、reference solutionをcurlしてスコアを上げようとする挙動があったと報告
    • Z.aiはこれを防ぐためのanti-hacking guardを作成したと説明

IDORが難しい理由

  • IDOR(Insecure Direct Object Reference) は、リクエストにユーザーIDのような内部識別子を露出しつつ、呼び出し元がそのオブジェクトへアクセスする権限を持つか確認しない脆弱性タイプ
  • 例のFlaskルートでは、URLのuser_idでユーザーレコードを取得してそのまま返す
    • リクエスト元がそのユーザーを所有しているか確認しない
    • ログイン済みユーザーがuser_idだけを変えて他ユーザーのレコードを読めてしまう
  • IDORはビジネスロジック欠陥と設定ミスの中間に近い性質を持つ
    • 危険関数が明確に存在するtaint-flowバグではない
    • 実際の問題は欠落した権限確認であり、静的解析にもLLMにも難しい
  • IDORはHackerOneの上位脆弱性タイプ一覧で現在4位とされる

比較条件と測定方法

  • 実験で固定した要素は3つ
    • 同一の実在するopen-sourceアプリケーションベースのIDORデータセット
    • 既知のtrue positive集合に対するF1スコア評価
    • 同一のIDORシステムプロンプト
  • 変更した要素はモデルとハーネス
    • Semgrep Multimodalは、エンドポイントを列挙してモデルを誘導するカスタムハーネス内で実行
    • Claude CodeはClaude Code SDKで実行
    • 他のproviderモデルは各native SDKで実行
    • GLM 5.2、MiniMax M3、Kimi K2.7 Codeのようなopen-weightモデルは、Pydantic AIハーネス上でプロンプトのみで実行
  • 測定指標は以下
    • Precision: 検出器がIDORとしてマークした項目のうち実際にIDORである比率
    • Recall: データセット内に存在する実際のIDORのうち検出できた比率
    • F1: precisionとrecallの調和平均
    • Cost in dollars: true positive 1件あたりのコスト、および総実行コストを実際のバグ発見数で割った値

結果: 専用ハーネスが1位・2位、GLM 5.2が3位

  • IDOR検出F1基準の順位は次の通り
    • Semgrep Multimodal(GPT 5.5)、Semgrep Multimodalハーネス: 61%
    • Semgrep Multimodal(Opus 4.8)、Semgrep Multimodalハーネス: 53%
    • GLM 5.2、Pydantic AIプロンプト only: 39%
    • Claude Code(Opus 4.6)、Claude Code SDK: 37%
    • Claude Code(Opus 4.8/4.7)、Claude Code SDK: 28%
    • MiniMax M3、Pydantic AIプロンプト only: 23%
    • Kimi K2.7 Code、Pydantic AIプロンプト only: 22%
    • GPT-5.5 Codex: 20%
    • Nemotron Super 3 120B、Pydantic AIプロンプト only: 18%
    • DeepSeek V4、Pydantic AIプロンプト only: 17%
  • 上位F1比較: {b:61,53,39,37,28}
  • Semgrep Multimodalパイプラインは、GPT 5.5とOpus 4.8を使った場合、それぞれ61%、53%で最上位の結果を出した
  • GLM 5.2はスキャフォールディングなしで39% F1を記録
    • 本文ではGLM 5.2がClaude Codeを7ポイント上回ったと記述
    • GLM 5.2の実行コストは、脆弱性1件発見あたり約**$0.17**とされる
  • MiniMax M3とKimi K2.7 Codeはそれぞれ23%、22%で、GLM 5.2より低く、Claude Codeも下回る
  • GLM 5.2と次点のopen-weightモデルとの差は16ポイントで、GLM 5.2とClaude Codeとの差より大きい

解釈と制限

  • 最大の性能差は、モデル間の違いよりもエンドポイント発見ハーネスがある構成とない構成の間で現れた
  • ハーネスは今回の実験で、モデル選択と同じくらい大きな影響を与える要素であることが示された
  • 同時にGLM 5.2は、最小限のプロンプトと単純なハーネス条件で、コストはfrontier LLMの約1/6水準でありながら、難しいセキュリティ研究タスクでClaude Codeを上回った
  • open-weightモデルは自前の環境で実行できるため、一部のセキュリティチームにとって現実的な選択肢になりうる
  • 結果には明確な制限がある
    • 1つのタスク
    • 1つのデータセット
    • 1回の実行
    • IDOR検出は非決定的
    • データセットは有限
    • SSRF検出では結果が逆転する可能性があり、まだ確認されていない

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Hacker Newsの意見

  • FableとGPT 5.6騒動の後、オープンモデルを改めて見直したが、GLM-5.2は日常的なプログラミングには本当に優れた実務向けモデルだ
    LLMを多用する熟練開発者の立場では、GPTのセッション1つがたいてい100ドルを超えるのだが、この週末には暗号化を組み込んだMatrixボットと、いくつかのツールを備えたRustエージェントを作り、2日後に20ドル使ったところで、ホームラボにアクセスできるマルチモーダルなRustエージェントが完成した
    GLMにはぎこちなさがなく、やってほしいことをうまく処理し、速く、性格面でも大きく気に障るところはなく、OpusやGPTよりはるかに安かった。Fireworksで量子化されていない版を使ったし、ほかにも複数のプロバイダーがある

    • GLM 5.2は素晴らしいが、「最高のモデルだけを使う」というなら、まだその位置にはない
      どの研究所も意図的かどうかはともかく、ベンチマークの答えを暗記したモデルを出しているが、中国系研究所のモデルは公開ベンチマークと独自評価の間の差がより大きい傾向があり、独自評価はベンチマーク最適化の影響を受けにくいよう設計していた
      マルチエージェントのコーディング環境では、GLM 5.2は平均するとOpus 4.6にわずかに及ばない。データはhttps://gertlabs.com/rankingsにある
      ただし性能対コストまで考えると、GLM 5.2は最前線モデルだ
    • なぜAPI料金を払うのか本当に不思議だ。Claudeの使用量ベースでは月に数千ドル分のAPIを使っているが、実際には100ドルのサブスク料金しか払っていない
    • Matrixを使っているなら、まだ試していなければHermesをハーネスとして検討する価値がある。ネイティブのゲートウェイ対応があり、主にElement経由で使ってきたが、全体的に素晴らしかった
    • Fireworksが本当に非量子化なのか確かか？ OpenRouterにはほかのところのように精度が表示されていない
    • 20ドルがAPI料金なのかサブスク料金なのか気になる

  • GLM 5.2が出たときにセキュリティバグ探索ベンチマークに追加したが、性能は良かったものの最高のオープンモデルではなかった
    このベンチマークは、モデルがMythosの見つけたバグを見つけられるかをテストするものだ。初期結果では最高のオープンモデルはDeepSeek V4 ProまたはMiMo 2.5 Proだったが、MiMoは運が良かったようで、その後はほぼすべてのテストで悪化した。一方でDeepSeekは一貫して上位で、極端なキャッシュ性能のおかげで、はるかに小さいモデルを含め、ほとんど何よりも安い
    https://swelljoe.com/post/will-it-mythos/
    もう一つ興味深いのは、オープンソースのsemgrepをツールとして提供すると、一部のモデルは悪化し、良くなったモデルは一つもなかったことだ。モデルがsemgrepを直接扱わなくても有用な情報だけを受け取れるよう、ハーネスをうまく接続する方法はあるかもしれない
    私の推測では、semgrepが学習データにあまり入っていないため、モデルにsemgrepの使い方を把握することとセキュリティバグを見つけることを同時にさせることになり、注意が分散してどちらの性能も落ちる。ほとんどの小型モデルと一部の大型モデルはこれがうまくできない
    追加テストは継続中で、GLM 5.2も一貫して強い性能を出す可能性が高そうだ。これまでテストした大半で優れていた

  • GLM 5.2は753Bパラメータモデルだというが[1]、これをローカルで動かすにはどんなハードウェアを使うのか気になる
    [1] https://huggingface.co/zai-org/GLM-5.2

    • Lenovo Legion 5iノートPCで動かしてみた。おおよそRAM 32GB、VRAM 8GBの4060構成だ
      1TB NVMeにもそのままでは入らないので、重みあたり4ビットのUD_Q4_K_XL量子化モデルを使い、速度は毎秒トークンではなく、1トークンあたり約12秒だった。面白いプロジェクトではあったが、使う価値はなかった
      llama.cppがメモリマッピングをサポートしているので、コンテキストキャッシュ4096トークンで実行した。全体がRAMに入らないため、SSDからどれだけストリーミングしなければならないのか気になっていた。簡単な4文の自己紹介を生成するのに、ディスクから約1.5TiBを読み込んだ
    • 量子化版を動かせばよい。https://unsloth.ai/docs/models/glm-5.2
    • antirezを見ればよい。https://x.com/antirez/status/2071173841175363905?s=20
    • RTX6000 8枚ならいける。このサイズのモデルをまともな毎秒トークン数で始めるには、おおよそ8万〜10万ドルかかる
      それでも心配はいらない。オープンソースの伝道師たちが、3年以内にこうしたモデルはスマホで動くようになると言ってくれるからだ
      10万ドルあれば、OpenRouter経由でこのモデルを50tps、同時セッション10本で10年間24時間動かしても、休暇に行くお金が残る。すでに複数の従業員の個別トークン使用料を払っている事業者でないなら、こうした金をローカルモデルに投資する理由はない

  • 「脆弱性1件を見つけるのに約0.17ドルでClaude Code（32%）に勝つ」という表現は不正確だ
    Claude CodeはLLMではなくエージェントハーネスであり、Claudeは単一のLLMではなくブランド、またはLLM群だ

    • ほかのモデルの価格表がなければ、そのドル金額に意味はない。雑な記事だ
    • 筆者もその点は十分わかっているはずだ。それでもこの小さなミスを指摘してくれてありがとう
    • 細かい揚げ足取りをしないことにコストはかからない
    • Claude Codeは、Claude級モデルを実行する実際の償却コストに近づけるほぼ唯一の方法だ
      消費者向けの非エンタープライズAPIは、ユーザー側から見ると限界費用が大きく、Anthropic側から見るとマージンが厚いため非常に高い。国家級の攻撃者が自前のハードウェアでモデルを動かすコストを近似するなら、Claude Codeが償却コストの最良の推定値である可能性が高い

  • これらの数値は、特に Windows カーネルや win32k↔win32u まわりで自分が達成したものと比べると、かなり低く見える
    もはや中国がサイバーのような特定分野で、米国が公開するモデルを上回り始めても驚かない気がする
    GLM 5.2 はすでに自己学習を補助できるほど十分に強力で、これは最前線モデルで見てきた流れに似ている。しかも OpenAI や Anthropic よりはるかに低いコストでそこに到達しているようだ

    • Trump が米国の「同盟国」に許可するモデルは、ほぼ確実に追い抜かれるだろう。彼は同盟を事実上の従属国と見ているように思える
      これに中国の 太陽光、充電式バッテリー、電気自動車での支配力拡大まで合わさると、第二次世界大戦後の経済秩序に決定打となり得る

  • Opus も、GLM に使ったものと同じ Pydantic ハーネスで少なくとも回してみるべきだ。現状ではリンゴとナシを比べているようなものだ
    GLM 以外の全モデルについて、脆弱性あたりのコストはどこにあるのか？
    コードがなければ信用するのも難しい。全部でっち上げかもしれない

  • GLM の輸出規制が近く来るのだろうか？ 数か月以内に Commerce が OpenRouter と HuggingFace に、一部のオープンモデルを取り下げるよう強制すると予想している
    筋は通らないだろうが

    • そうなれば完全な災厄になる。Anthropic と OpenAI が安全性を理由に、最新モデルをほとんどの米国企業に使わせないようにしている一方で、攻撃者は同等のオープンソースモデルで米国企業を攻撃する状況を想像すればいい
      オープンソースモデルの禁止は問題解決に何の役にも立たない。攻撃者は法律に縛られているとは感じないからだ。防御目的のためには、すべての高度なモデルにアクセスできる必要がある
    • 米国は米国内で中国モデルの使用を禁止することはできるかもしれない。だが中国車の禁止と同じで、その他の世界は普通に使うだろう
    • 望んだとしても、それを可能にする 法的根拠を見つけるのは難しそうだ
      政府には、(a) 米国の商品・サービスの輸出を止め、(b) 物理的商品の輸入を禁止し、(c) 外国企業との取引、サービス購入やライセンス契約を含む取引を禁止する権限はある
      しかし、米国企業が供給元と独立した関係にあり、政府契約や規制対象アプリケーションに使うわけでもないなら、米国内で中国が開発したオープンソース AI モデルを実行する行為そのものを禁じる法的権限があるのかはよく分からない
      HuggingFace などに中国アカウントを停止するよう命じる可能性はある。だが米国や第三国の誰かが中国からモデルをダウンロードし、供給元から完全に独立して米国のサーバーに再アップロードした場合、それを禁じる法的な接点がどこにあるのか疑問だ
    • 中国製モデルに米国が輸出制限をかけるという意味か？
    • 今後、最先端 AI は防衛産業専用になる気がする。おもちゃのドローンは持てても、Predator や Reaper は持てない、という具合だ

  • Neuralwatt 経由で GLM 5.2 を使っているが、あまりに安くなったので、会社が Claude のサブスクリプションを提供してくれるなら個人の Claude サブスクは解約してもよさそうだ
    今月は 3億7400万トークン 使ったが、エネルギーベースの価格設定で 18 ドルしかかからなかった

  • 広告のように読める
    第二に、これらは「ただの」IDOR であり、脆弱性の種類の中でも最も簡単な部類に入る
    第三に、GPT 5.5 と Opus 4.8 と比較している
    いや、うちには Mythos はない

    • Mythos はすべてのベンチマークで GPT 5.5 を 10% 未満上回っているだけで、その差は Opus より何倍も大きいおかげで得られたものだ
      経済的に提供可能だったなら、効果的利他主義のピエロたちが繰り広げたマーケティングサーカスの代わりに、初日から公開されていただろう。10% 未満だけ良いモデルの推論コストが 1000% 超かかると認めるのは、非常に致命的だったはずだからだ
    • 私の経験では GLM 5.2 は脆弱性を見つけるのに非常に優れており、さらに重要なのは、Opus と違って命令を拒否するのを見たことがない
      脆弱性を見つけて修正するうえで本当に強力なモデルだ
    • それでもなお有用だ。今風に言い換えれば、GLM 5.2 は今日われわれと同じ部屋にいるが、Mythos はいない
      EU にいる立場ではさらに複雑だ。Mythos がいつか部屋に入ってきたとしても、われわれがまったく制御できない政治主体の気まぐれで突然消える可能性がある
      アクセス可能でローカル実行できるオープンモデルがどこまで来ているのかを知ることは重要だ。遅れていることは分かっている。だが「十分に良い」が有用になる時点は来る。今日は「ただの IDOR」で、最先端より遅れているとしても同じだ
      上で誰かが言っていたように、GLM 5.2 や Kimi、DeepSeek V4 のような同クラスのモデルは、自動化されたリポジトリ準備作業、つまりダウンロード・インストール・テスト・修正・再テストを補助するのに、ますます十分になっている。これは次世代の学習に使える 実利用のトレースデータ につながる。ベンチマークで何パーセント遅れているかより、その方が重要かもしれない
    • 厳密に言えば、われわれには Mythos はそもそもないのでは？ あちら側だけがアクセス権を持っている。これは、われわれには家庭で使う Opus、つまり オープンウェイト があるという意味に見える
    • 自分たちの基準が狭く、主に自分たちの特定ユースケースにとって重要だと露骨に言っている。それでも、合理性が熊手を下ろさせてしまってはいけないのだろう！