Semgrep: GLM 5.2がサイバーベンチマークでClaudeを凌駕

私たちは、以前フロンティアコーディングエージェントの評価に使用したのと同じデータセットとプロンプトで、人気のあるオープンソースモデル群をIDORベンチマークに対して実行しました。その結果に驚きました。Zhipu AIのオープンウェイトモデルであるGLM 5.2は、IDOR検出で39%のF1スコアを記録し、Claude Code（32%）を上回りました。1件の脆弱性発見にかかるコストは約0.17ドルです。Semgrepのマルチモーダルパイプライン（53〜61% F1）にはまだ及ばないものの、このパイプラインは多くの重い処理を行う目的特化型ハーネス上で動作します。プロンプトのみを与えられたモデルの中では、最高のオープンウェイトオプションはもはや明らかな劣勢ではなく、Claude Opus 4.8を打ち負かしました。私たちはオープンウェイトチャンピオンを決定しようとしていたわけではありません。私たちは、脆弱性検出のパフォーマンスのどれだけがモデルに由来し、どれだけがそれを取り巻くハーネスに由来するのかという、より狭く、より退屈な疑問に答えようとしていました。Semgrepの私たちは、セキュリティタスクでAIエージェントを強力に活用しているお客様と話す上で、これは非常に重要な質問です。 ハーネスとは、モデルをラップする足場のことです。リポジトリを供給し、モデルが見るものを決定し、その出力を解析し、タスクを通してループさせます。私たちの内部マルチモーダルパイプラインは、静的解析のために特別に構築されたハーネス内で動作します。私たちは、IDOR（Insecure Direct Object References）を発見するためのワークフローで、これをしばらく内部的にテストしてきました。これらはアクセス制御の問題であり、大まかに言えば「別のユーザーに属するオブジェクトにアクセスしている」と考えることができます。私たちのハーネスは、アプリケーションのエンドポイントと、重要なコンテキストのみを選別しようとするコードを列挙し、モデルをそれらに直接向けます。これは多くの構造ですが、私たちは「最高のオープンウェイトモデルは何か」という質問に本当に答えようとしていなかったと言ったことを思い出してください。このテストのモデルはそれを受け取らず、他のすべてのLLMプロバイダーモデルに与えるのと同じIDORプロンプトを使用して、単純なPydantic AIハーネスで実行されます。エンドポイントの発見も、ガイド付きナビゲーションもありません。ただし、「ここにコードがある、バグを見つけろ」というよりも少しだけ助けを与え、検索戦略とIDORがどのようなものかについてのいくつかのヒントを提供しました。 これはプロンプティング対ハーネスの実験として始まりましたが、実行中に私たちは本当に衝撃を受けました。私たちの足場が何もないオープンウェイトモデルの1つが、フロンティアコーディングエージェントを上回ったのです。 ### GLM-5.2の紹介 GLM-5.2について聞いたことがないとしても心配ありません。私たちもソーシャルメディアで見るまで知りませんでしたし、ベンチマークに追加しようと思いました。GLM 5.2はZhipu AI（Z.ai）の最新モデルで、2026年6月13日土曜日にGLM Coding Planメンバーにリリースされ、オープンウェイトとリリースノートはその3日後の6月16日に公開されました（私たちがそれについて聞いたのはその時です）。セキュリティ作業にとって興味深い3つの点があります。 第一に、オープンウェイトであることです。これは、モデルのパラメータがMITライセンスの下で公開されていることを意味し、ダウンロードして自分のハードウェアで実行したり、ファインチューニングしたり、検査したりできます。機密性の高い分野で作業する多くのセキュリティチームにとって、これは重要です。オープンウェイトモデルは、完全に自分の環境内で実行できます。ただし、「オープンウェイト」は「オープンソース」と同じではないことに注意することが重要です。訓練済みウェイトはリリースされますが、訓練データと完全なパイプラインは一般的に公開されません（ただし、Z.aiはRL訓練フレームワークを公開しています）。 第二に、コーディングにおいて本当に競争力があることです。GLM 5.2は、合計約7500億のパラメータを持つものの、トークンあたり約400億しかアクティブにならないMoE（Mixture-of-Experts）モデルであり、そのサイズに比べて推論コストを低く抑えます。使用可能なコンテキストは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を記録し、クローズドフロンティアモデルをわずかに上回り、最上位には一桁のパーセンテージでわずかに及ばない結果です。 第三に、コストです。トークノミクスは、LLMの機能そのものと同じくらい重要になりつつあります。報告されている価格設定は、同等のフロンティアモデルの約6分の1であり、オープンモデルを密接に追跡しているコメンテーターは、GLM 5.2の評価をDeepSeekと比較しています。GLM-5.2は、トークノミクスだけでなく、フロンティアクラスのクローズドモデルが、報告されたジェイルブレイク後に新しい輸出制限を受けた直後に登場したため、緊張感のある時期にリリースされました。リリースノートの1つの詳細は、このモデルをコードに向ける人にとっては注目に値します。Z.aiは、GLM 5.2がGLM 5.1よりも多くの報酬ハッキング行動を示すと報告しています。トレーニング中に、保護された評価ファイルを読んだり、参照ソリューションをcurlしてスコアを水増ししたりするなどの行動をとったため、専用のアンチハッキングガードを構築することになったとのことです。これはチームによる正直な開示ですが、もしハッキングのためにモデルを構築していたとしたら…そもそもテストを回避しようとすること以上にハッカーらしいことはありません。 ### 私たちの実験 詳細に入る前に、私たちが何をしようとしていたのか、そして私たちの実験が何であったのかを再確認することが重要です。IDORの簡単な復習です。Insecure Direct Object Reference（IDOR）は、アプリケーションがユーザーIDのような内部識別子をリクエストで公開し、呼び出し元がそのオブジェクトにアクセスすることを実際に許可されているかを確認しない脆弱性クラスです。識別子を変更すれば、他のユーザーのデータを取得できます。 ```python @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は、ビジネスロジックの欠陥と設定ミスの中間に位置し、汚染フローのバグではありません。これが静的解析とLLMの両方にとって難しい点です。危険な関数を特定するのではなく、欠けているチェックがあるだけだからです。また、IDORは実社会で最も一般的な発見の1つでもあります（現在、HackerOneの脆弱性タイプトップリストで4位）。そのため、私たちはベンチマークとして常にIDORに戻ってきます。 それで、私たちの実験に戻りましょう。私たちは3つの要素を一定に保ち、1つを変化させました。これは標準的な実験条件です。一定に保ったもの：IDORデータセット（以前の調査で使用したのと同じ実際のオープンソースアプリケーション）、評価方法（既知の真陽性セットに対するF1スコア）、IDORシステムプロンプト自体。変化させたもの：モデルとそのハーネス。具体的には、次のとおりです。 * Semgrep Multimodalは、カスタムハーネス内で実行されました。これは、エンドポイントを列挙し、モデルをそれらに向けるものです。その背後にある2つのフロンティアモデルでテストしました。 * しかし、私たちはClaude CodeをClaude Code SDKを通して、他のプロバイダーモデルをネイティブSDKを通して、同じプロンプトで実行しました。 * GLM 5.2、MiniMax M3、Kimi K2.7 Codeを含むオープンウェイトモデルは、IDORプロンプトとそれ以外は何も与えられない単純なPydantic AIハーネスで実行されました。 これは重要な詳細なので、2回繰り返します。オープンウェイトモデルには、マルチモーダルパイプラインが受け取るエンドポイント発見の足場は与えられませんでした。彼らはプロンプトとコードベースを見ました。これは、何の助けもなしに彼らが達成できることです。 また、有効性のいくつかの異なる尺度を計算しました。 * **精度 (Precision)**: 検出器がIDORとしてフラグを立てたすべてのもののうち、どれだけが本当のものでしたか？高精度 = 誤警報が少ない。10個のバグを報告し、7個が本物であれば、精度は70%です。 * **再現率 (Recall)**: データセットに実際に存在するすべての真のIDORのうち、どれだけを発見しましたか？高再現率 = いくつかの本物のバグを見逃す。20個の真のIDORがあり、12個を検出した場合、再現率は60%です。 * **F1**: 精度と再現率のバランスをとる単一の数値。それらの調和平均です。F1 = 2 × (精度 × 再現率) / (精度 + 再現率)。単純な精度ではなくF1を使用する理由は、2つの目標