SAST/DAST

SAST/DAST とは

SAST (Static Application Security Testing) はソースコードを解析して脆弱性を検出する手法、DAST (Dynamic Application Security Testing) は実行中のアプリケーションに対して攻撃を模擬し脆弱性を検出する手法である。両者は代替関係ではなく補完関係にある。SAST はコードの構造を見るので「実行しなくても分かる欠陥」に強く、DAST は動いているものへ実際に要求を投げるので「組み上げた結果はじめて現れる欠陥」に強い。得意な欠陥の種類そのものが違うため、片方だけでは構造的に見えない領域が残る。

SAST と DAST の違い

違いは「いつ実行するか」ではなく「何を情報源にするか」から生まれる。SAST はソースという設計情報を持つ代わりに実行時の状態を知らず、DAST は実行時の応答を持つ代わりにコード内部を知らない。

観点	SAST	DAST
解析対象	ソースコード、バイトコード	実行中のアプリケーション
実行タイミング	コーディング〜ビルド時	デプロイ後
検出できる脆弱性	SQL インジェクション、XSS、ハードコードされた秘密情報	認証不備、設定ミス、ランタイムの脆弱性
誤検知	多い (到達不能な経路や独自のサニタイズ処理を判定できない)	少ない (応答で実際の挙動を確認する)
検出漏れ	少ない (コード全体を走査できる)	多い (認証の突破やクロール漏れで到達できない画面が残る)
言語依存	あり (言語ごとのパーサーが必要)	なし (HTTP で通信)
CI/CD 統合	容易 (ビルドステップに追加)	やや複雑 (実行環境が必要)

誤検知と検出漏れがちょうど逆向きになる点が実務上の要点である。SAST は「鳴りすぎる」ので放置すると警告が無視され、DAST は「鳴らない」ので通ったことを安全の証明と誤読しやすい。SAST はハードコードされた資格情報のように実行しても外から見えない欠陥を拾える一方、権限設計の誤り (本人以外の ID を指定すると他人のデータが返る類) はコードとして正常なので判定できない。逆に DAST はログイン後の画面や複数手順の操作を辿れなければその範囲を検査しないまま「検出ゼロ」を返す。

CI/CD パイプラインへの組み込み

実行コストが違うため、同じ頻度で回すと破綻する。SAST は数分で終わるので毎回の push に載せ、DAST は環境の起動とクロールに時間がかかるので夜間やリリース前に回すのが現実的な配置である。

[コード Push] → [SAST スキャン] → [ビルド] → [デプロイ (dev)] → [DAST スキャン]
                     ↓                                              ↓
              脆弱性レポート                                   脆弱性レポート
              (重大なら失敗)                                   (重大なら通知)

SAST はビルド前に実行し、問題があればパイプラインを停止する。DAST はデプロイ後に実行し、結果をチームに通知する。停止条件を最初から厳しくすると既存コードの警告でパイプラインが常時赤くなるため、導入時は既存の検出結果を基準線として除外し、新たに増えた分だけで失敗させる運用から始めるとよい。

主要ツールと SCA の位置づけ

この領域はツールの改称・買収・提供終了が多い。名前を覚えるより、選定のたびに現行の公式ドキュメントで提供状況を確認する習慣のほうが重要である (2026 年 8 月時点の状況を以下に示す)。

カテゴリ	ツール	特徴
SAST	Semgrep	OSS、多言語対応、カスタムルールを自分で書ける
SAST	SonarQube	品質指標とセキュリティを同じ基盤で扱う
DAST	ZAP (Zed Attack Proxy)	OSS、CI/CD 統合が容易
DAST	Burp Suite	商用、手動検証との併用に強い
SCA	Dependabot	依存ライブラリの既知脆弱性を検出し更新 PR を出す

ZAP は 2010 年の公開から長く OWASP のプロジェクトだったが、2023 年 9 月に OWASP を離れており (移行先発表は同年 8 月)、現在はどの財団にも属さず Checkmarx の支援で開発されている。「OWASP ZAP」という旧称の記事が大量に残っているため混同しやすいが、現行の名称は ZAP である。AWS の CodeGuru Reviewer も、2025 年 11 月 7 日以降は新しいリポジトリ関連付けを作成できなくなった。

SCA (Software Composition Analysis) は SAST の一種ではなく、機序の異なる別カテゴリである。SAST がコードの制御フローとデータフローを解析して欠陥を推論するのに対し、SCA は使っている依存ライブラリとそのバージョンを同定し、公開済みの脆弱性情報 (CVE) と照合する。つまり SCA が見つけるのは「他人が既に見つけて公表した欠陥を含む部品を使っていること」であり、自分たちが書いたコードの欠陥は原理的に検出できない。逆に SAST は依存ライブラリの中身までは通常走査しない。npm audit、Dependabot、Snyk、OWASP Dependency-Check が代表的である。

この違いは実際の被害の形にも対応している。自作コードの欠陥は個別のアプリだけの問題で済むが、依存ライブラリの欠陥は同じ部品を使う全アプリに同時に効く。だから SCA は「検出したら直す」より「新しい CVE が公表された瞬間に、自分がその部品を使っているかを即答できる状態にしておく」ことに価値がある。

IAST と RASP

どちらもアプリケーションの内側にエージェントを置く点が共通で、目的が検査か防御かで分かれる。

手法	説明
IAST	アプリ内のエージェントが実行時のコードフローを追跡する。外から要求を投げつつ内部の到達経路も見えるため、DAST の検出漏れと SAST の誤検知を同時に減らせる
RASP	本番環境で攻撃を検知・遮断する。防御側の仕組みであり、検査ツールではない

RASP と WAF はどちらもアプリケーション層 (HTTP) を扱うが、立っている場所が違う。WAF は通信経路の手前で要求の文字列だけを見て判定するため、その入力が最終的にどう使われるかを知らない。RASP はアプリのプロセス内に居るので、その値が実際に SQL 文の組み立てへ渡ったかどうかという実行文脈で判定できる。そのぶん誤遮断は減るが、言語ランタイムごとの実装が必要で、実行時オーバーヘッドと本番アプリへのエージェント組み込みという運用負荷を伴う。

導入順として現実的なのは、まず SCA (投資に対する効果が最も大きい) 、次に SAST を新規差分だけで運用、そのうえで DAST をリリース前に回す形である。IAST と RASP は、検査の体制が回り始めてから検討する段階のものと考えてよい。