Tsuzura

脆弱性診断の進め方

許可と範囲を先に決め、脆弱性診断の結果を人が確認して修正・再診断まで管理する手順を解説します。

公開日
更新日

脆弱性診断は、ツールを起動するところから始まりません。最初に確認するのは、システムの所有者が診断を許可しているか、どこまで触れてよいか、異常が起きたときに止められるかです。許可または影響範囲が分からない場合は、診断を始めずHOLDにします。

この記事では、Webサービスの脆弱性診断を計画し、検出結果を修正・再診断まで管理する流れを扱います。対象は、AI経由で調べ始めた人です。読み終えると、空欄の「脆弱性診断計画票」と「結果・修正・再診断記録」を作れます。

個別脆弱性の直し方、脅威モデル、認証認可の設計、診断会社やツールの比較、法的助言、バグ報奨金制度の運営は扱いません。実用的な攻撃ペイロード、権限回避、持続化、データ持出しの手順も載せません。

本記事では、脆弱性診断を「所有者が許可した範囲で確認方法を組み合わせ、検出事項を修正・再診断まで管理する作業」とします。単一のスキャンやツールの実行だけを指す言葉としては使いません。

最初にGO・HOLDを決める

診断の開始条件は、次の三つです。

  1. システムの所有者と、必要な第三者側で許可権限を持つ人が、実施者、対象、期間、許可する方法を明示的に許可している
  2. 対象・対象外と、利用者やデータ、外部サービスへ及ぶ影響を説明できる
  3. 異常時の停止条件、連絡先、再開を判断する人が決まっている

一つでも確認できなければHOLDです。公開インターネットから到達できること、管理画面へ入れること、ツールを契約していることは、診断の許可を意味しません。自分で作ったサービスでも、クラウド、決済、通知、認証など第三者の資産は別の所有者や利用条件を持ちます。

NIST SP 800-115の公式公開ページは、2026年8月20日時点でもFinalとして掲載されています。この資料は、技術的なセキュリティ評価の計画、実施、検出事項の分析、緩和策の策定を扱います。ただし2008年公開であり、個別技術の最新性や日本での法的許可を決める資料ではありません。NIST SP 800-115の本文も、診断計画で境界と許可を定め、関係者が承認することを重視しています。

HOLD 所有者の明示許可、影響範囲、停止・連絡方法のいずれかが不明なら、ツールを実行しません。確認できない欄を推測で埋めず、確認する人と期限を残します。

診断は、その時点で許可した範囲を確認する作業です。検出が0件でも、再診断に合格しても、「脆弱性がない」「将来も安全」とは保証できません。

五つの役割を分ける

「脆弱性診断」「脆弱性スキャン」「手動セキュリティテスト」「ペネトレーションテスト」「コードレビュー」は、同じ対象へ使われることがあります。ただし、見る場所と成果物が違います。本記事では、次のように分けます。

方法 主な役割 主に見るもの 単独では分からないこと 成果物
脆弱性診断 許可、範囲、複数の確認方法、検出事項、修正、再診断を一つの作業として管理する 診断対象と、選んだ確認方法の結果 範囲外、未実行条件、将来の脆弱性 計画票と結果・修正・再診断記録
脆弱性スキャン 既知のパターンや構成上の問題候補を広く自動確認する ツールが到達でき、ルールで判定できる対象 業務ルール、ルール外の問題、ツールが到達できない状態、誤検知・見逃し 未確定の検出候補とツールのログ
手動セキュリティテスト 人が状態、前後関係、アプリケーション固有の振る舞いを見て仮説を確認する 画面、API、認証状態、データの流れ等の動的な振る舞い 実施していない経路、ソースコード内部、実施者が想定しなかった問題 テストケース、観測、保護された証拠
ペネトレーションテスト 許可された範囲で、問題が成立する条件や複数条件のつながりを評価する 外部から見える振る舞いと許可された検証経路 全経路、全脆弱性、将来の状態 限定した検証結果と影響評価
セキュアコードレビュー ソースコード、アプリケーション固有の処理、データの流れ、実装状況を確認する コード、設定、変更、設計上の前提 稼働環境だけで起きる問題、ソースコード外の構成、実際の到達可能性 レビュー所見と対象範囲

OWASP Web Security Testing Guide（WSTG）のプロジェクトページは、2026年8月20日時点でv4.2を安定版、v5.0を開発版として案内しています。本記事は、内容が変わり得る開発版ではなく、版を固定したWSTG v4.2のIntroductionを参照します。同資料は、人による確認、コードレビュー、ペネトレーションテストなどを異なる技法として扱い、一つの技法だけでは確認できる範囲が限られると説明しています。脆弱性診断は、これらを全部行うという意味ではありません。目的とリスクから必要な方法を選び、選ばなかった範囲も記録します。

脆弱性スキャンは診断の入力

NIST SP 800-115が示すとおり、スキャン結果は、確定した検出事項ではなく確認候補です。スキャナーには誤検知があります。別のツールが同じ判定を返しても、共通のルールや前提によって同じ誤検知になる可能性があります。反対に、認証状態、構成、実行経路、ルール、時点によって見逃しも起こります。

そのため、ツール名、版、ルール、対象、認証の有無、実行時点を残し、人が対象の状況と証拠を確認します。「スキャンが通った」だけでは診断完了にも安全の証明にもなりません。

手動セキュリティテストにも限界がある

手動確認は、アプリケーション固有の状態や業務ルールを見られる一方、実施者の技量、時間、用意した仮説に左右されます。手動なら正しい、すべてを確認できる、という意味ではありません。

影響を予測できない検証を、試しながら学ぶ方法には向きません。利用停止、データ変更、権限への影響が考えられる場合は、計画票で許可された低影響の確認に限定するか、セキュリティの専門家へ渡します。

ペネトレーションテストは強いスキャナーではない

ペネトレーションテストは、許可された範囲で問題の成立可能性や条件のつながりを評価します。時点と経路を選んだ限られた確認であり、単独で全脆弱性を見つける方法ではありません。

所有者の許可と実施規則（Rules of Engagement、ROE）がない状態では行いません。本番への無断の負荷、破壊的操作、権限回避、持続化、データ持出しを、一般的な診断手順には含めません。必要性が疑われる場合は、実施方法を自己判断せず、所有者と専門家が別の承認対象として扱います。

セキュアコードレビューはソースの状況を見る

OWASP Secure Code Review Cheat Sheetは、ソースコードを人が読み、アプリケーション固有の処理、データの流れ、実装状況を確認する役割を示しています。自動ツールは候補を広く示せますが、状況の判断と結果の確認には人が必要です。

コードレビューは動的な診断と重なる部分がありますが、置き換えにはなりません。一件のAI生成コード差分を採用できるかはAI生成コードをレビューするで扱い、本記事では診断全体の中でセキュアコードレビューを選ぶ条件だけを扱います。

ASVSは確認観点の基準

OWASP Application Security Verification Standard（ASVS）のプロジェクトページでは、2026年8月20日時点の安定版を5.0.0としています。公式リポジトリのv5.0.0へ版を固定すると、どの要件を参照したか追跡できます。

ASVSは、Webアプリの技術的なセキュリティ対策を検証する要件の基準です。診断の許可、実行手順、すべての要件を適用すべきか、合格すれば安全か、を自動的に決めるものではありません。対象に適用する要件、版、除外理由を計画票へ記録します。

一般のテスト範囲や静的・動的、手動・自動の選び方はテストの種類と選び方で確認できます。本記事では、セキュリティ評価固有の許可と検出事項管理に絞ります。

脆弱性診断計画票を作る

ツールを選ぶ前に、一回の診断を識別できる計画票を作ります。NIST SP 800-115はセキュリティ評価を計画、実施、実施後の三段階で扱います。本記事の計画票は、その考え方を一回の診断用に再構成したもので、NISTやOWASPの公式書式ではありません。

所有者の許可を記録する

許可は口頭の雰囲気ではなく、後から範囲を確認できる記録にします。

  • 対象システムと、その所有者
  • 許可する人の氏名または役割
  • 実施者と所属
  • 許可した対象、方法、強度、期間
  • 許可記録または契約の保管先
  • 許可の有効期限と、変更時に再承認する条件

診断会社へ依頼する場合も、会社名だけで許可範囲は決まりません。対象、許可する行為、成果物、データ取扱い、再委託の有無など、実際の合意内容を確認します。この記事は契約や法的判断を代替しません。不明点は組織のセキュリティ、法務、契約担当へ確認します。

対象と操作の範囲を分ける

「このサイトを診断する」という記述だけでは足りません。対象資産と、許可する操作を分けます。

対象には、ドメイン、API、管理画面、クラウドアカウント、ネットワーク、リポジトリ、データ保管先、モバイルアプリ、外部サービスとの接続などのうち、実際に含めるものを識別できる形で書きます。版、環境、接続先が違えば、同じ名称でも別の対象です。

対象外には、第三者サービス、共用基盤、従業員端末、実利用者のアカウント、実データ、別環境など、触れてはいけないものを明記します。対象外へ到達した場合の停止方法も決めます。

操作の範囲には、次を記録します。

  • 使用する方法とツール・版
  • 認証あり・なし、使用する役割
  • 許可する負荷とデータ変更の範囲
  • 禁止する操作
  • 実行元のネットワークや識別情報
  • 適用するASVSや社内基準の版と項目
  • 確認しない範囲と理由

対象に含まれていても、すべての操作が許可されたわけではありません。方法や強度を変える場合は、元の許可で足りるかを所有者へ戻して確認します。

環境、時間帯、テスト用アカウント・テストデータを決める

影響を抑えられるなら、非本番環境を優先します。NIST SP 800-115は、実際の個人情報等を扱うリスクがある場合、非本番環境でテストデータを使う考え方を示す一方、本番との差によって見逃しが起こり得るとも説明しています。

非本番という名称だけで安全とは判断しません。本番との差を次のように残します。

  • アプリケーション、設定、ネットワーク、外部接続の差
  • マスキングや置換を含むデータの差
  • 監視、レート制限、Web Application Firewall（WAF）、キャッシュ等の差
  • 実行権限と利用できるアカウントの差
  • その差によって未確認になる範囲

テスト用アカウントは実利用者のアカウントと分け、診断に必要な役割だけを割り当てます。複数役割を確認するなら、アカウントごとの役割を明記します。認証情報の受け渡し、保管、失効、診断後の削除または無効化も決めます。秘密情報を計画票本文へ直接貼らず、アクセス制御された保管先を参照します。

テストデータは、必要な状態と量、作成方法、個人・顧客・機密情報を含むか、診断後の削除方法を決めます。実データが必要だと判断した場合は、その必要性、アクセス、保護、保有期間を所有者とデータ責任者が明示的に承認できるまでHOLDにします。

時間帯は、開始・終了日時とタイムゾーンまで書きます。影響を抑えられる時間帯を選んでも、無断の本番診断は許可されません。

停止、連絡、再開を決める

停止条件は「問題が起きたら」ではなく、対象システムで観測できる状態にします。固定の数値を記事から流用せず、所有者が普段の指標と事業影響から決めます。

停止条件の候補には、次があります。

  • エラー、応答時間、資源使用量が所有者の定めた範囲を外れた
  • 実利用者、実データ、対象外資産へ影響した
  • 意図しないデータ作成・変更・削除が起きた
  • 監視またはインシデント対応が作動した
  • 許可していない経路や権限へ到達した
  • 実施者が影響を説明できない状態になった

停止を判断できる人、緊急連絡先、連絡手段、停止後に保全する記録、再開を承認できる人を決めます。再開は、ツールを止めて起動し直すことではありません。影響を確認し、必要な対応を終え、所有者が再開条件を満たしたと判断してから行います。

証拠を保護する

診断結果には、システム構成、脆弱性、アカウント、個人データ等が含まれる可能性があります。NIST SP 800-115は、収集、保管、送信、廃棄を含むデータの取扱いを実施規則（Rules of Engagement、ROE）へ定め、診断結果を機微情報として扱うよう示しています。

計画票には次を残します。

  • 証拠を保存するアクセス制御済みの場所
  • 閲覧、追加、削除できる役割
  • 暗号化や安全な送信の方法
  • マスキングまたは削除する情報
  • 保有期間と削除責任者
  • 報告書へ載せる範囲

画面、リクエスト・レスポンス、ログ、ツール出力を無加工で共有しません。秘密情報、セッション情報、個人データ、実用的な攻撃情報を分離またはマスキングし、必要な人だけが保護された原本を参照できる形にします。

計画の境界内で実施する

開始直前に、対象版、許可の有効期間、時間帯、連絡先、監視、停止条件を再確認します。計画作成後に対象や環境が変わっていれば、古い計画のまま始めません。

実施中は、次を追跡します。

  • 実施日時と実施者
  • 対象と実行元
  • 方法、テストケース、ツール・版
  • 使用したテスト用アカウントの役割
  • 観測結果と保護された証拠の参照
  • 計画からの差と、その承認
  • 停止、連絡、再開の記録

未知の挙動を見つけても、その場で強い操作へ広げません。現在の許可と影響範囲で確認できなければ、検出事項候補と未確認理由を残してHOLDにします。

AIには、公開情報の整理、計画票の未記入欄の指摘、許可済みテストケースの候補整理、機微情報を除いた結果の要約を任せられます。一方、AIへ本番の認証情報を渡す、対象外へ接続させる、影響を判断させたまま自律的にテストを広げる、といった運用は行いません。実行権限、対象、停止条件を人が固定し、結果を確認します。

検出結果を人が確定する

ツール出力や一度の観測を、そのまま確定検出事項にしません。検出事項ごとに、次の順で確認します。

  1. 対象、版、環境、認証状態、時点を識別する
  2. ツール・ルールまたは手動テストケースと、保護された証拠を確認する
  3. 計画された低影響の条件で再現できるか確認する
  4. 期待するセキュリティ対策と実際の結果を分ける
  5. 誤検知、確認済み、未再現、情報不足のいずれかを、根拠と判定者付きで記録する
  6. 未確認経路、ツールが到達できなかった状態、環境差等の確認範囲限界を残す

再現できないことと誤検知は同じではありません。時点、権限、環境、設定が違う可能性を確認し、判断できなければ「未再現」または「情報不足」とします。誤検知にする場合も、理由、確認者、再確認する条件を残します。

WSTG v4.2 Reportingは、報告書に範囲、期間、限界を明示し、時点評価であってすべての問題を特定した保証ではないことを示しています。検出事項には理解、確認、解決に必要な情報を含めますが、本記事の空欄票では、危険な再現手順や機微な証拠を直接書かず、アクセス制御された記録への参照にします。

優先順位、修正、再診断をつなぐ

検出事項を確定したら、ツールの重大度や、脆弱性の重大度を共通の尺度で表すCVSSの値だけで順番を決めません。次を合わせて判断します。

  • 影響する資産とデータの重要度
  • 外部公開、認証の要否、到達可能な利用者等の露出
  • 成立に必要な条件
  • 利用者、業務、信頼性、契約への影響
  • 既存の防御や監視と、その確かさ
  • 修正による別のリスクと、修正までの一時対応

OWASP Vulnerability Management Guideのプロジェクトページは、準備、検出、報告、修正を反復するサイクルとして脆弱性管理を扱います。2020年版ガイド本文も、誤検知の検証、資産重要度を含む優先順位、所有者の割当て、修正後のテスト、証拠の保管を一続きにしています。この資料は2020年版であり、現行ツール仕様や一律の期限を決めるものではありません。

修正には、検出事項ID、所有者、期限、対応方針、変更版、確認する一般テスト、残存リスクを結び付けます。個別の修正実装は本記事の範囲外です。設計変更、認証認可、機微データ、複数システムへまたがる対応が必要なら、該当分野の所有者と専門家へ渡します。

再診断は、元の検出事項と同じIDを使い、次を分けて記録します。

  • 元の条件で問題が再現しないか
  • 修正が意図した対策として機能するか
  • 変更によって周辺を壊していないか
  • 実施できなかった条件と新しく残った範囲

修正箇所の確認と、変更による一般的な回帰テストは別の目的です。必要な組合せはテストの種類と選び方へ戻って決めます。公開できるかの判断は、同一の公開候補と証拠をそろえたうえでサービス公開前の確認へ渡します。

再診断に合格したときに言えるのは、記録した対象、版、環境、条件、時点では、元の検出事項について期待した結果を確認したということです。別の脆弱性、範囲外、新しい変更、将来の問題がないとは言えません。

脆弱性診断計画票

空欄のまま複製して使います。分からない項目は推測せず、未確認と確認担当・期限を書きます。開始条件に関わる項目が未確認なら判定はHOLDです。

# 脆弱性診断計画票

## 識別
- 計画ID・版:
- 診断の目的と、結果から決めること:
- 対象システム・版:
- システム所有者:
- 診断責任者:

## 明示的な許可
- 許可する人・役割:
- 許可した日:
- 許可の有効期間:
- 許可記録・契約・実施規則（Rules of Engagement、ROE）の保管先:
- 実施者・所属:
- 再承認が必要になる変更:

## 対象と対象外
- 対象資産・識別子:
- 対象外資産:
- 第三者・共用資産と、その扱い:
- 使用する基準・版・適用項目:
- 確認しない範囲と理由:

## 許可する方法
- 診断方法（スキャン・手動テスト・ペネトレーションテスト・セキュアコードレビュー等）:
- ツール・版・ルール・実行元:
- 認証あり・なしと確認する役割:
- 許可する操作・強度・データ変更:
- 禁止する操作:

## 環境と時間
- 環境（本番・非本番）:
- 本番との差と、そのために未確認になる範囲:
- 開始・終了日時・タイムゾーン:
- 監視する指標と担当:
- 所有者が定めた影響制御の条件:

## テスト用アカウント・テストデータ
- テスト用アカウントIDと役割:
- 認証情報の受渡し・保管・失効方法:
- テストデータの種類・量・作成方法:
- 個人・顧客・機密データの有無と承認:
- 診断後のアカウント・データの削除または無効化:

## 停止・連絡・再開
- 停止条件:
- 停止を判断できる人:
- 緊急連絡先・連絡手段:
- 停止時に保全する記録:
- 再開条件:
- 再開を承認できる人:

## 証拠の保護
- 証拠の保管先:
- アクセスできる役割:
- マスキング・暗号化・安全な送信の方法:
- 報告書へ載せない情報:
- 保有期間・削除責任者:

## 開始判定
- 未確認項目:
- 確認する人・期限:
- 判定（GO・HOLD）:
- 判定者・判定日:

結果・修正・再診断記録

検出事項ごとに複製し、元の計画IDへつなぎます。攻撃に転用できる手順、秘密情報、個人データ、完全なリクエスト・レスポンスは直接書かず、保護された証拠の参照を残します。

# 結果・修正・再診断記録

## 識別
- 検出事項ID:
- 計画ID・対象システム・版:
- 検出日時:
- 検出方法・ツール・版・ルール:
- 検出した人・実行元:

## 人による確認
- 影響する資産・機能・データ:
- 確認した環境・役割・前提条件:
- 期待するセキュリティ対策:
- 観測した結果:
- 保護された再現記録・証拠の参照:
- 判定（確認済み・未再現・誤検知・情報不足）:
- 判定根拠:
- 確認者・確認日:

## 確認範囲と優先順位
- 確認できた範囲:
- 未確認・到達できなかった範囲:
- ツールの誤検知・見逃しに関する留保:
- 資産重要度・露出・成立条件:
- ツールの初期重大度・スコア（使用した場合）:
- 状況を含む優先順位と理由:
- 専門家へ渡す条件・引渡し先:

## 修正
- 修正担当:
- 期限:
- 対応方針・一時対応:
- 変更版・変更記録:
- 一般テスト・回帰テストの参照:
- 残存リスク:
- 残存リスクを判断する人・判断日:

## 再診断
- 再診断の対象・条件:
- 再診断の環境・版・日時:
- 再診断した人・方法:
- 保護された証拠の参照:
- 結果（修正確認・未修正・一部修正・実施不能）:
- 新たに分かった影響・未確認範囲:
- 次の対応・所有者・期限:
- 最終状態（未対応・対応中・HOLD・リスク受容・完了）:
- 最終判断者・判断日:

リスク受容は、実施者やAIが選ぶ状態ではありません。事業とシステムのリスクを引き受ける権限のある所有者が、根拠、期限、見直し条件を記録して判断します。

HOLDと専門家への引き継ぎ

次のいずれかに当てはまる場合は、診断を始めないか、現在の作業を止めます。

  • 所有者の明示許可、対象、対象外、許可する方法を確認できない
  • 第三者または共用資産へ影響する可能性を整理できない
  • 本番の負荷、データ変更、停止の影響を説明できない
  • 停止条件、緊急連絡先、再開判断者が決まっていない
  • テスト用アカウント・テストデータ・証拠を保護できない
  • 対象外へ到達した、または計画外の挙動が起きた
  • 権限回避、破壊的操作、持続化、データ持出し等をしなければ確認できない
  • 認証認可、暗号、個人・機密データ、クラウド・ネットワーク、複数システムにまたがる高度な判断が必要
  • 稼働中の攻撃や情報漏えいが疑われ、診断ではなくインシデント対応が必要
  • 契約、利用規約、法的な許可の判断が必要

HOLDは失敗ではありません。安全に判断するための情報または権限が不足している状態です。足りない情報、確認先、再開条件を計画票に残します。

セキュリティの専門家へ渡すときは、攻撃を試してから説明するのではなく、計画ID、所有者の許可範囲、対象・対象外、環境差、観測した事実、保護された証拠、未実施の確認を渡します。専門家も同じ許可と停止条件の内側で作業します。

出典