Webアプリケーション脆弱性診断の項目｜IPA13項目とDAST・SAST・IASTの使い分け

Webアプリケーション脆弱性診断の見積書は、診断項目の数も粒度もベンダーごとに揃っていません。数の多さは品質の証明になりません。判断の起点になるのは、IPAが公開している「ウェブ健康診断仕様」の13項目という公的な基準線と、その13項目のどれを自動ツールが判定でき、どれが人手を要するのかという線引きです。ここではその2つを一次資料から確定させ、DAST・SAST・IAST・SCAの検出範囲の違い、ツールの精度を自分で測る手順、EC加盟店に課される脆弱性対策の位置づけまで通しで整理します。

まとめ

• 診断項目の公的な基準線はIPA別冊「ウェブ健康診断仕様」の13項目（記号A〜M）。ベンダー提案はまずこの13項目の充足で足切りできる。
• 13項目は「必要かつ最小限」の抜き取り調査で、IPA自身が「安全宣言には繋がりません」と明記。上乗せ範囲の設計が発注側の仕事になる。
• 上乗せの基準はOWASP Top 10:2025。新設のA03（サプライチェーン）とA10（例外条件）は13項目に無く、A03はSCA、A10は設計レビューで別建てに手当てする。
• DASTは応答差分や遅延で判定するためインジェクション系に強い。CSRF・認可制御・セッション管理は業務仕様を知らないと判定できず、機械判定は部分的にとどまる。
• 手法の選択は「どの項目を誰が保証するか」の割当であって、優劣の比較ではない。
• ツールの実力はOWASP Benchmark（Java版v1.2・2,740テストケース）で自社が測れる。偽陽性率まで出るのでベンダー資料の検出率より実務判断に使える。
• ECサイトなら、クレジットカード・セキュリティガイドラインが求める脆弱性対策5項目に「脆弱性診断又はペネトレーションテストを定期的に実施し、必要な修正対応を行う」が含まれる。診断は任意施策ではない。

以降で、13項目の中身と判定基準、OWASP Top 10:2025との差分、手法ごとの守備範囲の順に根拠を示します。

診断項目の基準線はIPA「ウェブ健康診断仕様」の13項目

「Webアプリケーション脆弱性診断の項目は何を見ればよいか」に対する日本語圏の一次回答は、IPA「安全なウェブサイトの作り方」の別冊として公開されている「ウェブ健康診断仕様」（全30ページ）です。本編である改訂第7版は全115ページ、最終更新は2021年3月31日の第4刷で、第1章がウェブアプリケーションのセキュリティ実装11種類、第2章がウェブサイトの安全性向上の取り組み7項目、第3章が失敗例8種類という構成になっています。別冊はこのうち診断で確認すべき項目を絞り込み、検出パターンと判定基準まで書き下したものです。

成り立ちも押さえておく価値があります。この別冊は、財団法人地方自治情報センター（LASDEC）が地方公共団体向けに実施したウェブ健康診断事業の仕様を引き継ぎ、2012年12月26日にIPAが公開したもの。項目は、危険性の高いもの、平成19年度のWebアプリケーション脆弱性診断事業で検出数が多かったもの、社会問題化した事案の原因になったもの（クローラへの耐性）などを基準に選ばれています。仕様自身が「一般にウェブアプリケーションの脆弱性診断サービスとして提供されているものよりも簡素です」と述べているとおり、最新の攻撃手法の網羅ではなく、外せない基礎の集合として読むものです。

なお、ここで扱うのはアプリケーションが受け取る入力と返す出力を対象とした診断です。OS・ミドルウェア・公開ポート・既知CVEの残存を見るプラットフォーム診断（ネットワーク診断）は対象レイヤーが別で、Webアプリ診断では検出されません。両方の見積もりを1枚で受け取ると範囲が混ざりやすいため、発注時に切り分けておいてください。

13項目の内訳と記号A〜Mでの管理

13項目のうち4つがインジェクション系（A・D・F・I）です。「インジェクション」が指すのは、利用者が送った文字列がSQL文・OSコマンド・メールヘッダ・HTTPヘッダのいずれかの構文として解釈されてしまう欠陥。混入先が違えば別項目として数えます。診断報告書が記号で管理されていれば、指摘が13項目のどれに当たるのかを発注側でも追跡できます。逆に、ベンダー独自の項目名だけで並ぶ報告書は、IPAの基準線に対する充足度を検証しづらくなります。

危険度と総合判定所見の判定基準

危険度の3段階は攻撃の型で切られています。「高」は被害者ユーザの関与がなくても攻撃者が直接攻撃可能な能動的な脆弱性で、大量の情報漏洩や改ざんを生じうるもの。「中」は攻撃成功に被害者の関与（罠のリンクのクリック等）が必要な受動的な脆弱性、または能動的でも大量の漏洩・改ざんにつながりにくいもの。「低」は成功確率が低いか被害が軽微なものです。

そのうえで、診断結果の総合判定所見は「要治療・精密検査」「差し支えない」「異常は検出されなかった」の3つしかありません。「差し支えない」となるのは(E)ディレクトリ・リスティング、(J)認証、(K)セッション管理の不備、(M)クローラへの耐性の4つだけが検出された場合に限られ、それ以外が1つでも出れば「要治療・精密検査」です。ただしこの4項目にはそれぞれ格上げ条件が付きます。(E)は個人情報の記載されたファイル等の重要な情報が検出された場合、(J)は検出パターン1かつ2または5、(K)は検出パターン2またはパターン4かつ5、(M)は⑥脆弱性の判定基準の条件1)〜4)に該当した場合で、いずれも「要治療・精密検査」へ上がります。同じ項目名でも中身次第で判定が動く、という点が報告書レビューの勘所。3つ目の「異常は検出されなかった」にも「診断していない項目もあり、診断方法も限定しているので、『安全である』ことと同義ではない」と釘が刺してあります。

13項目で担保できない範囲

IPAは活用上の注意として7点を挙げており、そのうち診断範囲に直結するのが「検査パターンを絞り込んだ診断であり、安全宣言には繋がりません」「できるだけ低いコストで診断が実施できるように、必要かつ最小限の診断項目、検査パターンを採用した診断です」という記述です。さらに「診断対象のウェブアプリケーションの全てのページを診断するものではなく、診断対象の規模にもよりますが、基本は抜き取り調査（診断）です」とも明記されています。13項目は下限であって上限ではありません。

実務上もう1つ落とせないのが、診断そのものの副作用です。同仕様は「健康診断を行うことにより、診断対象のウェブサイトが停止したり、ウェブサイトに意図しないデータが登録される可能性があります」とし、影響がインフラを共有する別のウェブサイトにも及びうるため「診断を行う際は必ず、サーバやデータセンター等、インフラ管理者の許可を事前に得てください」と求めています。クラウド事業者への事前申請が要る範囲は環境によって異なり、AWSの場合の切り分けはAWSの脆弱性診断｜事前申請が要る範囲とツール選定・費用の判断基準で整理しています。

OWASP Top 10:2025で入れ替わった優先順位

13項目の上に何を積むかを決めるとき、国際的な基準として使われるのがOWASP Top 10です。現行版はOWASP Top 10:2025（第8版）で、280万件を超えるアプリケーション分の提供データをもとに589件のCWEを分析し、10カテゴリに248件のCWEを割り当てています。1カテゴリあたりのCWEは上限40件に制限され、10カテゴリのうち8つはデータから、残る2つはコミュニティ調査から選ばれる方式です。2021年版のカテゴリ名で診断項目表を作っている場合、次の差分で更新が要ります。

OWASP Top 10 2021年版からの順位・名称の差分

順位の下降を「危険度が下がった」と読むのは誤りです。A05のInjectionについてOWASPは、最もテストされているカテゴリの1つで、38件のCWEに紐づくCVE件数は全カテゴリ中で最多だと明記しています。順位が動いたのは他カテゴリの検出が増えたためで、SQLインジェクションやXSSの対策を緩めてよい根拠にはなりません。

診断項目リストに足すべき論点

13項目にもWebアプリ診断の標準メニューにも含まれないのが、新設された2カテゴリです。A03のSoftware Supply Chain Failuresは5件のCWEを束ね、依存ライブラリだけでなくビルドシステムや配布インフラまで含む侵害を扱います。OWASPはこのカテゴリについて、提供データ中の出現件数は最も少ない一方、CVEから算出した平均の攻撃可能性スコアと影響スコアはいずれも最も高いとし、出現の少なさはテスト手法が追いついていないことに由来すると見ています。「診断で出なかった＝無い」と読めない領域であり、依存関係の棚卸しは診断とは別建てで持つ必要があります。

A10のMishandling of Exceptional Conditionsは24件のCWEを束ねたもので、不適切なエラー処理、ロジックの誤り、フェイルオープン（異常時に処理を通してしまう挙動）などを対象にします。異常系の挙動は正常系の仕様書に書かれないため、リクエストを機械的に投げるだけの診断では拾えません。発注時に「異常系・エラーハンドリングを診断範囲に含めるか」を明示的に確認する価値があります。より細かい要件レベルで診断範囲を定義したい場合は、OWASPが検証要件を体系化したASVS（Application Security Verification Standard、現行の安定版は5.0.0）を仕様書の共通言語として使う手もあります。

DAST・SAST・IAST・SCAの検出範囲の違い

ここまでが「何を診るか」で、次が「何で診るか」です。DAST・SAST・IAST・SCAはApplication Security Testing（AST）ツールの分類で、どれかが優れているという関係ではなく、見える場所が構造的に違います。

DASTが検出できる項目と苦手な項目

DAST（Dynamic Application Security Testing、動的アプリケーションセキュリティテスト）は、稼働中のアプリケーションに外部からHTTPリクエストを送り、応答の差分や遅延で脆弱性の有無を判定する方式。ソースコードが不要なので、他社製パッケージや改修対象外のシステムにも適用できます。IPAの検出パターンを見ると、この方式が何を根拠に判定しているかがはっきりします。

# (A) SQLインジェクションの検出パターン
# 1. シングルクォート1つを送り、DBMSのエラーメッセージが出るか
'
# 2. 文字列の検索キーに条件を足し、検索キーのみと同じ結果になるか
検索キー'and'a'='a
# 3. 数値の検索キーの場合のみ
検索キー and 1=1

# (D) OSコマンド・インジェクションの検出パターン（UNIX系OS向け・4パターン中の2番目）
;/bin/sleep 20

パターン2と3の「同じ結果」の判定は、HTTPステータスコードが一致し、かつレスポンスの差分が全体の6%未満であることと定義され、検査対象が検索機能の場合は検索結果件数が同一であっても同一の結果と判定されます。パターン1のDBMSエラーの判断基準も、製品名の全部または一部が出る、SQLの一部が出る、構文上の問題指摘が含まれる、通常は日本語のエラーが英語になっているなど異質である、の4つが挙がっています。OSコマンド・インジェクションに至っては20秒のsleepを注入して20秒レスポンスが遅くなるかを見る時間差判定。いずれも外形の観測だけで完結するため、DASTと相性が良い項目です。

苦手なのは、正常な業務仕様を知らないと正誤を判定できない項目です。(C)CSRFの検出は「ログイン状態において、特定副作用を持つ画面に対して外部からパラメータを強制する」形で行い、脆弱性ありの判定条件はトークン等のパラメータが存在しない、削除しても特定副作用が実行される、トークン文字列の推測が可能、別ユーザのトークンが使用できる、のいずれか。特定副作用とは送金・商品購入・退会処理・設定変更といった、取り消しできない重要な処理を指します。4条件のうち最初の1つは機械的に見つかり、OWASP ZAPにも受動スキャンのルール10202「Absence of Anti-CSRF Tokens」（CWE-352、リスクMedium）として実装済み。取りこぼすのは残りの3つで、どの画面が特定副作用に当たるかの判断と別ユーザ分のアカウント準備は、スキャナが自力で用意できません。(L)認可制御も同じく、「権限のない情報を閲覧できるか」は正しい権限設計を知らないと判定できません。ツール診断と手動診断の割当は脆弱性診断のやり方｜5工程の手順とトリアージ・再診断の判断基準で工程ごとに整理しています。

SASTとSCAが担う範囲

SAST（Static Application Security Testing、静的アプリケーションセキュリティテスト）はソースコードやバイトコードを解析し、入力値がどの処理まで伝播するかを追って欠陥箇所を指摘します。DASTが分かるのは「攻撃が通ったこと」だけ。対してSASTは行番号まで示せるので修正が速い反面、実行時にしか決まらない設定や到達しないコードにも指摘を出すため偽陽性が増えます。開発中のリポジトリに常時かける前提の道具であり、GitHubを使っているならGitHub Code Scanningとは？CodeQLの仕組み・設定方法・料金を解説で設定と料金の条件を確認できます。

SCA（Software Composition Analysis）は自作コードではなく、依存しているOSSライブラリとそのバージョンを棚卸しし、既知の脆弱性と突き合わせます。前述のA03が扱う領域を直接カバーするのがこの手法で、SASTともDASTとも守備範囲が重なりません。コンテナイメージまで含めた依存関係をCI/CDで継続的に見るなら、Dockerの脆弱性診断をCI/CDに組み込む手順とツール選定の構成が参考になります。

IASTの位置づけ

IAST（Interactive Application Security Testing）は、実行中のアプリケーションの内部にエージェントを常駐させ、外部からのリクエストが内部でどう処理されたかを観測する方式。DASTの「外から攻撃する」とSASTの「内部構造を知っている」を同時に満たすため、外形だけでは判定できない挙動を根拠付きで指摘できます。代償として、対応言語・フレームワークがエージェントの実装に縛られ、本番同等の実行環境を用意する必要があります。既存のテストコードやE2Eテストを流して初めて検出範囲が広がる仕組みなので、自動テストが整備されていない組織では投資に見合いません。導入判断は言語構成とテスト資産の有無で決まる、と割り切ってよい領域です。

IPA13項目と手法の対応

13項目それぞれを、IPAが定めた検出パターンの作り（何を送り、何を観測して判定するか）から手法に割り当てると、次の4群に分かれます。この割当はIPAが手法を指定しているわけではなく、検出パターンの性質から本記事で整理したものです。

3群目の4項目も、自動ツールで部分的には充足を示せます。(K)のCookieセキュア属性やセッションIDのURL埋め込み、(J)のパスワード最大文字数や10回失敗時のアカウントロックは、いずれもIPAの検出パターンとして外形から確認できる項目です。機械で埋まらないのは「別ユーザのトークンが使えるか」「権限のない情報を閲覧できるか」の側。見積書の項目一覧を(C)(J)(K)(L)で照合し、どこまでを自動判定で済ませる提案なのかを確認すると、価格差の理由が見えます。価格帯そのものの相場感は脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説にまとめています。

OWASP Benchmarkによるツール検出精度の数値化

ベンダー資料の検出率をそのまま比較しても、母集団も偽陽性の扱いも各社バラバラなので意味を持ちません。ここで使えるのがOWASP Benchmarkです。意図的に脆弱性を埋め込んだ実行可能なWebアプリケーションを配布し、SAST・DAST・IASTのいずれのツールでも同じ土俵でスコアを出せるようにしたプロジェクトで、検証は自社で実施できます。

Java版の最新リリースはv1.2で、テストケースは2,740件。v1.1の21,041件から絞られており、DASTツールがスキャンし切れない事態を避けるための調整だとプロジェクト側が説明しています。内訳はSQLインジェクション504件、Weak Randomness 493件、XSS 455件など11領域です。

このプロジェクトの実務的な価値は、テストケース数ではなく設計にあります。各テストケースは1つのHTTPサーブレットで、単一のCWEに対する真の脆弱性か偽陽性かのどちらか。全ケースの正解は expectedresults-VERSION#.csv としてリポジトリに同梱されています。検出できた数だけでなく、存在しない脆弱性を報告した数まで機械的に集計でき、真陽性率と偽陽性率を同じ軸に載せられる、というのがこの設計の効きどころ。実行用の runBenchmark.sh とスコアカード生成ツールも配布済みで、候補ツールを2つ3つ走らせて自社のスコアカードを作るところまで手元で完結します。

注意点を1つ。Java版v1.2は2016年6月に公開された版を保守しているサーブレットアプリケーションで、ここで高得点のツールが自社のPHPやGoのコードで同じ精度を出す保証はありません。Python版は初期のv0.1が公開された段階です。候補ツールの絶対的な優劣を決めるのではなく、「偽陽性をどれだけ出す製品か」を事前に把握して運用工数の見積もりに使う、という位置づけが現実的。診断で挙がった指摘の優先順位付けと自動化の限界は、脆弱性対応の自動化｜ASM・BAS・ASVの使い分けと限界で別途扱っています。

EC加盟店に求められる脆弱性対策と法的な位置づけ

「Webアプリケーション脆弱性診断は義務なのか」の答えは業種で変わります。ECサイトを運営してクレジットカード決済を扱う事業者については、実質的に求められる段階に入りました。クレジット取引セキュリティ対策協議会（事務局は一般社団法人日本クレジット協会）が公表する「クレジットカード・セキュリティガイドライン」は、2026年3月に【6.1版】へ改訂されています。EC加盟店への「脆弱性対策」が指針対策になったのは【6.0版】からで、適用開始は2025年4月。現行の【6.1版】にも引き継がれています。対象は割賦販売法第35条の16第1項第2号に定める2号事業者（＝加盟店）のうちEC加盟店で、カード情報保護対策としてシステムおよびWebサイトの「脆弱性対策」を講じることが求められます。位置づけは、割賦販売法が義務付けている漏えい等の事故を防止するための措置について、その指針対策の1つ。法律が直接「脆弱性診断」を条文で命じているわけではない、という区別は押さえてください。

求められる脆弱性対策は5項目で、ガイドラインは「下記のすべての対策を講じる」と規定しています。

• システム管理画面のアクセス制限と管理者のID／パスワード管理（IPアドレス制限、2段階認証または多要素認証、10回以下のログイン失敗でのアカウントロック）
• データディレクトリの露見に伴う設定不備への対策（公開ディレクトリに重要ファイルを置かない、アップロード可能な拡張子の制限）
• Webアプリケーションの脆弱性対策（脆弱性診断またはペネトレーションテストの定期実施と修正対応、プラグインとソフトウェアの更新、セキュアコーディングの確認とソースコードレビュー）
• マルウェア対策としてのウイルス対策ソフトの導入と運用
• 悪質な有効性確認、クレジットマスターへの対策

3番目が本記事の主題に直結します。原文は「脆弱性診断又はペネトレーションテストを定期的に実施し、必要な修正対応を行う。」で、実施だけでなく修正対応まで含めて1つの対策。診断報告書を受け取って終わりでは要件を満たしません。なお1番目のアカウントロック回数には「10回以下(PCI DSS ver4.0.1基準)」と根拠が併記され、PCI DSSの基準値をそのまま採用した箇所だと分かります。脆弱性診断とペネトレーションテストのどちらを選ぶかは、目的も費用も異なるためペネトレーションテストと脆弱性診断の違い｜目的・費用・使い分けを発注前に整理で判断材料を確認してください。

内製化と外注の切り分け

内製化は、13項目のうちどこまでを自社で持つかという分割で考えると判断しやすくなります。外形観測で判定できる9項目（A・B・D・E・F・G・H・I・M）は内製化の対象にできますが、(C)(J)(K)(L)を自社だけで担保しようとするのは勧めません。

前半9項目が内製に向く理由は、判定基準が公開されている点にあります。IPAの仕様には送信する検査文字列と、脆弱性ありと判定する条件が項目ごとに書かれており、レスポンス差分6%未満や20秒の遅延といった閾値まで明示されたもの。OSSのDASTツールを使えば、リリース前の定型チェックとして回すところまでは十分に手が届きます。導入の実際はOWASP ZAPの診断項目とは？検出できる脆弱性一覧と使い方、リクエストを手で組み立てて確認する工程はBurp Suiteとは？通信傍受の仕組みとエディションの選び方・初期設定が参考になります。

一方で後半4項目は、判定に「その機能の正しい振る舞い」の定義が要ります。認可制御の不備を自社で検証しようとしても、開発したチーム自身が「この画面は誰が見てよいか」の前提を共有しているため、前提そのものの誤りに気づけません。ここが外部診断に金を払う理由で、内製ツールをどれだけ揃えても代替されない部分。併用するなら、日次・リリース毎の自動チェックは内製、年1回または大規模改修時の(C)(J)(K)(L)を含む精査は外注、という頻度による分割が現実的な運用ルールです。

よくある質問

Webアプリケーションの脆弱性診断は法律で義務化されていますか？

すべての事業者を対象に脆弱性診断そのものを命じる法律はありません。ただしクレジットカード決済を扱うEC加盟店については、割賦販売法が求める漏えい防止措置の指針対策として、クレジットカード・セキュリティガイドラインが「脆弱性対策」5項目の実施を求めています。【6.0版】で導入されて2025年4月から適用され、現行の【6.1版】にも引き継がれた要件で、その中に脆弱性診断またはペネトレーションテストの定期実施と修正対応が含まれます。業界基準や取引先の要求で実質的に必須となるケースが多いため、自社の適用範囲を先に確認してください。

API診断とWebアプリケーション診断の違いは何ですか？

診断対象と、想定するリスクの並びが違います。OWASPはWebアプリケーション向けのTop 10とは別に、API Security Top 10を公開しており、2023年版の1位はBroken Object Level Authorization（オブジェクト単位の認可の不備）です。3位のBroken Object Property Level Authorization（プロパティ単位の認可の不備）、9位のImproper Inventory Management（棚卸しの不備）、10位のUnsafe Consumption of APIs（外部APIから受け取ったデータの検証不足）も、画面を持つWebアプリの診断項目には現れにくい論点。画面経由の診断だけでAPIエンドポイントを範囲外にすると、認可周りが丸ごと未検証で残ります。

SASTとDASTはどちらを先に導入すべきですか？

自社でコードを書いているならSASTを先に入れるほうが投資対効果が高くなります。SASTは行番号まで指摘するため修正コストが低く、リポジトリに常時かけられるので開発の途中で潰せるためです。ただしSASTだけでは、設定不備や運用起因の欠陥、他社製パッケージの問題を検出できません。自社開発のコードがほとんど無く、パッケージやSaaSの組み合わせで構築しているならDASTを先に選びます。

IASTはDASTやSASTと何が違うのですか？

観測する場所が違います。DASTが見るのは外部から送ったリクエストへの応答だけ、SASTが見るのはコードだけ。IASTは実行中のアプリケーション内部にエージェントを置き、リクエストが内部でどう処理されたかを観測します。そのため外形からは判定できない処理の中身を根拠として指摘できる反面、対応言語がエージェントの実装に制限され、本番同等の実行環境と、機能を一通り動かすテストが必要になります。テスト資産が無い状態で導入しても検出範囲は広がりません。

WAFを導入していれば脆弱性診断は不要ですか？

役割が別なので置き換えにはなりません。診断は欠陥そのものを特定して修正するための工程、WAFは攻撃リクエストを遮断する緩和策です。クレジットカード・セキュリティガイドライン【6.1版】がEC加盟店に求める脆弱性対策5項目のうち、Webアプリケーションの脆弱性対策として挙がっているのは、診断またはペネトレーションテストの定期実施と修正対応、プラグインとソフトウェアの更新、セキュアコーディングの確認とソースコードレビューの3つです。同ガイドライン本文の5項目には、WAFの導入をこれらの代替として認める記述はありません。WAFは修正が完了するまでの時間を稼ぐ手段と位置づけると、投資判断がぶれません。

関連記事

• 脆弱性診断のやり方｜5工程の手順とトリアージ・再診断の判断基準
• 脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説
• ペネトレーションテストと脆弱性診断の違い｜目的・費用・使い分けを発注前に整理
• OWASP ZAPの診断項目とは？検出できる脆弱性一覧と使い方
• GitHub Code Scanningとは？CodeQLの仕組み・設定方法・料金を解説