---
title: "Webアプリケーション脆弱性診断の項目｜IPA13項目とDAST・SAST・IASTの使い分け"
url: "https://www.issoh.co.jp/column/details/2485/"
published: 2024-06-12
updated: 2026-10-26
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

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

Webアプリケーション脆弱性診断の見積書は、診断項目の数も粒度もベンダーごとに揃っていません。項目数の多さは品質の証明になりません。判断の起点になるのは、IPAが公開している「ウェブ健康診断仕様」の13項目という公的な基準線と、そのどれを自動ツールが判定でき、どれが人手を要するのかという線引きです。この記事では13項目とOWASP Top 10:2025を一次資料で確定させたうえで、DAST・SAST・IAST・SCAの守備範囲、WAFやログ解析といった「攻撃を検知する仕組み」との違い、診断結果の管理方法、外注先の絞り込み方までを順に整理します。

## まとめ

- 診断項目の公的な基準線はIPA別冊「ウェブ健康診断仕様」の13項目（記号A〜M）。ベンダー提案はまずこの13項目の充足で足切りできる。
- 13項目は「必要かつ最小限」の抜き取り調査で、IPA自身が「安全宣言には繋がりません」と明記している。上乗せの基準はOWASP Top 10:2025で、新設のA03（サプライチェーン）とA10（例外条件）は13項目に無い。
- DASTは応答差分や遅延で判定するためインジェクション系に強い。CSRF・認証・セッション管理・認可制御の4項目は業務仕様を知らないと判定しきれず、手動診断が残る。
- WAF・RASP・IPAのiLogScannerは攻撃を検知する側の仕組みで、欠陥そのものは残り、診断の代わりにはならない。WAF・RASPの遮断は修正までの緩和策、iLogScannerのログ解析は攻撃痕跡の事後確認と位置づける。
- 診断結果はCVSS v4.0の「どのメトリクスで算出した値か」を確認し、SAST・DAST・SCAの指摘はSARIF形式で1か所に集めて再診断まで追跡する。
- ECサイトなら、クレジットカード・セキュリティガイドラインの脆弱性対策に「脆弱性診断又はペネトレーションテストを定期的に実施し、必要な修正対応を行う」が含まれる。
- 外注先は、経済産業省「情報セキュリティサービス基準」に適合したサービスを載せたIPAのリストで候補を絞り、そのうえで13項目の手動範囲を見積書で照合する。

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

「Webアプリケーション脆弱性診断で何を見ればよいか」に対する日本語圏の一次回答は、IPA「[安全なウェブサイトの作り方](https://www.ipa.go.jp/security/vuln/websecurity/about.html)」の別冊として配布されている「ウェブ健康診断仕様」（全30ページ・2012年12月26日公開）です。本編の現行版は改訂第7版第4刷（2021年3月31日）です。別冊は診断で確認すべき項目を絞り込み、検出パターンと判定基準まで書き下したもので、仕様自身が「一般にウェブアプリケーションの脆弱性診断サービスとして提供されているものよりも簡素です」と述べるとおり、外せない基礎の集合として読むものです。

対象はアプリケーションが受け取る入力と返す出力です。OS・ミドルウェア・公開ポートを広く調べるプラットフォーム診断は、Webアプリ診断とは主な対象レイヤーが異なります。ただし、Web経由で確認できる既知の脆弱性など、検査範囲が重なる場合もあります。両方の見積もりを1枚で受け取ると範囲が混ざるため、発注時に切り分けてください。

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

| 記号  | 診断項目（脆弱性名）                   | 危険度 | 攻撃の型    |
| --- | ---------------------------- | --- | ------- |
| (A) | SQLインジェクション                  | 高   | 能動的     |
| (B) | クロスサイト・スクリプティング              | 中   | 受動的     |
| (C) | CSRF                         | 中   | 受動的     |
| (D) | OSコマンド・インジェクション              | 高   | 能動的     |
| (E) | ディレクトリ・リスティング                | 低〜高 | 能動的     |
| (F) | メールヘッダ・インジェクション              | 中   | 能動的     |
| (G) | パス名パラメータの未チェック／ディレクトリ・トラバーサル | 高   | 能動的     |
| (H) | 意図しないリダイレクト                  | 中   | 受動的     |
| (I) | HTTPヘッダ・インジェクション             | 中   | 受動的     |
| (J) | 認証                           | 低〜中 | 能動的     |
| (K) | セッション管理の不備                   | 低〜高 | 能動的／受動的 |
| (L) | 認可制御の不備、欠落                   | 高   | 能動的     |
| (M) | クローラへの耐性                     | 低〜中 | 能動的     |

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

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

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

総合判定所見は「要治療・精密検査」「差し支えない」「異常は検出されなかった」の3つだけです。「差し支えない」になるのは(E)(J)(K)(M)の4つだけが検出された場合に限られ、それ以外が1つでも出れば「要治療・精密検査」。ただし4項目にはそれぞれ格上げ条件があり、(E)は個人情報の記載されたファイル等の重要な情報が検出された場合、(J)は「検出パターン1と2の両方」または「5」、(K)は「検出パターン2」または「4と5の両方」、(M)は判定基準の条件1)〜4)に該当した場合に「要治療・精密検査」へ上がります。同じ項目名でも中身次第で判定が動く点が、報告書レビューの勘所です。「異常は検出されなかった」にも「診断していない項目もあり、診断方法も限定しているので、『安全である』ことと同義ではない」と注記されています。

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

IPAは活用上の注意として7点を挙げ、そのうち範囲に直結するのが「検査パターンを絞り込んだ診断であり、安全宣言には繋がりません」「必要かつ最小限の診断項目、検査パターンを採用した診断です」という記述です。さらに「基本は抜き取り調査（診断）です」とも明記されています。13項目は下限であって上限ではありません。

診断には副作用もあります。同仕様はサイトの停止や意図しないデータ登録の可能性を挙げ、「診断を行う際は必ず、サーバやデータセンター等、インフラ管理者の許可を事前に得てください」と求めています。クラウド事業者への事前申請が要る範囲は環境ごとに違い、AWSの場合は[AWSの脆弱性診断｜事前申請が要る範囲とツール選定・費用の判断基準](/column/details/2713/)で切り分けています。

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

13項目の上に何を積むかを決める国際的な基準がOWASP Top 10です。現行版は[OWASP Top 10:2025](https://owasp.org/Top10/2025/0x00%5F2025-Introduction/)（第8版）で、280万件を超えるアプリケーション分のデータから589件のCWEを分析し、10カテゴリに248件のCWEを割り当てています。1カテゴリのCWEは上限40件、10カテゴリのうち8つはデータから、2つはコミュニティ調査から選ぶ方式です。2021年版のカテゴリ名で診断項目表を作っているなら、次の差分で更新が要ります。

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

| 2025年版 | カテゴリ                                  | 2021年版からの変化                      |
| ------ | ------------------------------------- | -------------------------------- |
| A01    | Broken Access Control                 | 1位を維持。SSRFを統合                    |
| A02    | Security Misconfiguration             | 5位から2位へ上昇                        |
| A03    | Software Supply Chain Failures        | 新設（A06:2021の範囲を拡張）               |
| A04    | Cryptographic Failures                | 2位から4位へ下降                        |
| A05    | Injection                             | 3位から5位へ下降                        |
| A06    | Insecure Design                       | 4位から6位へ下降                        |
| A07    | Authentication Failures               | 7位を維持。名称から Identification を削除    |
| A08    | Software or Data Integrity Failures   | 8位を維持                            |
| A09    | Security Logging & Alerting Failures  | 9位を維持。Monitoring から Alerting へ改称 |
| A10    | Mishandling of Exceptional Conditions | 新設（24件のCWE）                      |

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

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

新設の2カテゴリは、IPAの13項目だけでは十分に扱えません。既存の診断にも関連する検査が含まれるため、カテゴリ名の有無だけでなく、具体的な検査範囲を確認します。A03のSoftware Supply Chain Failuresは5件のCWEを束ね、依存ライブラリだけでなくビルドシステムや配布インフラまで含む侵害を扱います。OWASPは、提供データ中の出現件数は最も少ない一方、CVEから算出した平均の攻撃可能性スコアと影響スコアはいずれも最も高いとし、出現の少なさはテスト手法が追いついていないことに由来すると見ています。「診断で出なかった＝無い」と読めない領域なので、依存関係の棚卸しは診断とは別建てで持ちます。

A10のMishandling of Exceptional Conditionsは24件のCWEで、不適切なエラー処理、ロジックの誤り、フェイルオープン（異常時に処理を通してしまう挙動）などが対象です。異常系の問題には、不正な入力への応答やエラーメッセージから自動検出できるものもあります。ただし、業務上正しい失敗時の挙動やフェイルオープンの有無は、仕様確認と個別の検証が必要です。発注時に「異常系・エラーハンドリングを範囲に含めるか」を明示的に確認してください。要件レベルで範囲を定義したいなら、OWASPの検証要件集[ASVS](https://asvs.owasp.org/)（安定版5.0.0・2025年5月30日公開）を仕様書の共通言語に使えます。

## DAST・SAST・IAST・SCAの守備範囲の違い

DAST・SAST・IAST・SCAは優劣ではなく見える場所が構造的に違います。各手法の仕組みとCI/CDへの組み込みは個別記事に譲り、ここでは13項目との対応に絞ります。

### DASTが判定できる項目と取りこぼす項目

DAST（動的アプリケーションセキュリティテスト）は、稼働中のアプリケーションに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%未満であることと定義され、検索機能なら検索結果件数が同一でも同一と判定されます。OSコマンド・インジェクションは20秒のsleepを注入して応答が20秒遅れるかを見る時間差判定。どちらも外形の観測を使うため、DASTに組み込みやすい検査です。ただし、掲載した文字列と判定閾値はIPAの簡易診断の目安であり、この反応だけで脆弱性の存在を確定するものではありません。

取りこぼすのは、正常な業務仕様を知らないと正誤を決められない項目です。(C)CSRFの「脆弱性あり」の条件は、トークン等のパラメータが存在しない、削除しても特定副作用（送金・購入・退会・設定変更など取り消せない処理）が実行される、トークンが推測できる、別ユーザのトークンが使える、のいずれか。最初の1つは機械的に見つかり、ZAPにも受動スキャンのルール10202「Absence of Anti-CSRF Tokens」（CWE-352）として実装済みです。残りの3つは、どの画面が特定副作用に当たるかの判断と、別ユーザ分のアカウント準備をスキャナが自力で用意できません。(L)認可制御の「権限のない情報を閲覧できるか」も、正しい権限設計を知らないと判定できません。ZAPでの組み込み方は[DASTとは？SASTとの違い・ZAPでのCI/CD組み込みと導入判断を実装視点で解説](/tech/details/15882/)で扱っています。

### SAST・SCA・IASTが受け持つ範囲

SAST（静的アプリケーションセキュリティテスト）はソースコードを解析し、入力値がどの処理まで伝播するかを追って欠陥の候補箇所を行番号で示します。HTTP通信から兆候を拾うDASTと違ってコード上の位置まで示せるので原因調査を助ける一方、実行時にしか決まらない設定や到達しないコードにも指摘を出すため偽陽性が増えます（[SASTとは？DAST・SCAとの違いとCI/CDへの組み込み・導入判断を実装視点で解説](/tech/details/15880/)）。

SCAは自作コードではなく依存OSSとそのバージョンを棚卸しし、既知の脆弱性と突き合わせる手法で、前述のA03のうち依存コンポーネントに関するリスクの一部を扱います（[SCAとは？ソフトウェア構成分析の仕組みとSAST・SBOMとの違い・導入判断を解説](/tech/details/16216/)）。IASTは実行中のアプリケーション内部にエージェントを置き、外部からのリクエストが内部でどう処理されたかを観測します。外形では判定できない挙動を根拠付きで指摘できる代わりに、対応言語がエージェントの実装に縛られ、検出範囲は実際に実行した処理に依存します。手動操作でも範囲を広げられますが、自動・手動を問わず主要な業務経路を継続して実行できない場合は、導入を見送る判断が妥当です（[IASTとは？SAST・DASTとの違いと実行時検査の実装・導入判断を実装視点で解説](/tech/details/16210/)）。

### IPA13項目と手法の対応

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

| 群               | 該当項目                  | 主に担う手法     |
| --------------- | --------------------- | ---------- |
| 送信文字列と応答差分で判定   | (A)(B)(D)(F)(G)(H)(I) | DAST／SAST  |
| 公開設定・可用性の外形確認   | (E)(M)                | DAST       |
| 業務仕様と複数アカウントが要る | (C)(J)(K)(L)          | 手動診断／IAST  |
| 13項目の外側         | A03・A10相当             | SCA／設計レビュー |

3群目の4項目も、部分的には自動で充足を示せます。(K)のCookieセキュア属性やセッションIDのURL埋め込み、(J)のパスワード最大文字数や10回失敗時のアカウントロックは、IPAの検出パターンとして外形から確認できる項目です。人が定義すべきなのは、アカウントごとの正しい権限と期待結果です。それらを設定すれば、権限のない情報へのアクセスなどを自動検査できる場合もあります。見積書の項目一覧を(C)(J)(K)(L)で照合し、どこまでを自動判定で済ませる提案なのかを確かめると、価格差の理由が見えます。

## 診断と攻撃検知システム（WAF・RASP・ログ解析）の役割分担

「Webアプリの脆弱性を検知するシステム」を探すと、性質の違う2系統が混ざって出てきます。1つは欠陥そのものを事前に見つける診断（DAST・SAST等）、もう1つは稼働中のアプリケーションに来た攻撃を検知・遮断する仕組みです。後者は欠陥を直さないので、どちらを買っても他方は埋まりません。

| 仕組み                | 働くタイミング  | 見ているもの       | 欠陥は直るか       |
| ------------------ | -------- | ------------ | ------------ |
| 脆弱性診断（DAST・SAST等）  | リリース前・定期 | アプリの欠陥       | 修正すれば直る      |
| WAF                | 攻撃の受信時   | HTTPリクエストの内容 | 直らない（遮断のみ）   |
| RASP               | 攻撃の処理中   | アプリ内部の実行     | 直らない（実行を止める） |
| IDS・IPS            | 通信の通過時   | ネットワークの通信    | 直らない         |
| ログ解析（iLogScanner等） | 攻撃の後     | アクセスログの痕跡    | 直らない（気づくだけ）  |

WAFはリクエストの文字列パターンで判定するため、正規のリクエストと見分けがつかない(L)認可制御の不備（他人のIDに書き換えた閲覧など）は素通りしやすい種類の攻撃です。アプリの内部で危険な処理の実行を止めるRASPは、[RASP（実行時アプリケーション自己保護）とは？WAFとの違いと導入判断を実装視点で解説](/tech/details/16230/)でWAFとの差を扱っています。ネットワーク層の検知は[IDS・IPSとは？違い・仕組み・種類とファイアウォール/WAFとの使い分けを解説](/column/details/13258/)が対象です。

WAF・RASPによる遮断は修正までの緩和策となり、ログ解析は攻撃痕跡の確認と対応判断に使います。いずれも脆弱性を修正するものではなく、診断の代わりにはなりません。後述するクレジットカード・セキュリティガイドラインも、Webアプリケーションの脆弱性対策として診断またはペネトレーションテストの定期実施と修正対応、プラグインとソフトウェアの更新、ソースコードレビューを挙げており、脆弱性対策の5項目の本文にWAFで代替できるとする記述はありません。

### IPAの無償ツール：iLogScannerの攻撃兆候検出とAppGoatの学習用途

IPAが公開する攻撃兆候検出ツールの1つが[iLogScanner](https://www.ipa.go.jp/security/vuln/ilogscanner/operation.html)です。ただしこれはウェブサーバのアクセスログから攻撃と思われる痕跡を検出するツールで、サイトに検査リクエストを送る診断ツールではありません。ログの痕跡のうち一部は攻撃が成功した可能性まで確認でき、SSHやFTPサーバのログも解析できます。現在の配布はオフライン版（ZIP・3.7MB）だけで、オンライン版は2019年1月16日に公開を終えています。使い方は[iLogScannerとは？IPA無料ツールで攻撃兆候を検出する使い方](/tech/details/5167/)にまとめています。

IPAが提供するもう1つの無償ツール[AppGoat](https://www.ipa.go.jp/security/vuln/appgoat/about.html)は、脆弱性を埋め込んだ演習環境で発見と修正を体験する学習ツールです（現行は3系・Windows 11対応のウェブアプリケーション用学習ツール）。自社サイトを検査する用途には使えず、診断担当者の育成に向きます（[AppGoatとは？IPA提供の無償脆弱性体験学習ツールの使い方・学べる脆弱性](/tech/details/5144/)）。つまりIPAから得られるのは、診断の基準（ウェブ健康診断仕様）、攻撃後の痕跡確認、人材育成の3つで、検査そのものはZAPなどのDASTツールか外部診断で行うことになります。

## 診断結果を管理するアプリケーション脆弱性管理

診断の成果物は報告書ですが、報告書を受け取った時点では何も直っていません。指摘を優先順位づけし、修正し、直ったことを確かめるまでを追跡する仕組みがアプリケーション脆弱性管理です。ここで差が出るのは、スコアの読み方と、複数ツールの結果を1か所に集める形式の2点です。

### CVSS v4.0のスコア表記と算出メトリクス

深刻度の共通尺度である[CVSS v4.0](https://www.first.org/cvss/v4-0/specification-document)（2023年11月1日公開）は、Base・Threat・Environmental・Supplementalの4つのメトリクスグループで構成されます。仕様は数値を示すときに、どのグループを使った値かを命名で区別するよう求めています。

| 表記       | 算出に使ったメトリクス               |
| -------- | ------------------------- |
| CVSS-B   | Base                      |
| CVSS-BT  | Base＋Threat               |
| CVSS-BE  | Base＋Environmental        |
| CVSS-BTE | Base＋Threat＋Environmental |

実務で効くのは、仕様の「ThreatとEnvironmentalの適用はCVSSの利用者の責任」という一文です。仕様自身が、製品の開発元やNVDのような評価提供者は通常Baseだけで算出したCVSS-Bを示すと書いています。インターネットに公開している画面か社内限定か、扱うデータの重要度はどうかといった自社の環境を反映しない値なので、報告書の数字順にそのまま修正すると、社内限定の管理画面の指摘に公開フォームより先に工数を割くといった逆転が起きます。報告書を受け取ったら、Environmental（自社環境）に加えてThreat（悪用状況）も評価し、業務への影響や修正の実行可能性を踏まえて優先順位を決めます。なお[NVD](https://www.nist.gov/itl/nvd/nvd-news)はv4.0のデータがある脆弱性について、詳細ページにv4.0の指標を表示しています。

### SAST・DAST・SCAの指摘の集約とSARIF対応

手法を複数使うと、指摘がツールごとの形式で散らばります。共通形式として使えるのがSARIF（Static Analysis Results Interchange Format）で、バージョン2.1.0が2020年3月27日にOASIS標準として承認されています。GitHubのcode scanningは[有効なSARIF 2.1.0ファイルのアップロードを受け付け](https://docs.github.com/en/code-security/reference/code-scanning/sarif-files/sarif-support)（使われるのは対応するプロパティのみ）、DASTのZAPもレポートテンプレートに[sarif-json](https://www.zaproxy.org/docs/desktop/addons/report-generation/templates/)を持っています。CodeQLの結果と並べて管理する設定は[GitHub Code Scanningとは？CodeQLの設定手順・対応言語・料金とAI Scan【2026年10月】](/tech/details/5210/)を参照してください。

外部診断の報告書やSCAの結果まで含めて一元管理するなら、OSSのDefectDojo（BSD 3-Clause License、2026年10月22日公開の3.4.202が最新）が、READMEで自らを「DevSecOps, ASPM (application security posture management), and vulnerability management tool」と位置づけています。ツールを選ぶ前に決めておくべきなのは、同じ欠陥を別ツールが別名で報告したときに1件として扱う規則と、修正後の再診断で「同じ検出パターンで再現しないこと」を確認した記録をどこに残すかです。この2つが無いと、件数だけが積み上がって完了の判定ができません。修正・検証のどこまでを自動化できるかは[脆弱性対応の自動化｜情報収集・優先順位付け・修正・検証で任せる範囲と人が残す判断](/column/details/2372/)で扱っています。

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

ベンダー資料の検出率は母集団も偽陽性の扱いも各社バラバラで、並べても比較になりません。自社で測る手段が[OWASP Benchmark](https://owasp.org/www-project-benchmark/)です。意図的に脆弱性を埋め込んだ実行可能なWebアプリケーションを配布し、SAST・DAST・IASTのどのツールでも同じ土俵でスコアを出せるようにしたプロジェクトです。

Java版の現行版はv1.2で、テストケースは2,740件（v1.1の21,041件から、DASTツールがスキャンし切れない事態を避けるために削減）。各ケースは単一のCWEに対する真の脆弱性か偽陽性のどちらかで、正解が expectedresults-VERSION#.csv として同梱されているため、真陽性率と偽陽性率を同じ軸に載せられます。ただしJavaのサーブレットで高得点のツールが自社のPHPやGoで同じ精度を出す保証はありません。優劣を決めるより、「偽陽性をどれだけ出す製品か」を把握して、前章のトリアージに要る工数の見積もりに使うのが現実的です。

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

「Webアプリケーション脆弱性診断は義務なのか」の答えは業種で変わります。クレジットカード決済を扱うECサイトは、実質的に求められる段階に入りました。クレジット取引セキュリティ対策協議会（事務局は一般社団法人日本クレジット協会）が公表する「[クレジットカード・セキュリティガイドライン](https://www.j-credit.or.jp/security/document/index.html)」は2026年3月に【6.1版】へ改訂されています。EC加盟店への「脆弱性対策」が指針対策になったのは【6.0版】からで、適用開始は2025年4月。現行の【6.1版】にも引き継がれています。位置づけは、割賦販売法（第35条の16第1項第2号の加盟店）が義務付ける漏えい防止措置の指針対策の1つで、法律の条文が「脆弱性診断」を直接命じているわけではありません。

求められる脆弱性対策は5項目で、ガイドラインは「下記のすべての対策を講じる」と規定しています。(1)管理画面のアクセス制限と管理者のID／パスワード管理（IPアドレス制限、2段階認証または多要素認証、10回以下のログイン失敗でのロック）、(2)データディレクトリの露見に伴う設定不備への対策、(3)Webアプリケーションの脆弱性対策（診断またはペネトレーションテストの定期実施と修正対応、プラグインとソフトウェアの更新、ソースコードレビュー）、(4)ウイルス対策ソフトの導入と運用、(5)悪質な有効性確認・クレジットマスターへの対策です。

3番目の原文は「脆弱性診断又はペネトレーションテストを定期的に実施し、必要な修正対応を行う。」で、修正対応まで含めて1つの対策です。1番目のロック回数には「10回以下(PCI DSS ver4.0.1基準)」と根拠が併記されており、PCI DSS本体は[PCI DSSとは？12要件と準拠レベル・v4.0.1移行を発注視点で整理【2026年時点】](/column/details/13185/)で整理しています。診断とペネトレーションテストのどちらを選ぶかは、[ペネトレーションテストと脆弱性診断の違い｜目的・費用・使い分けを発注前に整理](/column/details/13440/)で判断材料を確認してください。

## 内製化と外注の切り分け

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

### 内製に向く9項目と外注に残す4項目

ここで内製候補とした9項目は、検査文字列と判定の閾値（応答差分6%未満、20秒の遅延など）がIPAの仕様で公開されており、OSSのDASTツールでリリース前の定型チェックとして回せます。ZAPは2025年12月15日公開の2.17.0が現行の安定版で、導入は[OWASP ZAPの診断項目とは？検出できる脆弱性一覧とOWASP Top 10 2025対応・使い方](/tech/details/2958/)、リクエストを手で組み立てて確かめる工程は[Burp Suiteとは？通信傍受の仕組みとエディションの選び方・初期設定](/tech/details/9699/)が参考になります。

後半4項目は、判定に「その機能の正しい振る舞い」の定義が要ります。認可制御の検証を実装担当者だけで完結させると、権限設計の思い込みを見落とすおそれがあります。独立したレビュー担当者を社内で確保できない場合は、外部診断を組み合わせてください。運用としては、リリースごとの自動チェックは内製、年1回または大規模改修時の(C)(J)(K)(L)を含む精査は外注、という頻度による分割が現実的です。費用相場と発注の進め方は[脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説](/column/details/13101/)にまとめています。

### 外注先の絞り込みに使える情報セキュリティサービス基準

外注先の候補を絞る公的な手がかりが、経済産業省の「[情報セキュリティサービス基準](https://www.meti.go.jp/policy/netsecurity/shinsatouroku/touroku.html)」です。現行は第4.1版（令和7年3月31日公表、4月1日施行）で、脆弱性診断サービスをWebアプリケーション脆弱性診断・プラットフォーム脆弱性診断・スマートフォン／タブレット端末アプリケーション脆弱性診断の3つと定義しています。審査基準は大きく2系統です。

- 技術要件：所定の資格、専門家コミュニティでの講師経験、過去3年間に合計5件以上の診断実績、所定の研修修了のいずれかを満たす者を技術責任者に置くこと。あわせて、定められた基準に沿ってサービスを行い、診断結果の取扱いを明らかにすること
- 品質管理要件：品質管理の担当者を割り当て、サービス提供プロセスとアウトプットの管理を含む品質管理マニュアルを整備すること

この基準に適合すると審査登録機関に認められたサービスは、IPAの「[情報セキュリティサービス基準適合サービスリスト](https://www.ipa.go.jp/security/service%5Flist.html)」に載ります（最終更新2026年10月9日）。掲載期間は登録有効期間か2年間の短い方で、ペネトレーションテストは脆弱性診断サービスのオプションとして★印で区別されています。ただしIPAは掲載をいかなる保証とも位置づけておらず、適合の審査・判定にも関与していません。リストは「最低限の体制を持つ事業者」の足切りに使い、最終判断は前節の(C)(J)(K)(L)を手動で診る範囲と、報告書がIPAの記号で追跡できるかの照合で行ってください。Webアプリの診断を開発会社の視点でまとめて相談したい場合は、[脆弱性診断・セキュリティ診断](/service/system/vulnerability/)の支援内容を参照できます。

## よくある質問

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

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

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

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

### 無料で使えるWeb脆弱性診断ツールはありますか？

代表はZAP（旧称OWASP ZAP）です。2023年9月にOWASPを離れた独立のOSSプロジェクトで、ライセンスはApache License 2.0、現在は「ZAP by Checkmarx」とも呼ばれます。現行の安定版は2025年12月15日公開の2.17.0で、2024年9月24日にはプロジェクトリーダー3人がCheckmarxの従業員として参加すると発表されました。無料ツールで判定できるのは主に13項目のうち外形観測で済む9項目で、(C)(J)(K)(L)の手動部分は残ります。また他人のサイトや、インフラ管理者の許可を得ていない環境に向けて実行してはいけません。

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

自社でコードを書いているならSASTが先です。行番号まで指摘するため修正コストが低く、リポジトリに常時かけて開発の途中で潰せます。ただしSASTでは、解析対象に含まれない実行環境の設定や運用状態、ソースコードを取得できない他社製パッケージの内部までは確認できません。自社開発のコードがほとんど無く、パッケージやSaaSの組み合わせで構築しているならDASTを先に選びます。

### 脆弱性診断はどのタイミングで実施すべきですか？

リリース前、大規模改修の後、そして定期の3つです。リリース前と改修後は変更箇所に(C)(J)(K)(L)を含めて手動で診るのが基本です。定期の頻度は改修サイクルに合わせて自社で決め、年1回などと規程に書いておくと監査や取引先への説明がぶれません。クレジットカード・セキュリティガイドラインも診断の「定期的」な実施を求めています。日々の変更はSASTとDASTの自動チェックをCI/CDで回して拾い、外部診断の間を埋めます。

## 関連記事

- [脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説](/column/details/13101/)
- [ペネトレーションテストと脆弱性診断の違い｜目的・費用・使い分けを発注前に整理](/column/details/13440/)
- [DASTとは？SASTとの違い・ZAPでのCI/CD組み込みと導入判断を実装視点で解説](/tech/details/15882/)
- [OWASP ZAPの診断項目とは？検出できる脆弱性一覧とOWASP Top 10 2025対応・使い方](/tech/details/2958/)
- [iLogScannerとは？IPA無料ツールで攻撃兆候を検出する使い方](/tech/details/5167/)

---

出典: [Webアプリケーション脆弱性診断の項目｜IPA13項目とDAST・SAST・IASTの使い分け](<https://www.issoh.co.jp/column/details/2485/>)（株式会社一創）