オートトリアージにおける推論モデルの使用

ベルク・セベレンス

#AI

#SAST

#オートトリアージ

#トリアージ

掲載日

2025年8月15日

最終更新日

2025年9月8日

TL;DR

推論モデルはほとんどのSASTルールには不要だが、JavaScriptのパストラバーサルといった特殊ケースでは、誤検知を2倍多く検出する。

推論モデルはすべて誇大広告なのか？

「推論モデル」が注目を集めている。主要なAI研究所は主導権争いを繰り広げており、スケーリング法則、より高度な事前学習、RLHF（人間からのフィードバックを用いた強化学習）による微調整を通じて、モデル規模と性能の限界を押し広げている。さらに推論中にモデルが「思考を声に出す」ようにするため、思考の連鎖プロンプティングを組み込んでいる。これにより論理タスクにおいて非AIシステムを圧倒し、リーダーボードの頂点に立つことに成功している。

それは素晴らしいですね。でも実際に役立つのでしょうか？それは状況によります。

AutoTriage*の場合、SAST**ルールの複雑さに大きく依存します。
‍
*簡単な復習 - AutoTriageは、Aikido 誤検知をAikido 機能です。
**SAST検出結果とは とは、ハードコードされたパターン検出器によって報告される、ソースコード内で発見された潜在的な脆弱性を指します。‍
‍

大半のSASTルールに対して過剰に高価

AutoTriageは2段階で動作します：まず脆弱性の悪用可能性を排除しようと試みます。それが可能であれば、誤検知をフィルタリングできます。これには、ユーザー制御変数が脆弱性に到達可能かどうかについて、白黒はっきりした判断が必要です。モデルは基本的に、変数が実際にユーザー制御されているか、サニタイズ/検証/型変換が実施されているかをチェックします。そして何らかの緩和策が存在する場合、それが実際に有効かどうかを判断します。

第二段階は、第一段階で悪用可能性を排除できない場合にのみ実施される。この段階では優先順位付けに焦点を当てる。優先順位は、問題発生の可能性と、問題が発生した場合の深刻度によって定義される。この第二段階は白黒はっきりしないが、主観的な見積もりにも依存する。例えば、完全な文脈が欠如している場合に、変数がユーザー制御下にあると判断される場合などである。

ほとんどのルールについては、これを実行する方法を合理的な数の「経験則」で要約できるため、推論モデルは過剰な処理となる。推論モデルは同程度の精度を持つ傾向があるが、その代償として著しく高いコストが発生する。

なぜ小さな推論モデルが機能するのか

一部のルールは驚くほど複雑で、非推論モデルでは理解が困難です。発する言葉ごとに全く同じ思考スペースを使うと想像してみてください：最初に誰かが「1＋1は何ですか？」と尋ねます。次に、その同じ人物が「26248＋346237は何ですか？」と尋ねます。通常のモデルは複雑さの度合いの変化に苦戦しますが、推論モデルは複雑な入力に対してより多くの言葉を使い、大きな問題をより扱いやすい小さな部分問題に分解することで対応できます。

残念ながら、トークン消費量が多いため、一般的にコストも高くなります。ただし、推論モデルとして構築されたモデルは、非推論モデルに比べてモデル縮小の影響を受けにくいという特徴があります。より大規模なモデルを採用する理由は二つあります：(1) より多くの知識を蓄積する容量がある（ただし脆弱性トリアージの場合、大量の知識は必ずしも必要ではない）。 (2) 大規模モデルは単語単位の精度が若干向上する傾向がある。ただし推論モデルは推論構造により誤りを修正できる。したがってトークン消費量が増加する一方で、トークン単価の低い小規模モデルを実用的に活用し、高いトークン使用量を相殺することが可能である。

JavaScriptにおけるパストラバーサル

パストラバーサルは、推論モデルが真価を発揮できるルールです。なぜなら、その分類が驚くほど複雑だからです。パストラバーサルとは、エンドユーザーが意図されたディレクトリ外のファイルを読み書きできる脆弱性です。例えば、Google Driveがファイルシステム上で各ユーザーごとに専用のフォルダを次のように配置していると想像してください：

GoogleDrive/userId1/
Google Drive/userId2/…

‍次にファイルをダウンロードしたいときは、ブラウザクライアントからGoogleドライブにGETリクエストを送信します。例えばファイル名で 私の犬が靴を食べている.jpgそのファイルが存在する場合、ダウンロードはすぐに開始されます。しかし、次のファイル名を試した場合、どうなるでしょうか： ../userId2/mypasswords.txtもしGoogle Driveがバックエンドをパストラバーサル攻撃から保護していなかったなら、あなたは『私のパスワード.txtそのファイルが存在する場合、別のユーザーからそのファイルを取得します。

異なるパストラバーサル攻撃

パストラバーサルSAST検出結果をトリアージするためには、脆弱性が存在するケースと存在しないケースの違いを理解する必要があります。まずは単純なケースから始め、次第に複雑さを増していく形で進めていきましょう。

パターン1: ‘../’

ここでの明らかな問題は「../」パターンです。この文字列を含むファイルパスから読み書きを行うと、意図したディレクトリを脱出し、想定外の場所を読み書きする可能性があります。したがって、ファイルパス内の「../」チェックがなく、ファイルがクライアント側で指定される場合、深刻な脆弱性が存在します。最悪の場合、ハッカーがシステム上の認証情報を含むファイルを読み取る恐れがあります。

パターン2: ‘..\\’

「../」をチェックしたと仮定しましょう。しかしコードがWindowsシステム上で実行されている場合、再び問題が発生します。なぜなら「..\\」パターンでは依然としてパストラバーサルが可能だからです。ここまでなら問題ありません。チェックすべき経験則は2つだけなので、まだ管理可能ですよね？

パターン3: ‘..’

スラッシュを欠かさずきれいで整ったパスを得るために、多くの人が以下のような関数を使用します： path.resolve() または path.join()ここからが楽しいところだ。こんなものを想像してみてほしい：

if (userControlledSubPath.includes(‘../’) || userControlledSubPath.includes(‘..\\’)|| filename.includes(‘../’) || filename.includes(‘..\\’)) 
{	
   throw new Error(‘Path traversal attempt detected);
}‍

const filepath = path.join(HARDCODED_BASE_PATH, userControlledSubPath, filename);

return fs.readFileSync(filepath);‍

結局のところ、これは依然として脆弱であることが判明した：攻撃者が userControlledSubPath === '..', the path.join それでも1つ上のディレクトリに移動すると解釈されます。

しかし、最後の引数において path.join() その攻撃に対して免疫がある。攻撃者が最後の引数に「..」を指定しようとした場合、 path.join() 関数はファイルパスではなくディレクトリを返すため、無効な読み取り/書き込み操作が発生する。

パターン4: ‘/*’

新たな例では、また次のようなテストがありました：

if (filename.includes(‘..’)) 
{	
    throw new Error(‘Path traversal attempt detected);
}

const filepath = path.resolve(HARDCODED_BASE_PATH, filename);

return fs.readFileSync(filepath);

これは安全そうに見えるよね？チェックは「..」「../」「..\\」のケースをカバーしている——エレガントだ！ところが驚くべきことに、これでもまだ脆弱性が残っている。さあ、その意外な理由をどうぞ…ドラムロール…trrrrrrrrr…引数として path.resolve() スラッシュで始まる場合、それ以前の引数はすべて無視されます。したがって、攻撃者が filename = /etc/passwd のような操作を行うと、 path.resolve() ハードコードされたベースパスを無視し、 /etc/passwd怖いですよね？あの末尾のスラッシュも確認すべきでした。注意してください、 path.join() 安全にできたはずだ。

複雑さを理解する

チャーリー・チャップリンはかつて「シンプルさは単純なものではない」と語った。ここにも同じことが言える：シンプルで効果的な対策は存在するが、まずは攻撃ベクトルの可能性の範囲を理解する必要がある。パストラバーサルに対する最もシンプルで堅牢な対策は、まずパスを解決し、それが意図したベースパスで始まるかどうかを確認することだ。このチェックを回避する方法はない。

しかし、AutoTriageチームには修復方法を選択する余裕はありません。誤検知で顧客を不必要に混乱させないため、代替ソリューションを安全とマークできる必要があります。これまでに4種類のパストラバーサル攻撃ベクトルを確認しており、それぞれ固有の検証項目が存在する。各攻撃ベクトルについて、LLMは攻撃成功に必要な全条件を満たす可能性の有無、あるいは攻撃可能性を完全に排除できるかどうかを検証する必要がある。

推論モデルはほとんどのルールにおいてデフォルトではないにもかかわらず、JavaScriptのパストラバーサルにおいて非推論モデルと比較して2倍の偽陽性を安全にフィルタリングできる。これはノイズ低減において画期的な変化をもたらす。