脆弱性診断のやり方を調べると、「ツール診断と手動診断があり、準備・実施・報告の流れで進む」という説明にはすぐ行き当たります。ところが実際に着手すると、詰まるのはその先です。スキャナが数百件の指摘を返してきたとき、どれから直すのか。直したあと、どこまで再診断すれば完了と言えるのか。この記事では、計画からトリアージ、再診断の合格判定までを5工程に分け、各工程で何を根拠に決めるのかを一次情報つきで整理します。
まとめ：脆弱性診断のやり方は5工程、成否は検出後のトリアージで決まる
- 工程1・計画とスコープ定義：診断対象のホスト・URL・API・認証状態を先に確定する。クラウド上の環境は事業者のテストポリシー確認を計画に含める
- 工程2・ツールと手動の割り当て：既知パターンの網羅はツール、権限昇格やビジネスロジックの欠陥は手動。画面単位で振り分ける
- 工程3・診断項目の決定：IPA「安全なウェブサイトの作り方」の付属チェックリストとOWASP WSTG 4.2を基準表にし、自社固有の項目だけを追加する
- 工程4・トリアージ：CVSSスコアの高さだけで並べない。CISAはBOD 19-02の失効に伴い、連邦民間行政機関に対するCVSS使用の要求を取り下げている。KEV（既に悪用された事実）とEPSS（今後30日の悪用確率）を組み合わせる
- 工程5・修正と再診断：再診断の合格条件を診断前に文書化しておく。「報告書の全項目がClosed」ではなく「同じ攻撃手順が再現しないこと」で判定する
以下、各工程の判断基準を順に見ていきます。費用相場や診断会社の選び方は脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説にまとめています。
脆弱性診断の守備範囲と、隣接する手法との境界
脆弱性診断は、対象システムへ攻撃を模したパケットやリクエストを送り、既知の欠陥が存在するかを確認する時点評価です。経済産業省の「ASM導入ガイダンス」（令和5年5月29日初版）は、この方式について「調査のためのパケットがセキュリティ監視装置に検出されアラートを発報する場合や、対象のIT資産の動作に支障を及ぼす場合がある」と述べています。裏を返せば、検知の確度が高いのは実際に攻撃相当の入力を送っているからです。
隣接する手法との境界を先に押さえておくと、診断で何を期待してよいかがはっきりします。
| 手法 | 入力 | 判定できること | 判定できないこと |
|---|---|---|---|
| 脆弱性診断 | 攻撃を模したリクエスト | 既知の欠陥の有無 | 侵入後の被害範囲 |
| ペネトレーションテスト | 攻撃者と同じ手順 | 目的達成の可否 | 網羅的な欠陥一覧 |
| ASM | 外部からの観測のみ | 公開資産と存在可能性 | 脆弱性の確定 |
ASMは可能性の検知にとどまり、それを確定させる工程が脆弱性診断です。両者は代替ではなく前後関係にあります。ASMやBASによる自動化の限界は脆弱性対応の自動化｜ASM・BAS・ASVの使い分けと限界、目的の違いから発注単位を分けたい場合はペネトレーションテストと脆弱性診断の違い｜目的・費用・使い分けを発注前に整理を参照してください。
工程1：診断計画とスコープ定義
診断の質は、対象を決めた時点でほぼ決まります。ここを曖昧にしたまま発注すると、報告書は届くのに肝心の画面が診られていない、という結果になります。
対象資産の洗い出しと診断範囲の切り方
最初に固めるのは、ホスト名とIPアドレスの一覧、診断対象URLの一覧、APIエンドポイントの一覧という3種類の対象リストです。そのうえで、それぞれをどの認証状態で診るかを決めます。特に抜けやすいのが認証状態で、ログイン後にしか到達できない画面は、認証情報を渡さない限りツールも診断員も踏み込めません。管理者・一般ユーザー・未認証の3ロール分の資格情報を用意し、どのロールでどこまで診るかを範囲表に書き込みます。
本番とステージングのどちらで実施するかも計画段階の決定事項です。本番で診るなら、攻撃相当のトラフィックが流れるためWAFやIDSの検知ルールを調整するか、送信元IPを許可リストに登録します。ステージングで診るなら、本番との構成差分（WAFの有無、パッチレベル、外部連携の疎通）を残し、診断結果の適用範囲を限定しておきます。
クラウド事業者への事前申請が要る範囲
クラウド上の環境では、事業者のテストポリシーを計画に組み込みます。AWSの侵入テストポリシーの場合、許可サービス一覧に載っているリソースへの診断は事前承認が不要です。一方で、Red/Blue/Purple Team Testing、iPerf Testing、Simulated Phishing、Malware Testingの4類型はSimulated Eventsフォームの提出が必要で、開始の2週間前までに出す必要があります。負荷試験は禁止ではなく、別途Stress Test policyの管轄になります。
「C2ホスティングだけ申請すればよい」と要約すると3類型を取りこぼすので、該当の有無は4類型それぞれで確認してください。あわせて範囲の外側も押さえておきます。同ポリシーは「Customers are not permitted to conduct any security assessments of AWS infrastructure or the AWS services themselves.」と明示しており、許可サービス一覧はあくまで自社が構築したリソースを診るための枠です。アウトバウンドの侵入テストではAmazon API GatewayとAmazon Bedrock AgentCoreが禁止サービスとして列挙されています。AWS環境固有の範囲設定とツール選定はAWSの脆弱性診断｜事前申請が要る範囲とツール選定・費用の判断基準で扱っています。
工程2：ツール診断と手動診断の割り当て
ツール診断と手動診断は、どちらが優れているかではなく、どの欠陥に届くかで役割が分かれます。全画面を一律に「ツール＋手動」で診るのは費用の無駄になりやすく、画面単位で割り当てるのが現実的です。
ツール診断が構造的に取りこぼす欠陥
スキャナは、リクエストを改変して応答の差分を見る仕組みです。したがって「正しい応答」と「異常な応答」を機械的に区別できる欠陥には強く、SQLインジェクションやクロスサイト・スクリプティング、既知CVEを持つミドルウェアの検出は自動化で十分な精度が出ます。
逆に、応答としては正常な処理が返ってくる欠陥には届きません。他人の注文IDを指定すると他人の明細が表示される、決済確定前に金額パラメータを書き換えると割引が二重に適用される、退会済みアカウントのトークンが失効していない。いずれも仕様上ありうる応答なので、スキャナは異常と判定できません。ファジングとは？脆弱性を自動検出する仕組みとツール・他テストとの使い分け【2026年版】で扱う無効値の総当たりも、この種のロジック欠陥には効きません。
手動診断へ回す画面の選び方
手動に回すべきなのは、金銭・個人情報・権限のいずれかが動く画面です。決済、ポイント付与、権限変更、退会処理、他ユーザーの情報を参照する画面。この5種は、画面数が少なくても優先的に手動枠を確保します。残りの静的な閲覧系画面はツール診断で網羅し、指摘が出たものだけ手動で再現確認する、という配分にすると費用対効果が合います。
ツールの具体的な操作は、WebアプリケーションならOWASP ZAPの診断項目とは？検出できる脆弱性一覧と使い方、リクエストを手で組み替えて検証するならBurp Suiteとは？通信傍受の仕組みとエディションの選び方・初期設定が入口になります。
工程3：診断項目の決め方｜IPA・OWASPのガイドラインを基準表にする
診断項目をゼロから設計する必要はありません。公開されている項目表を基準にし、自社固有の要素だけを足すのが早くて漏れが少ない方法です。
日本語で参照できる基準としては、IPA「安全なウェブサイトの作り方」の改訂第7版（第4刷・2021年3月31日公開）があります。第1章でSQLインジェクションやOSコマンド・インジェクションなど11種類の脆弱性を扱い、付属資料としてウェブアプリケーションのセキュリティ実装状況を確認するためのチェックリストが付いています。実装側の観点で書かれているため、診断項目としてそのまま流用しやすい構成です。
診断側の観点で直接使えるのは、同じIPAのページで配布されている別冊「ウェブ健康診断仕様」です。IPAの説明によれば、危険度の高い脆弱性など13の診断項目について、検出パターンとそれに対応した脆弱性有無の判定基準が記載されています。判定基準まで公開されているため、自社の項目表の妥当性を照合する土台になります。
より網羅的な体系が要る場合はOWASPのWeb Security Testing Guideを使います。安定版は4.2（2020年12月3日リリース）で、v5.0は開発中の段階です。4.2は情報収集から設定管理、認証、認可、セッション管理、入力値検証まで、テスト観点をID付きで列挙しています。
追加すべき自社固有の項目は、業務ロジックに紐づくものに限ります。多段階承認のスキップ、契約プランごとの機能制限の回避、外部連携APIのレート制限の迂回。この種の項目は公開項目表には載らないので、仕様書から起こします。Webアプリケーションで優先度の高い項目の詳細はWebアプリケーション脆弱性診断で特に重要な項目とは？にまとめています。
工程4：検出結果のトリアージ
診断が終わると、数十から数百件の指摘が並んだ報告書が届きます。全部を同じ速度では直せません。ここが脆弱性診断の実務で最も判断を要する工程です。
CVSSスコア単独で優先度を決めない根拠
「CVSS 9.0以上のCriticalから潰す」という運用は広く使われていますが、規格側はこの使い方を想定していません。CVSS User Guideの2.2節は「CVSS Base (CVSS-B) scores are designed to measure the severity of a vulnerability and should not be used alone to assess risk.」と述べています。基本値は深刻度の尺度であって、リスク評価に単独で使うものではない、という趣旨です。
制度側でも同じ方向に動いています。CISAは2026年6月10日にBOD 26-04「Prioritizing Security Updates Based on Risk」を発出し、その中でBOD 19-02とBOD 22-01の両方を同時に失効させました。実装ガイダンスには「By revoking BOD 19-02, the FCEB no longer requires CVSS use for vulnerability prioritization.」とあります。連邦民間行政機関（FCEB）に対して、脆弱性の優先度付けにCVSSを使うことを要求しなくなった、という記述です。
ただしこれはCVSSの放棄ではありません。同じQ&Aは続けて、この指令がFIRSTの「CVSS SIG Consumer Implementation Guidance」とも整合すること、成熟した優先度付けは同ガイダンスの技術・脅威・環境の各情報を使って判断に至ることを述べています。否定されているのは基本値だけを見て順番を決める運用であって、CVSSの脅威評価・環境評価まで使う運用ではありません。
参考までに、現行のCVSS v4.0（仕様書Version 1.2、2024年6月18日）の定性評価はNone 0.0、Low 0.1〜3.9、Medium 4.0〜6.9、High 7.0〜8.9、Critical 9.0〜10.0です。この帯は深刻度のラベルであり、修正の順番を示すものではないと理解して扱ってください。
KEVとEPSSの役割分担
CVSSを補うのが、悪用の実態を扱う2つのデータです。役割が異なるので、片方だけでは足りません。
| データ | 示すもの | 時間軸 | 更新 |
|---|---|---|---|
| CISA KEV | 悪用された事実 | 過去から現在 | 追加は24時間以内が目標 |
| EPSS | 悪用される確率 | 今後30日 | 全CVEを毎日 |
EPSSはfirst.orgの定義で「estimates the probability that a published CVE will be exploited in the wild in the next 30 days」とされ、全CVEに対して0〜1の確率とパーセンタイル順位を毎日公開しています。KEVは既に起きたことの記録なので、載った時点で確実に危険ですが、載るまでの間は空白になります。CISA自身も「CISA aims to update the KEV within 24 hours」としつつ、遅延要因があることを認めています。またKEVへの追加に公開PoCの存在は要件ではない（「an available POC is not a requirement for addition to the KEV Catalog」）ため、PoCの有無を掲載判断の代理指標にはできません。
実務では、KEV掲載済みを即時対応の確定条件とし、未掲載のものをEPSSの確率で並べ替える、という二段構えにすると空白が埋まります。
4変数で緊急度を決める手順
BOD 26-04は緊急度を4つの変数で決める枠組みを示しています。政府機関向けの指令ですが、変数の設計自体は民間でもそのまま使えます。
- Asset Exposure：その資産はインターネットに公開されているか
- KEV Status：そのCVE IDはKEVカタログに載っているか
- Exploit Automation：攻撃者は悪用に必要な手順を全て自動化できるか
- Technical Impact：悪用後に資産の部分的な制御を得るか、完全な制御を得るか
この4つを診断報告書の各指摘に対して埋めると、CVSSの数字とは違う並びが出てきます。CVSS 7.2でも公開資産かつKEV掲載かつ自動化可能なら最優先、CVSS 9.8でも社内限定ネットワークの資産で悪用に物理アクセスが要るなら後回し、という判断が根拠つきで説明できるようになります。なお同ガイダンスは「BOD timelines represent maximum duration until a remediation is applied」とも述べており、期限は上限であって目標値ではありません。社内の修正期限を設計するときに、この区別を落とさないでください。
この4変数の運用を、診断のたびの単発作業ではなく継続的なプロセスとして回す考え方がCTEMとは？脆弱性管理との違い・5つの段階と企業の導入判断を解説で扱うCTEMです。
工程5：修正と再診断の合格判定
修正が終わったら再診断します。この工程で崩れやすいのが合格の定義です。「報告書の全項目がClosedになったこと」を合格条件にすると、修正の仕方によっては通ってしまいます。
攻撃手順の再現による合格判定と横展開の範囲
合格判定は、指摘の管理番号ではなく攻撃手順で行います。診断報告書に記載された再現手順（リクエスト内容、パラメータ、想定される応答）をそのまま再実行し、脆弱な応答が返らないことを確認する。これが最小の合格条件です。工程2で挙げた他人の注文IDの例なら、修正後に同じリクエストを投げて403や404が返ることを確認します。
curl -i -H "Cookie: session=<自アカウントのセッション>" \
"https://example.com/api/orders/10024"
# 修正前: 200 OK ＋ 他ユーザーの明細
# 合格条件: 403 または 404（200で本文が空、は不合格）ステータスコードだけでなく応答本文まで確認するのが要点です。200を返したまま本文を空にする修正は、権限チェックではなく表示の抑止にすぎず、別の経路から漏れます。また、指摘された画面だけを直して同じ欠陥が他画面に残っているケースは頻出するので、同種の指摘が複数画面で出ていた場合は、修正した画面と同じ実装パターンを使う全画面を再診断の対象に含めます。
WAFによる暫定対処を合格とみなすかの線引き
WAFのシグネチャ追加で応答をブロックしただけの状態を「修正済み」として合格させるかどうかも、事前に決めておく判断です。恒久対処が間に合わない場合の暫定措置としては妥当ですが、その場合は「アプリケーション側は未修正」であることを台帳に残し、恒久対処の期限を別途設定します。ここを曖昧にすると、WAFのルールを見直した瞬間に脆弱性が復活します。
再診断が初回費用に含まれるか別料金かは会社によって異なります。含まれる回数と対象範囲は、発注前の見積もり条件に書き込んでおいてください。
指摘ゼロが安全の証明にならない3条件
検査範囲を絞った診断で脆弱性が出なかったことを、安全の証明として扱ってはいけません。IPAも「ウェブ健康診断仕様」について「検査パターンを絞り込んだ診断ですので、脆弱性が検出されなかった場合でも、安全宣言には繋がりません」と注記しています。これは項目を絞った場合の話ですが、実務ではもっと手前の実施条件が原因で「診ていないから出なかった」結果になることがあります。報告書を受け取ったら、まず次の3点を確認してください。
条件1：認証後の画面が範囲外だった
認証情報を渡さずに実施した診断は、ログイン画面までしか到達していません。会員制サービスの脆弱性の大半はログイン後の画面にあるので、この条件下の「指摘なし」は診ていないという意味です。工程1で用意した3ロール分の資格情報が実際に使われたか、報告書の実施条件欄で確認します。
条件2：WAFやIPSを経由したまま診断した
防御機器が攻撃相当のリクエストを遮断すると、スキャナには「攻撃が通らなかった」と見えます。アプリケーション側の欠陥はそのまま残っているのに指摘が出ない、という偽陰性です。本番で診断するなら、送信元IPを許可リストに入れるか、オリジンへ直接到達する経路を用意します。
条件3：スキャンが途中で止まっていた
レート制限、セッションの強制ログアウト、CAPTCHA、対象サーバの高負荷。いずれもスキャンを中断させ、クロールできたURLの数を大きく減らします。報告書のクロール件数と、工程1で提出した対象URL一覧の件数を突き合わせて、乖離があれば実施条件を見直したうえで再実施を要求します。
3条件のどれかに該当する診断は、費用を払って「診ていない範囲がある」ことを確認しただけの結果になります。指摘件数がゼロだったときこそ、実施条件を疑ってください。
診断の頻度とタイミングの決め方
脆弱性診断は時点評価なので、実施した瞬間から結果は古くなります。EPSSが全CVEのスコアを毎日更新しているのは、悪用可能性が短い周期で動くことを前提にした設計だからです。したがって「年1回実施しているから安全」という運用は成り立ちません。
頻度は、暦ではなく変更イベントで決めるほうが実態に合います。次のいずれかが起きたら、その範囲を対象に診断を実施する、という設計です。
- 認証・認可・決済に関わる機能を追加または変更したとき
- 外部公開するエンドポイントを新設したとき
- ミドルウェアやフレームワークをメジャーバージョン更新したとき
- インフラ構成を変更し、公開範囲が変わったとき
これに加えて、変更がない期間も定期実施の枠を確保します。自社が受けている監査や業界基準（PCI DSSなど）に準拠要件がある場合は、その要件が定める間隔が上限（それ以上は空けられない値）になるため、適用される条文を確認して間隔を決めてください。要件がない場合でも、公開資産については年次より短い間隔で回すのが現実的です。
よくある質問
脆弱性診断にはどれくらいの期間がかかりますか？
診断対象の規模と手動診断の比率で決まります。ツール診断中心であればスキャン自体は数時間から数日ですが、報告書の作成と精査に別途日数が要ります。手動診断を含む場合は、対象画面数と診断員の工数の掛け算になるため、見積もり時に「診断実施日数」と「報告書提出までの日数」を分けて確認してください。加えて、工程1のスコープ確定と資格情報の準備に要する期間を見落とすと、着手が遅れます。
無料の脆弱性診断ツールだけで済ませられますか？
既知パターンの検出という範囲に限れば、OWASP ZAPのようなオープンソースのスキャナでも実用的な結果が得られます。ただし工程2で述べたとおり、権限まわりやビジネスロジックの欠陥はツールの仕組み上検出できません。無料ツールで自動化できる部分を内製し、金銭・個人情報・権限が動く画面だけ手動診断を外注する、という切り分けが費用面では合理的です。
脆弱性診断とペネトレーションテストはどちらから実施すべきですか？
通常は脆弱性診断が先です。既知の欠陥が多数残っている状態でペネトレーションテストを実施しても、既知の穴から侵入できたという結果が出るだけで、防御体制の評価にはなりません。診断で検出した指摘を修正したあとに、目的達成の可否を試すのがペネトレーションテストの使いどころです。判断の詳細はペネトレーションテストと脆弱性診断の違い｜目的・費用・使い分けを発注前に整理で整理しています。
セキュリティパッチを適用していれば脆弱性診断は不要ですか？
不要にはなりません。パッチが解決するのは、ベンダーが提供する製品に含まれる既知の欠陥です。自社で実装したアプリケーションのSQLインジェクションや認可の抜け、設定ミスによる情報公開はパッチでは塞がりません。逆に、パッチ管理が行き届いていれば診断で検出される既知CVEの件数は減るので、両者は診断対象の層が違う対策だと考えてください。
脆弱性診断を内製するには脆弱性診断士の資格が必要ですか？
法令上の必置資格ではないため、資格がなくても診断は実施できます。スキルレベルの共通指標としては、JNSA-ISOG-JとOWASP Japanの共同ワーキンググループが定義するスキルマップがあり、GSXのSecuriST認定脆弱性診断士はその「Silver」レベル相当を認定するものです。認定Webアプリケーション脆弱性診断士と認定ネットワーク脆弱性診断士の2コースがあり、いずれも2日間の講座とCBT30問（60分）の試験で構成され、認定の有効期間は3年です。費用は講座と試験1回で1コースあたり22万円（税込）、試験のみの受験と再試験は各29,700円（税込）です。両方を取得するなら講座費用は2コース分かかります。金額や実施形態は改定されるため、申し込み前に公式サイトで確認してください。内製と外注の判断軸は脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説にまとめています。
