CLOUD SECURITY LAB

LLM SAST vs DAST: コードを「読む」AIと「叩く」AI、何が違うのか？

—

by

cslab
in

静的か動的か、それが問題だ。

— そしてLLMがその答えを書き換えている。

>

この記事で扱うこと

  • SASTとDASTの本質的な違いを5分で解説
  • LLMが両陣営にもたらしたゲームチェンジャーの変化
  • LLM SASTとLLM DASTの強み・限界を比較
  • 実務導入時に直面する落とし穴とコスト構造
  • DevSecOpsパイプラインに組み込むための段階別ガイド

導入：セキュリティテスティングが再び注目される理由

今日、コードは人間よりも速く作られています。Copilot、Cursor、Claude CodeのようなAIアシスタントが毎日何万行ものコードを生成し、開発者はレビューする間もなくPRをマージしています。問題は、そのように急速に増えたコードが、同じ速さで安全になるわけではないということです。

従来のSASTとDASTは、この時代の速度についていくのが困難です。ルールベースのスキャナーはfalse positive（誤検知）を爆弾のように大量に放出し、開発者は最終的にアラート自体を無視するようになります。業界ではこれを「アラート疲労」と呼んでいます。「オオカミ少年が何度も叫びすぎると、本当にオオカミが来ても誰も信じない」という現象です。

ここにLLMという変数が加わりました。コードの意味を理解するAIが登場したことで、セキュリティテスティングの状況が再び揺れ動いています。

SASTとDAST、何が違うのか？

まず基本から確認しましょう。

SAST (Static Application Security Testing)

  • 一言で要約：「コードを広げて読む」
  • 分析対象：ソースコード、バイトコード、バイナリ
  • タイミング：ビルド段階（実行しない）
  • 視点：ホワイトボックス — 内部構造を知っている
  • 検出するもの：SQLインジェクションパターン、ハードコードされたパスワード、安全でない関数呼び出し、データフローの脆弱性

DAST (Dynamic Application Security Testing)

  • 一言で要約：「アプリを実際に叩いてみる」
  • 分析対象：実行中のアプリケーション（HTTPリクエスト・レスポンス）
  • タイミング：ステージングまたは運用環境
  • 視点：ブラックボックス — 内部を知らずに外部から攻撃
  • 検出するもの：認証・認可の迂回、セッション管理の欠陥、サーバー設定エラー、実際に発生するXSS

簡単な比喩でまとめるとこうなります。

SASTは、建物の設計図を広げて「この壁は薄すぎる、崩れる危険がある」と指摘する建築審査官のようなものです。

DASTは、実際の建物にハンマーを持って行き、「ここが本当に崩れるな」と確認する安全点検官です。

どちらも必要です。設計図だけでは施工の不備を見つけられず、叩くだけでは設計の欠陥を見つけられません。

LLMがもたらした変化：パターンマッチングから意味理解へ

従来のSASTの慢性的な問題

既存のSASTツールの核は、結局のところパターンマッチングです。AST（抽象構文木）をパースして、事前に定義されたルールにマッチさせます。そのため、限界が明確です。

  • コンテキストを理解しない → 「この入力値はすでに上位のミドルウェアで検証済みだ」と認識できない
  • 意図を理解しない → 安全なコードを危険だと主張する
  • 結果は？ false positiveの大量発生、開発者の信頼喪失

従来のDASTの慢性的な問題

DASTは、決められたペイロードを機械的に投げつけます。SQLインジェクションペイロード1番から100番まで、XSSペイロード1番から50番まで…そのため、以下を検出できません。

  • ビジネスロジックの欠陥：「1万ポイント使用 → 払い戻し時に1万5千ポイント払い戻し」のような論理的な欠陥はそのまま通過
  • 多段階シナリオ：ログイン → 注文 → 決済といったフローの微妙な欠陥を追跡できない
  • ワークフロー理解の欠如：単発のペイロードを投げるだけで終わる

LLMが導入されたとき

LLMはコードとHTTPトラフィックを言語として捉え、パターンではなく意味を理解します。これにより、両陣営に大きな変化が起こりました。

LLM SAST陣営の変化

  • データフロー追跡時に意味を理解 → 「この変数はユーザー入力であり、検証なしでSQLに挿入される」と自然言語で推論
  • 自動修正コードの提案 — 単なる警告ではなく、「このように修正できます」というPRを自動生成
  • 脆弱性の説明を自然言語で → ジュニア開発者も即座に理解
  • 代表的なツール：GitHub Copilot Autofix, Snyk DeepCode AI, Amazon CodeGuru Security, Checkmarx One AI Security Champion

LLM DAST陣営の変化

  • ペイロードをLLMが状況に合わせて生成 → 応答を見て次の攻撃を調整
  • ビジネスロジックの脆弱性検出 → 多段階シナリオを自動生成
  • 応答を意味的に解釈 → 「エラーメッセージにDBスタックトレースが露出している」ことをLLMが認識
  • 代表的なツール：PortSwigger Burp Suite AI, ZAP AI, StackHawk AI

同じ脆弱性、異なる視点

同じSQLインジェクションを両陣営がどのように異なる視点で見ているか見てみましょう。

# 脆弱なコード
def get_user(user_id):
    query = f"SELECT * FROM users WHERE id = {user_id}"
    return db.execute(query)

LLM SASTの視点

「user_idが関数パラメータとして渡され、検証やエスケープなしにf-stringでSQLクエリに直接挿入されています。これはSQLインジェクションの脆弱性であり、パラメータ化クエリ（プリペアドステートメント）に変更する必要があります。以下のように修正してください。」

# 自動提案されたパッチ
def get_user(user_id):
    query = "SELECT * FROM users WHERE id = %s"
    return db.execute(query, (user_id,))

LLM DASTの視点

  1. /users?id=1 リクエスト → 正常応答を確認
  2. /users?id=1′ OR ‘1’=’1 リクエスト → 全ユーザーデータ応答を確認
  3. 応答からPostgreSQLエラーメッセージの露出を発見
  4. 追加ペイロードによるデータ抽出の可能性を確認 → 脆弱性を確定報告

同じ結論に異なる道筋で到達します。そのため、両者は補完関係にあります。SASTは「なぜ危険なのか」を、DASTは「本当に発生するのか」を証明します。

⚠️ LLMセキュリティテスティングの落とし穴

光があれば影がある。LLMベースのセキュリティテスティングにも、注意すべき点が明確に存在します。

1. ハルシネーションのリスク

LLMはもっともらしい嘘をつきます。存在しない関数が「ここで呼び出されている」と主張したり、実際には安全なコードを脆弱だと報告したりすることがあります。検証なしに信頼してはいけません。

2. False Negativeの落とし穴

むしろより危険なのはfalse negative（見逃し）です。LLMが「このコードは安全です」と断言したのに、実際には脆弱だったとしたら？ false positiveが1万個あるよりも、false negativeが1個ある方が致命的です。

3. コード外部流出のリスク

SaaS型LLM SASTを使用すると、社内ソースコードが外部のLLM APIに送信されます。金融機関、公共機関、軍事環境では、これはコンプライアンス違反に直結します。オンプレミスLLM（自社ホスト型オープンソースモデルなど）のオプションを必ず検討する必要があります。

4. コストと応答時間

すべてのPRごとにLLM SASTを実行すると、トークンコストが急速に累積します。また、LLMの応答時間によりCIパイプラインが遅くなる可能性があります。どの段階でどの程度の深さで適用するか、設計が必要です。

5. プロンプトインジェクション — 新たな攻撃面

LLM DASTがペイロードを生成するということは、逆にLLM自体が攻撃対象になる可能性もあるということです。分析対象のアプリがLLMと連携している場合、セキュリティスキャナーのLLMが逆に操られるシナリオまで考慮する必要があります。

️ DevSecOpsパイプラインに組み込む5段階

理想的な適用段階は、このように設計できます。

  1. IDE段階 — 軽量なLLM SAST補助。開発者のコーディング中にリアルタイムヒント
  2. PR段階 — 精密なLLM SAST。変更されたファイルを中心に、自動修正PRを生成
  3. ビルド段階 — 従来のSAST + LLM SASTを並行。速度と正確さのバランス
  4. ステージング段階 — LLM DASTを実行。シナリオベース、ビジネスロジックの点検
  5. 運用段階 — 軽量なDASTモニタリング + RASP（Runtime Application Self-Protection）

肝心なのは「どこに何を置くか」です。すべての段階にすべてのツールを導入すると、コストもアラート疲労も手に負えなくなります。

✅ まとめ：競争ではなくデュエットだ

LLM SASTとLLM DASTは互いに代替品ではありません。同じ問題を異なる角度から見るデュエットパートナーです。コードを読む視点とコードを叩く視点が出会ってこそ、真のセキュリティテスティングが完成します。

LLMは両陣営を「パターンマッチング」から「意味理解」へと引き上げました。しかし、LLMも万能ではなく、人間のセキュリティエンジニアによる検証と組み合わせることで最も強力になります。

次のステップで学習するのに役立つキーワードを挙げておきます。

  • IAST (Interactive Application Security Testing) — SASTとDASTのハイブリッド
  • SCA (Software Composition Analysis) — オープンソース依存関係の脆弱性
  • RASP (Runtime Application Self-Protection) — 運用段階での自己防御
  • AI Red Teaming — LLM自体に対するセキュリティテスティング

Comments

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です