SAST vs SCA vs DAST vs IAST：各開発フェーズに応じた最適なスキャンの選び方
本ブログは「Harness」社で2026年9月30日に公開された「 SAST vs SCA vs DAST vs IAST: choosing the right scan for the right stage 」の日本語翻訳です。
ほとんどの AppSec チームは、1種類のスキャンだけを実行しているわけではありません。単一のツールで全体像を把握できるものはないため、パイプラインのさまざまな段階で複数のスキャンを実行しています。本記事では、SAST、SCA、DAST、IAST を比較し、それぞれが実際に何をテストするのか、ソフトウェア開発ライフサイクル（SDLC）のどこに位置づけられるのか、そして作業を重複させたり開発者を大量の検出結果で溺れさせたりすることなく、どのように組み合わせればよいのかを解説します。
実際に解決しようとしている問題は何か？
ツールを比較する前に、「自分のコードは安全に書かれているか？」「自分のコードは安全でない依存関係を使っていないか？」「稼働中のアプリケーションに悪用可能な穴はないか？」という問いを切り分けておくと役立ちます。これらは3つの異なる問いであり、すべてに答えられる単一のスキャン手法は存在しません。さらに4つ目の問い、「稼働中のアプリの中をデータが流れるとき、コードはそのデータを実際にどう扱っているのか？」を考えると、比較はより微妙なものになります。
SAST、SCA、DAST は、それぞれ最初の3つの問いのうち1つにうまく答えます。IAST はその中間に位置し、実際の実行を監視することで、4つ目の問いに一定の形で答えます。
SAST vs SCA vs DAST vs IAST：それぞれがテストするもの
SAST：実行前の自社コード
静的アプリケーションセキュリティテスト（SAST）は、ソースコード、バイトコード、またはバイナリを、実行することなく検査します。コードベース全体を調べ、サニタイズされていない入力がデータベースクエリに到達している、認証情報がハードコードされている、暗号関数が安全でない方法で使われている、といった既知のリスクの高いパターンを探します。
稼働中のアプリケーションを必要としないため、SAST はコードが書かれたその瞬間から実行でき、多くの場合、開発者の IDE 内やプルリクエストのチェックの一環として直接実行されます。その代わり、実際の振る舞いを観察するのではなく、コードを構造的に推論するため、実際の実行を観察する手法に比べて誤検知率が高くなる傾向があります。
SCA：ソフトウェアサプライチェーンの中身
ソフトウェア構成分析（SCA）は、自社のコードそのものはまったく見ません。見るのは、コードが依存しているものです。SCAはオープンソースライブラリやサードパーティのパッケージを棚卸しし（多くの場合、ソフトウェア部品表（SBOM）を生成または利用します）、それらを既知の脆弱性データベースと照合します。照合には通常、CVE 識別子が使われます。
SCA は高速に実行でき、まったく異なる種類のリスクを捉えます。つまり、自分が書いたコードではなく、インポートしたライブラリに含まれる脆弱性です。主な制約は、指摘されたライブラリ内の脆弱な関数が、実際にアプリケーションから到達可能か、あるいは使われているかを一般的に判別できない点です。そのため、「クリティカル」な検出結果が実際のリスクを示しているとは限りません。
DAST：外部からアプリケーションを攻撃する
動的アプリケーションセキュリティテスト（DAST）は、アプリケーションをブラックボックスとして扱います。攻撃者が使うような手法と同様に細工した HTTP リクエストを稼働中のアプリケーションに送り、そのレスポンスを評価して、SQL インジェクション、認証の不備、設定ミスといった脆弱性の兆候を探します。
DAST はソースコードへのアクセスを必要としないため、自社で開発していないアプリケーションのテストや、本番に近いトラフィック条件下でのアプリケーションの振る舞いの検証に役立ちます。その代わり、可視性には限界があります。DAST は何かが壊れたことは教えてくれますが、問題がコードのどこにあるのかまでは特定できないことがよくあります。
IAST：実行中のコードを内部から監視する
インタラクティブアプリケーションセキュリティテスト（IAST）は、アプリケーションのランタイム内にエージェントを組み込み、機能テスト、QA サイクル、通常利用といった日常的なテストの中で、データがコード内をどのように流れるかを監視します。入力にタグを付けてアプリケーション内を解析し（テイント解析と呼ばれる手法です）、信頼できないデータが適切な処理を経ずに機密性の高い処理に到達したケースを検出します。
IAST は、SAST のコードレベルの可視性と、アプリケーションが実際に稼働している必要があるという DAST の特性を併せ持っています。そのため、誤検知が少なく、行単位でより正確な検出結果が得られる傾向があります。その代償は運用面にあります。エージェントの組み込みにはセットアップと保守の負担がかかり、大規模でポリグロットなマイクロサービス環境では、きれいにスケールしません。
SDLCにおけるそれぞれの位置づけ
ソフトウェア開発ライフサイクルに沿って並べると、これら4つのツールは自然に2つのグループに分かれます。
- ランタイム前（アプリケーションがビルドされ稼働する前）：SAST と SCA が該当します。 どちらもデプロイするものがまだない段階で、コードと依存関係に対して実行できます。そのため、通常はコミット、プルリクエスト、CI の初期段階に組み込まれます。
- ランタイム（アプリケーションがデプロイされ実際に動かされている段階）：DAST と IAST が該当します。 どちらもテスト対象として稼働中の何かを必要とするため、検出結果はパイプラインの後半、通常は QA、ステージング、またはプリプロダクションで得られます。
これこそが、好みではなく段階に応じてスキャンを選ぶという考え方の核となるロジックです。修正は早ければ早いほどコストが低いため、早期に捉えられるものは早期に捉え、静的解析では構造的に見えないものを捉えるためにランタイムテストを重ねていきます。
適切な段階に適切なスキャンを選ぶ
判断の対応付けを実践的に整理すると、次のようになります。
- 新しいコードを書いている、またはプルリクエストをレビューしている場合は？： SAST を、できるだけ開発者に近いところで実行します。
- 依存関係を追加または更新する場合は？： SCA を、定期的にではなく、理想的にはすべてのビルドで実行します。
- デプロイ済みのアプリケーション（ソースにアクセスできないものも含む）をテストする場合は？： DAST を実行します。
- ステージング環境で機能テストや回帰テストを実行しており、そのテストから正確なコードレベルの検出結果を得たい場合は？： IAST を実行します。
- 成熟したパイプライン全体のリスクを評価する場合は？： チームの実際のギャップに合わせて調整した、4つすべての組み合わせです。
これら4つのスキャン手法のどれかが、他を包含する上位互換というわけではありません。SAST を実行しているからといって SCA を省けば、依存関係のリスクは測定されないままになります。IAST を実行しているからといって DAST を省けば、エージェントを組み込めないアプリケーションに対するブラックボックスの視点が失われます。適切な組み合わせは「最良」のツールを1つ選ぶことではなく、技術スタック、チームの成熟度、そして吸収できる運用負荷によって決まります。
開発者に過度な負担をかけない多層的な戦略を構築する
最もよくある失敗パターンは、間違ったツールを選ぶことではありません。トリアージ戦略を持たずに4つすべてを実行し、優先度の低い検出結果で開発者を埋もれさせてしまうことです。次のようなプラクティスが役立ちます。
- 重複する検出結果を排除する。： SAST と IAST は、同じ根本的なコードの問題を両方とも指摘することがあります。どの種類の検出結果について、どのツールを信頼できる情報源とするかを決めておきましょう。
- 重大度だけでなく、悪用可能性で優先順位を付ける。： 到達不能なコードパス上の SCA の検出結果は、同じ CVSS スコアであっても、到達可能なものより優先度を下げるべきです。
- ツールをチームの能力に合わせる。： 大規模なマイクロサービス環境全体で IAST エージェントを維持できるだけのプラットフォームの成熟度がない場合、それは無理に押し通すべきギャップではなく、尊重すべき現実的な制約です。
- 結果を一元化する。： SAST、SCA、DAST、IAST の検出結果を1つのビューに集約することで、4つのバラバラなバックログを管理するのではなく、SDLC 全体にわたるリスクを把握できるようになります。
まとめ
SAST、SCA、DAST、IAST は、互いに競合する選択肢ではありません。SDLC のさまざまな段階で異なる問いに答える、補完し合うツールです。目指すべきは単一の最良のスキャン手法を見つけることではなく、各ツールが他のツールの残したギャップをカバーするパイプラインを構築することです。
SAST、SCA、DAST、IAST の結果を個別に管理するのではなく、1つのパイプラインに統合したいとお考えなら、アプリケーションセキュリティテストを CI/CD ワークフローに直接組み込む方法について、ぜひご相談ください。
