IASTとは？SAST・DASTとの違いと実行時検査の実装・導入判断を実装視点で解説

SASTを入れたら誤検知の山が積み上がり、DASTを足したら「どのコードが悪いのか」が分からない。この2つの不満を同時に解こうとして出てくるのがIASTです。ただし、エージェントを入れれば勝手に見つけてくれる道具ではありません。この記事では、定義とテイント追跡の仕組み、SAST・DAST・RASPとの違い、パッシブ型とアクティブ型の分かれ目、ツール選定軸とCI/CDへの組み込み、採用と見送りの判断基準を実装者目線で整理しました。

まとめ：IASTの守備範囲と導入判断の分かれ目

先に結論を置きます。IASTは、テストを流している最中のアプリケーション内部にエージェントを住まわせ、外部からの入力が危険な処理へ届くまでの経路を実行時に追いかける検査手法です。実際に到達した事実を根拠にできて、コード行まで指し示せる。この2点が固有の値打ちになります。

一方で制約もはっきりしています。IASTが見られるのは、テストが実際に通った経路だけ。E2Eのカバー率が4割なら検査対象も概ね4割で、テスト資産が薄い現場へ先に入れても静かな結果が返るだけで終わります。

判断の順序はこう置いてください。まずSASTで書いた側を、DASTで動いた側を押さえる。そのうえで「誤検知のトリアージに人手が溶けている」「DASTの指摘からコードへ辿るのに時間がかかる」という具体的な痛みが出てから、IASTを足す。対応言語とテスト資産の2つが揃わない段階では、投資が回収できません。

IASTの定義と検査原理｜実行中のコード内部から脆弱性を見つける仕組み

まず、この手法が何を見ているのかを揃えます。名前の「インタラクティブ」が取り違えられやすいためです。

IASTの定義とエージェントが実行時に脆弱性を捉える対象範囲の境界

IAST（Interactive Application Security Testing、インタラクティブアプリケーションセキュリティテスト）は、アプリケーションの実行環境へ検査用のエージェントを組み込み、テストや操作でコードが動いている最中に内部の挙動を観測して脆弱性を検出する手法を指します。

「インタラクティブ」は、利用者が対話的に操作するという意味ではありません。テスト実行という外からの働きかけと内部の観測が組み合わさって初めて成立する、という検査構造を指した呼び方です。

観測できる範囲は、エージェントが差し込まれたプロセスの内側に限られます。HTTPリクエストの中身、そこから派生した変数、データベースへ渡ったクエリ文字列まで。プロセスの外側にあるネットワーク機器の設定やインフラの構成不備は守備範囲の外です。

テイント追跡でソースからシンクまでのデータの流れを追う判定の仕組み

検出の中核はテイント（汚染）追跡と呼ばれる考え方です。外部から入ってきた値に「信用できない」という印を付け、その値がプログラムの中を渡り歩く様子を実行時に追いかけます。

印を付ける起点をソースと呼びます。該当するのはHTTPのパラメータ、ヘッダ、Cookie、アップロードされたファイル名など。追跡の終点はシンクで、SQL実行・OSコマンド実行・ファイル操作・画面出力といった、危険な入力を渡されると事故になる処理が並びます。ソースの値が加工されないままシンクへ届いたと分かった瞬間、それが検出です。

この経路上に、エスケープ処理やバリデーションといった無害化の関数が挟まっていれば、印は外れて検出されません。ここがSASTとの精度差になります。SASTはコードを読んで「届きうる」と推定しますが、IASTは実際にその値がシンクへ到達した事実を見ているため、届かない経路を誤って報告しにくい構造です。

エージェントの組み込み方とアプリ起動時に差し込む設定項目の実装手順

組み込み方は言語のランタイムごとに決まっています。Javaであれば起動オプションへ-javaagentを指定してエージェントのJARを読み込ませる形が一般的で、アプリケーションのソースコードには手を入れません。.NETならプロファイラAPI経由、Node.jsやPythonなら専用パッケージの読み込みになります。

APM（アプリケーション性能監視）を既に入れている環境では、その計装を共用する構成も選べます。Datadogの実行時コード解析（IAST）はAPMと同じトレーシングライブラリを土台にし、対応言語としてJava・.NET・Node.js・Pythonの4系統を挙げています（2026年8月時点の公式ドキュメント実測）。追加の計装を挟まずに検査を有効化できる点が利点です。

設定で必ず決めるのは、エージェントを有効にする環境・検出結果の送信先・除外設定の3項目。除外は、意図的に脆弱な入力を投げるテストシナリオが混ざる現場ほど効いてきます。

IASTとSAST・DAST・RASPの違い｜検査時点と検出根拠の分担

4つの手法は名前が似ており、混同されがちです。検査する時点と検出の根拠という2軸で並べると区別がつきます。

検査時点で並べたSAST・DAST・IAST・RASPの守備範囲の比較表

並べると、それぞれが埋めている穴の位置が見えます。

SASTの詳しい検査原理とツール選定はSASTの守備範囲とDAST・SCAとの役割分担、外部から擬似攻撃を投げる方式の実装はDASTの検査原理とCI/CDへの組み込み設計にそれぞれまとめています。本記事はIASTの実装に絞っているため、比較の先はそちらを参照してください。

SASTの誤検知の多さとDASTの原因特定の弱さをIASTが埋める点

SASTの悩みは、報告された件数のうち手を入れるべきものを選り分ける工数にあります。到達しない経路やフレームワーク側で既に無害化されている箇所まで拾うため、トリアージの人件費が本体の費用を上回る場面も珍しくありません。IASTは実際にシンクへ届いた事実を根拠にするので、この負荷が下がります。

DASTの悩みは逆方向です。外から投げて応答の異常を見る方式では「この画面のこの入力が危ない」までは分かっても、原因となったコードの位置までは辿り着けず、修正担当者が自力で追跡し直す工程が挟まります。IASTは内部を見ているため、検出と同時にスタックトレースとコード行を返せる仕組みです。

RASPと同じエージェント基盤でも用途と稼働環境が分かれる境界線

RASP（Runtime Application Self-Protection）は、IASTとほぼ同じ計装技術の上に乗っています。実行時にアプリケーション内部を観測する点まで共通で、製品によっては同じエージェントの設定切り替えで両方の機能を提供します。

分かれるのは目的と稼働先です。IASTは検査であり、テスト環境で脆弱性を「見つけて直す」ための道具。RASPは防御であり、本番環境で攻撃を「検知して止める」ための仕組みになります。前者の成果物は修正チケット、後者の成果物は遮断ログです。

パッシブ型とアクティブ型の違い｜検出方式が精度と実行負荷に効く境界

IASTを名乗る製品でも、検出の取り方は2系統に分かれます。この違いが検出件数と確度、実行時の負荷を左右します。

既存のテスト通信を観測するだけのパッシブ型の挙動と導入に適した条件

パッシブ型は、既に流れているテストの通信をただ観測します。追加のリクエストは送らず、テスト担当者や自動テストが投げた入力が内部でどう流れたかだけを記録して判定する方式です。市場に出ている製品の多くがこの系統に属します。

利点は導入の軽さにあります。既存のE2Eテスト、手動の受け入れテスト、開発者がローカルで画面を触る操作まで、そのすべてが検査の入力になるため、シナリオを検査用に書き足す必要がありません。

弱点は、テストが踏まなかった経路を一切見られないところ。正常系だけを流すテスト資産では、異常系の入力でしか露見しない欠陥が出てきません。テストの網羅率がそのまま検査の網羅率になると理解したうえで導入してください。

検証用リクエストを追加で送るアクティブ型が確度を上げる仕組みと制約

アクティブ型は、観測しながら検証用のリクエストを自分でも投げます。テイント追跡で「怪しい経路」を見つけた時点で、その入力点へ安全に加工した検証用の値を送り、本当に脆弱性として成立するかを確かめる作り方です。Black DuckのSeekerがこの系統として知られています。

この一手間が確度を押し上げます。届いているという観測に加え、実際に成立するという裏取りまで済んだ状態で報告されるためです。

制約は、検査対象へ余分な通信が発生する点です。検証用の入力がデータベースへ書き込まれる、メール送信が走る、外部APIの呼び出し回数を消費する。こうした副作用が起きうるため、本番と共有している資源へ向けて動かす構成は避けてください。

実行時オーバーヘッドと本番投入の可否を分ける負荷の見積もりの手順

エージェントは、シンクに当たる処理へフックを挟んで動くため、処理時間は伸びます。ベンダーや比較記事では数パーセント台という数字が示されることが多いものの、実際の増分はシンクの呼び出し密度に強く依存する点へ注意してください。

見積もりの手順は単純です。エージェントなしで負荷試験を回して応答時間のp95とp99を取り、エージェントを入れて同じシナリオを回し、差分を見る。SQLを1リクエストあたり数十回発行する処理では、平均値に現れない増分がp99へ出ることもあります。

主要IASTツールの比較軸｜Contrast・Seeker・Datadogの選び分け

製品数はSASTやDASTより絞られ、選定の自由度は高くありません。実務では次の3軸で候補が決まります。

対応言語とランタイムで候補が絞り込まれる選定の第一関門と確認手順

最初の関門は言語です。エージェント方式である以上、そのランタイム向けの実装が提供されていない言語では動きません。Java・.NET・Node.js・Pythonは主要製品が揃って対応しますが、GoやRuby、PHPは製品によって対応状況が分かれ、RustやElixirでは選択肢がほぼ無い状態になります。

言語の次に見るのは実行形態になります。コンテナで動かすならイメージへエージェントを同梱するか、初期化コンテナで注入する構成が要ります。サーバーレス関数は常駐プロセスを前提とした計装と噛み合わないため、対応が限られる領域です。確認は、候補製品の公式ドキュメントで対応言語表とランタイムのバージョン範囲を突き合わせる作業から始めてください。

Contrast・Seeker・Datadogの3系統で分かれる導入経路と検出方式

代表的な製品を系統で並べます。

選び方の目安を示します。既にDatadogでAPMを回している現場なら、計装を共用できる実行時コード解析が導入工数の面で有利です。監視基盤を持たず検査専用に入れるなら、AppSec専業のContrast Assessが素直な選択になります。誤検知を削り、報告された件数をそのまま修正キューへ流したいならSeekerのアクティブ検証が効くでしょう。表の情報は2026年8月時点の各社ドキュメントに基づくもので、対応言語は改版で変わるため導入時に再確認してください。

無償で試せる導線が細くなった現状と検証環境を用意する段取りの決め方

評価を始める前に押さえたい現状があります。個人開発者向けに提供されていたContrast Community Edition（CE）は、公式ドキュメントに2025年6月30日で提供終了と記載されました（2026年8月時点で確認）。無償枠で触ってから稟議を上げる進め方が取りにくくなっています。

成熟したオープンソース実装も限られます。SASTにおけるSemgrepやCodeQLのような、単独で本格運用できる無償の選択肢がIASTには揃っていません。評価はベンダーとのトライアル契約から始まる形が通常でしょう。

そこで段取りを先に決めます。評価用のアプリケーションは実際の案件で使っているフレームワークとバージョンで用意し、意図的に脆弱な入力経路を1本仕込んでおく。そのうえで、既存のE2Eテストを流して検出されるか、応答時間がどれだけ伸びるかを測る。この実測がないままベンダー資料の数字だけで決めると、導入後に何も出ない結果になりがちです。

CI/CDへのIAST組み込み設計｜テストカバレッジが検出範囲を決める

ここが実装の山場です。IASTは既存のテスト工程へ乗せる検査であり、パイプライン設計が検出力を決めます。

E2Eテストの通過率がそのまま検出範囲になる前提と不足の補い方の設計

この前提だけは外せません。カバレッジが低い状態でエージェントを入れても、検出0件という結果が返るだけで、それは安全の証明にはなりません。

導入前に測るべき数字は、E2EテストあるいはAPIテストの行カバレッジです。主要な業務フローの正常系と代表的な異常系が通っている状態、行カバレッジで5割前後を一つの下限に置くと判断しやすいでしょう。ここに届いていない現場では、IASTへ払う費用をテスト整備へ先に回したほうが結果は出ます。

不足を補う手としては、DASTのクローラでエージェント有効の環境を巡回させ、その通信をIASTの入力として使う併用構成があります。網羅的な巡回と内部観測を組み合わせ、シナリオの薄さをある程度まで埋める形です。

パイプラインのどこへ置くかとビルド時間を延ばさない実行の分離設計

置き場所は、E2Eテストや結合テストを実行するステージです。ビルドやユニットテストの段階ではアプリケーションが起動しておらず、検査が成立しません。エージェント有効の環境へデプロイし、テストスイートを流し、その実行中に検出結果が上がってくる流れになります。

プルリクエストごとの実行にこだわらない設計を勧めます。IASTはテスト実行に相乗りする検査なので、テストが長い現場では待ち時間がそのまま伸びるためです。差分に対する速い検査はSASTへ任せ、IASTはナイトリービルドへ寄せる分離が現実的でしょう。

パイプライン全体でセキュリティ検査をどう配置するかという設計思想は、DevSecOpsのライフサイクルと各フェーズの対策で整理しています。IASTはそのライフサイクルのうちテスト段階に置かれる部品として位置づけると、他の検査との重複が避けられます。

検出結果をどこへ返すかとチケット化の基準を決める運用の組み立て方

検出後の経路を決めていないと、ダッシュボードに数字が溜まるだけで終わります。返し先は重大度で分けるのが扱いやすい形です。

基準の例を挙げます。SQLインジェクションやコマンドインジェクションのように直接的な侵害に繋がる検出は、その場でパイプラインを失敗させて修正を必須にする。弱いハッシュ関数やCookieの属性不足といった設定寄りの検出は、チケットを自動起票して次のスプリントで拾う。この2段構えが、検査に開発の足を止め続けさせない要になります。

IASTを導入すべき現場と見送る現場｜受託開発での採用条件と判断基準

最後は判断の話です。IASTは費用も導入工数もSASTより重く、適用場面を選びます。

採用が投資に見合う3つの条件と受託開発で回収できる場面の見極め方

1つ目は、テスト資産が既に厚いこと。E2Eテストが自動化され主要フローが日次で通っている現場なら、追加のシナリオ整備なしで検査範囲が確保できます。

2つ目は、SASTの誤検知トリアージが実際の負担になっていること。週に何時間をこの選り分けへ使っているかを測り、その時間が製品費用に見合うなら投資は回収できます。感覚ではなく実測で判断してください。

3つ目は、対応言語で構築していること。JavaまたはC#の業務システムであれば、どの製品を選んでも計装は成立します。3条件のうち1つでも欠けている現場では、先にそこを埋めるほうが費用対効果は高くなるでしょう。

見送るべきプロジェクト側の条件と代替手段へ切り替える判断の軸と代案

見送りを勧める条件は3つ。テストが手動中心で自動化されていない場合、エージェントを入れても検査の入力が発生しません。次に、本番稼働までが数か月に満たない短期の受託案件では、導入と調整の工数が回収できない計算になります。

3つ目は、対象がフロントエンドのみ、あるいはSaaSの設定作業が中心という場合。サーバー側で動くコードが薄い構成では、テイント追跡の対象そのものが少なく、検査の値打ちが出ません。

代替としては、公開前に外部から一括で診断を受ける手段が現実的です。手法や費用相場の整理は脆弱性診断の種類・費用相場・進め方にまとめています。エージェント導入の工数を割けない体制であれば、脆弱性診断・セキュリティ診断のように、診断の実施から報告書の読み解き、修正方針の検討までを外部へ預ける選び方も取れます。

SAST・DASTと組み合わせて段階的に広げる導入順序の決め方と基準

3手法を同時に入れる進め方は勧めません。検出が一斉に上がり、どの検査からの指摘なのかを追う工数で現場が止まります。

順序としては、SASTを先に入れて書いた側を押さえ、ルールを絞り込んで誤検知を落ち着かせる。次にDASTを結合テスト環境へ足し、外から見える欠陥を拾う。この2つが定常運用に乗り、それでもトリアージの負担か原因特定の遅さが残った段階でIASTを検討する。各手法が何を埋めているのかを実感として掴める順序です。

広げ方も段階的にしてください。まず1サービスへ入れて3か月ほど運用し、検出件数・誤検知率・応答時間の増分を実測したうえで横展開の可否を決める。全社一斉導入は、エージェントのバージョン管理と例外設定の保守という負担を、実態を掴む前に背負い込む進め方です。

よくある質問

IASTの導入検討でよく受ける質問を整理します。

IASTを入れればSASTとDASTは不要になりますか？

置き換えにはなりません。SASTはテストが1本も無い段階でもコードを検査でき、コミット直後の速いフィードバックを返せます。DASTはエージェントを入れられない他社提供の連携先まで外から検査できる手法です。IASTが埋めるのは、この2つの間にある「実行時に到達した事実をコード行と結びつける」領域。3つを重ねる前提で、どこから入れるかを順序の問題として扱ってください。

IASTのエージェントは本番環境で動かしても問題ありませんか？

検査目的での常時稼働は勧めません。理由は2つ。1つは負荷で、シンクへのフックによる処理時間の増分が利用者へ影響します。もう1つはデータの取り扱いで、本番の実データがテイント追跡の対象となり、検出結果の詳細情報へ含まれる経路ができてしまう点。本番で守りたい場合はRASPやWAFという別の仕組みを選び、検証環境で実データに近いテストデータを流す構成へ寄せてください。

テストコードが少ない状態でIASTを導入しても意味はありますか？

検出範囲がテストの通過範囲に限られるため、効果は限定的です。ただし、手動の受け入れテストや開発者が画面を触る操作も入力として拾える点は押さえておいてください。テスト自動化が進んでいない現場でも、リリース前の受け入れテスト期間にエージェントを有効化しておけば、その操作範囲は検査できます。まずはこの形で試し、効果が見えたらテスト自動化へ投資を回す進め方が現実的でしょう。

IASTとSCA（ソフトウェア構成分析）は何が違いますか？

見ている対象が別物です。SCAが調べるのは、依存しているライブラリのバージョンと既知の脆弱性情報との突き合わせで、自社が書いたコードは見ません。IASTが見るのは自社コードを含む実行時のデータの流れで、ライブラリの版数は判定材料にしていない仕組みです。ただしIASTのエージェントは実行時にロードされたライブラリを把握できるため、実際に呼ばれた依存関係だけを対象にしたSCA機能を併せ持つ製品もあります。両方を並べる前提で考えてください。

マイクロサービス構成でもIASTは導入できますか？

導入自体は可能ですが、単一のアプリケーションより手間が増えます。サービスごとにエージェントを組み込む必要があり、コンテナイメージの構成変更とバージョン管理が発生する構成です。もう一つの難所は検出の解釈で、サービスAで受けた入力がサービスBのシンクへ届く経路は、各エージェントが自分のプロセス内しか見ていないため、そのままでは繋がって見えません。分散トレースと組み合わせて相関を取る作りが要ります。まずは外部入力を直接受ける前段のサービスへ絞り、そこから広げてください。

関連記事

• Dockerの脆弱性診断をCI/CDに組み込む手順とツール選定：コンテナ側の検査をパイプラインへ乗せる手順です。
• Burp Suiteとは？通信傍受の仕組みとエディションの選び方：手動で入力経路を確かめる道具と初期設定を確認できます。
• セキュアコーディングとは？10原則と主要脆弱性のコード対策：検出を減らすため前段で決める実装規約です。