脆弱性アセスメント(VA)とは？種類・手順・優先度の決め方をわかりやすく解説

脆弱性アセスメントを始めたいのに、何から着手し、どこまで実施し、どれを先に直すかで迷っていませんか。

この記事は、種類と対象範囲、実施プロセス、スコアリングと優先度、継続運用までを実務の型で解説します。

脆弱性アセスメントとは何か

脆弱性アセスメントは、組織のシステムやアプリケーション、ネットワークに潜む「弱点」を体系的に洗い出し、ビジネスに与える影響の大きさと発生しやすさを評価し、優先度をつけて対策へつなげる取り組みです。

つまり、単なるスキャンの実行ではなく、リスクという経営の言葉に翻訳して「どこから直すべきか」を決めるためのプロセスです。

したがって、脆弱性アセスメントはセキュリティ対策の出発点であり、運用改善の指針にもなります。

1-1. 脆弱性アセスメントの定義と目的

脆弱性アセスメントの中心は「棚卸し→可視化→優先順位付け→改善計画」の一連の流れです。だからこそ、実施するだけで終わらず、現場が実行できるアクションに落とし込むことが重要です。

1-1-1. 定義：資産の弱点を体系的に洗い出す活動

• 対象：サーバ、ネットワーク機器、クラウド設定、Web／モバイルアプリ、ソースコード、社内業務フローなど
• 作業：自動スキャン、設定レビュー、ログ／構成の確認、ヒアリング、ドキュメント確認
• 成果：弱点の一覧、重大度（例：高・中・低）、影響範囲、再現条件、暫定対処と恒久対策案

1-1-2. 目的：事業リスクを可視化し、優先度をつける

• 目的1：重要サービスの停止や情報漏えいの「確率×影響」を下げる
• 目的2：限られた人員・予算のなかで修正作業の順番を決める
• 目的3：監査・コンプライアンス要求（ISMS、SOC2 など）に説明可能な根拠を示す

1-1-3. 到達点：経営に説明できる改善計画

• 30・60・90日の修正ロードマップ
• 影響の大きい資産に対する短期の暫定対策（例：設定変更、アクセス制御）
• 再発防止の仕組み（例：パッチ適用の標準化、IaCのセキュア設定テンプレート）

1-2. 情報セキュリティにおける「脆弱性」「脅威」「リスク」との関係

用語の混同は意思決定を誤らせます。なぜなら、「何が原因で何が結果か」を切り分けないと、対策の優先順位がぶれるからです。

そこで、脆弱性アセスメントでは用語の整理から始めます。

1-2-1. 用語の整理

• 脆弱性：システムや設定の弱点（例：古いミドルウェア、過剰な権限、S3の公開設定）
• 脅威：弱点を悪用しうる存在や事象（例：攻撃者、マルウェア、内部不正、災害）
• リスク：脆弱性と脅威が結び付いたときに生じる損害の可能性

1-2-2. リスク式と優先順位

• 基本式：リスク ＝ 影響度 × 発生可能性
• したがって、影響度が大きく発生可能性も高い項目（例：インターネット公開サーバの既知脆弱性）は最優先で対処します。
• 逆に、影響は大きくても発生可能性が低い項目は暫定対策と監視強化で「受容」も選択肢になります。

1-2-3. 具体例で理解

要素	例	影響	発生可能性	対処の方向性
脆弱性	VPNの既知脆弱性未パッチ	社外から不正侵入	高	直ちにパッチ、MFA必須化
脅威	フィッシング攻撃	認証情報の窃取	中～高	フィッシング対策、FIDO等
リスク	権限過多のサービスアカウント＋公開鍵流出	全データアクセス	中	権限最小化、鍵ローテーション

このように、脆弱性アセスメントは「用語を正しく結び、優先度の根拠を作る」ための枠組みでもあります。

1-3. アセスメントと診断（スキャン／脆弱性診断）／ペネトレーションテストとの違い

同じように語られがちですが、目的とアウトプットが異なります。だから、状況に応じて使い分けることでコスト対効果が上がります。

1-3-1. ゴールの違い

• 脆弱性アセスメント：組織全体の弱点とリスクの棚卸し・優先順位付け
• 脆弱性診断（スキャン含む）：特定のシステムやアプリの弱点を洗い出す技術的テスト
• ペネトレーションテスト：攻撃者視点で実際の侵入可能性を実証し、被害シナリオを確認

1-3-2. 手法・産出物の違い（比較表）

項目	脆弱性アセスメント	脆弱性診断（スキャン／手動）	ペネトレーションテスト
主な対象	組織全体の資産・プロセス	個別のホスト／ネットワーク／アプリ	クリティカル資産と経路
目的	リスク可視化と優先度決定	技術的な脆弱性の網羅	実際に突破可能かの証明
手法	資産棚卸し、設定レビュー、ヒアリング、スキャン併用	自動スキャン＋手動確認	目標設定型の攻撃シナリオ実施
産出物	リスクマップ、改善ロードマップ	脆弱性一覧、修正推奨	侵入経路、再現手順、影響証跡
適した場面	全体最適を図りたいとき	リリース前検証や定期点検	防御の実効性を証明したいとき
頻度	四半期～半期など継続	月次～リリース都度	年次や大規模変更時

1-3-3. 使い分けの実務的な指針

• まず脆弱性アセスメントで資産とリスクの全体像をつかむ
• 次に、優先度の高い領域へ脆弱性診断を実施し、修正を回す
• そのうえで、重要システムについてはペネトレーションテストで防御の実効性を検証
• その結果、修正が完了したら再診断を行い、継続的にサイクル化する（例：四半期ごとにミニアセスメント＋主要リリース前に診断）

必要性と導入タイミング

脆弱性アセスメントは、単なる「スキャンの実行」ではありません。つまり、事業に直結するリスクを見える化し、限られた予算と人員で最大の効果を出すための意思決定プロセスです。したがって、いつ実施するか、どの深さで行うかを戦略的に決めることが重要です。

2-1. なぜ脆弱性アセスメントが企業にとって重要か（メリット）

2-1-1. 経営リスクの可視化と優先順位付け

脆弱性アセスメントは、資産の重要度、脅威の現実性、脆弱性の深刻度をひとつの軸にまとめ、修正すべき順番を明確にします。

だから、場当たり的な修正に追われるのではなく、効果の大きい箇所から投資できます。

• どのサービスが止まると致命的かを定義する
• 外部公開領域や権限まわりなど、攻撃経路になりやすい箇所を優先
• 経営層に説明できる根拠付きのロードマップを提示

2-1-2. コスト最適化と工数の前倒し削減

事後対応は高くつきます。なぜなら、復旧、法的対応、顧客通知、ブランド毀損が同時に発生するからです。脆弱性アセスメントによる予防は、修正の工数を早期に確保でき、総コストを圧縮します。

観点	事後対応	予防（脆弱性アセスメント）
直接費	復旧、フォレンジック、外部対応	診断費用、修正工数
間接費	機会損失、信用低下	手戻り削減、運用品質向上
タイムライン	突発・長期化しやすい	計画的・短期で回せる

簡易式
予防の価値 ＝ 回避できた損失額 − アセスメントと修正の費用
したがって、損失の最大化を避ける観点で脆弱性アセスメントは費用対効果が高い打ち手です。

2-1-3. 事故発生時の被害最小化と復旧力の向上

脆弱性アセスメントの副産物は、資産台帳と依存関係の整理です。その結果、万一のインシデントでも影響範囲を素早く特定でき、封じ込めと復旧までの時間を短縮できます。

• 優先遮断リスト、暫定対策の手順が用意済み
• 影響の大きいデータや業務プロセスが明確
• 関係者への連絡系統が整備されている

2-1-4. 社内合意と説明責任の強化

脆弱性アセスメントのレポートは、開発、運用、経営の共通言語になります。つまり、主観ではなくデータに基づく意思決定が可能です。

• 重大度とビジネス影響をセットで提示
• チケット化と期日の合意で進捗が可視化
• 監査や取引先への説明資料としても再利用可能

---

2-2. いつ実施すべきか／変化発生時・リスク発見時のタイミング

2-2-1. 基本の周期設計

頻度はビジネス重要度と変更の多さで決めます。一般的には次のような周期が目安です。

• 重要サービスや外部公開資産は四半期ごと
• 社内向け基幹系は半期ごと
• 変更が少ない周辺資産は年次で棚卸し

2-2-2. イベントドリブンの実施トリガー

定期に加え、次のイベントが発生したら臨時で脆弱性アセスメントを走らせます。なぜなら、環境やリスクが一気に変わるからです。

• 大規模リリースやアーキテクチャ変更
• クラウド構成の拡張、ネットワーク再設計
• ゼロデイ脆弱性の公表や重大インシデント発生
• 新規サービスの公開、M&Aによる資産統合
• 重要ベンダーの入替えやSaaS採用
• 監査指摘、顧客要件、規制変更の通知

2-2-3. 重要度別の推奨頻度（例）

重要度	具体例	推奨頻度	補足
高	決済、顧客データ、対外API	四半期	主要リリース前に追加チェック
中	社内基幹、業務SaaS連携	半期	権限・設定のドリフト確認
低	情報系、検証環境	年次	新規公開時のみ臨時実施

このように、定期と臨時を組み合わせることで、ムダなく的確な脆弱性アセスメント運用が可能になります。

---

2-3. 法令・規制・コンプライアンス要件との関係

2-3-1. 代表的な基準との対応関係

脆弱性アセスメントは、多くの基準で推奨または事実上求められる活動です。したがって、計画的に実施してエビデンスを残すことで、監査対応がスムーズになります。

• ISMSや各種マネジメントシステムのリスク評価・是正プロセス
• NIST系フレームワークの識別と保護のコントロール
• PCI DSSなどの業界基準における定期的な脆弱性管理
• SOC 2における変更管理とリスク低減の証跡
• 個人情報保護関連の実効的な安全管理措置の一部としての実施

2-3-2. 監査・取引先から求められるエビデンス

脆弱性アセスメントを「やった」で終わらせないために、次を揃えておきます。その結果、監査・顧客審査・入札で強みになります。

• 実施計画と対象スコープ、使用ツール、実施日
• 発見事項の一覧、重大度、根拠、影響範囲
• 修正チケットと完了証跡、例外承認の記録
• 改善計画とフォローアップ日程

2-3-3. ベンダー管理と契約への反映

サプライチェーンの弱点は自社のリスクです。だから、重要委託先やSaaSにも脆弱性アセスメント相当の管理を要求します。

• 契約での最低限の脆弱性管理要件
• 年次の自己評価書や第三者レポートの提出
• 重大インシデントの通知義務と是正期限

種類と対象範囲

脆弱性アセスメントは「何を」「どこまで」「どれくらいの頻度で」評価するかで成果が大きく変わります。

つまり、種類と対象範囲を正しく設計できれば、限られたリソースでも最大のリスク低減効果を得られます。

以下では、脆弱性アセスメントの代表的な種類、内部・外部という視点による対象範囲の切り方、そして頻度とスコープの決め方を順に解説します。

3-1. アセスメントの種類（ネットワーク、Webアプリケーション、ホスト、クラウド等）

3-1-1. ネットワーク脆弱性アセスメント

• 目的：ネットワーク全体の露出面を把握し、侵入・横展開に使われやすい弱点を特定する
• 主な対象：ルータ、ファイアウォール、VPN、L3/L2スイッチ、無線LAN
• 代表的な観点：不要ポートの開放、暗号化・認証設定、セグメンテーション不備、VPNの既知脆弱性
• ポイント：まずは外部公開アドレス帯から。次に重要セグメント間の通信制御を確認する

3-1-2. Webアプリケーション脆弱性アセスメント

• 目的：アプリ固有のロジックや入力処理の欠陥を洗い出し、情報漏えいとアカウント乗っ取りを防ぐ
• 主な対象：Web/API、モバイル向けバックエンド、管理画面
• 代表的な観点：認可不備、認証まわり、入力検証（XSS/SQLi）、セッション管理、APIスキーマの公開範囲
• ポイント：自動スキャンに加え、権限昇格やビジネスロジックの手動確認を必ず入れる

3-1-3. ホスト／エンドポイント脆弱性アセスメント

• 目的：OSやミドルウェア、エージェントの設定・パッチ状況を可視化し、横展開リスクを抑制する
• 主な対象：サーバ（物理・仮想）、コンテナホスト、VDI、開発端末
• 代表的な観点：未適用パッチ、不要サービス、権限過多、脆弱なプロトコル、ログ監査の欠落
• ポイント：資産台帳と連動し、網羅率（スキャンカバレッジ）をKPI化する

3-1-4. クラウド／コンテナ／Kubernetes脆弱性アセスメント

• 目的：クラウド特有の設定不備やアイデンティティの過剰権限、コンテナイメージの既知脆弱性を発見する
• 主な対象：IaaS（IAM、ネットワーク、ストレージ）、PaaS、SaaS、イメージレジストリ、Kubernetes
• 代表的な観点：公開設定（ストレージ・LB）、IAMの最小権限、セキュアデフォルト逸脱、イメージの既知脆弱性、シークレット管理
• ポイント：構成のルール化（ポリシー）と継続的スキャンを前提に、コードとしての構成（IaC）も評価する

3-1-5. 無線／モバイル／OTなどの拡張領域

• 無線LAN：暗号化方式、ゲスト分離、持ち込み端末ポリシー
• モバイル：証明書ピンニング、データ保存、意図しない情報共有
• OT/ICS：レガシープロトコル、ネットワーク分離、事業継続優先の運用実態
• ポイント：事業特性と可用性要件を踏まえ、停止リスクのない手法を選ぶ

3-1-6. 種類別の比較（概要）

種類	主な目的	代表的な弱点	初手の優先対象	注意点
ネットワーク	露出面の縮小	不要ポート、VPN脆弱性	外部公開IP帯	本番停止を避ける計画
Webアプリ	情報漏えい防止	認可不備、XSS/SQLi	認証・権限境界	手動テストの比率確保
ホスト	横展開阻止	未パッチ、権限過多	特権サーバ	網羅率の管理
クラウド/コンテナ	誤設定防止	公開ストレージ、過剰権限	重要アカウント/IAM	IaCと合わせて評価
OT/その他	可用性重視	レガシー設定	制御ネットワーク	影響ゼロの手法選定

---

3-2. 内部／外部の視点からの対象範囲設定

3-2-1. 外部視点（攻撃者から見える面）での脆弱性アセスメント

• 対象：インターネット公開資産（ドメイン、IP、SaaS、公開API、CDN）
• 目的：露出している資産の棚卸しと、攻撃に使われやすい弱点の早期発見
• 具体策：外部スキャン、証明書・DNS監査、OSINTでの攻撃面（アタックサーフェス）洗い出し
• メリット：緊急性の高い弱点を短時間で可視化できる

3-2-2. 内部視点（社内からの到達面）での脆弱性アセスメント

• 対象：社内ネットワーク、ゼロトラスト未適用領域、社内SaaS連携、管理系システム
• 目的：初期侵入後の横展開や権限昇格の可能性を抑える
• 具体策：内部セグメントスキャン、権限・グループレビュー、パッチ準拠率の測定
• メリット：被害拡大を未然に防ぐガードレールを整備できる

3-2-3. サプライチェーン・委託先の評価

• 対象：重要ベンダー、共同開発先、SaaS事業者
• 目的：委託先の弱点が自社のリスクにならないようにする
• 具体策：自己評価票、第三者レポート、外部露出の簡易スキャン、契約条項での要件化
• ポイント：重要データに触れる先から優先する

3-2-4. 対象範囲の切り方（実務のコツ）

• ビジネス重要度で層別化し、層ごとに深さを変える
• 「外部→内部→委託先」の順で段階的に広げる
• ドキュメント化し、次回以降の差分が追える形にする

---

3-3. 頻度・スコープの設定方法

3-3-1. 決め方の基本フレーム

頻度とスコープは「影響度×発生可能性×変更頻度」で決めます。

つまり、変化が大きく影響も大きい領域は短いサイクルで深く行い、逆は長いサイクルで軽く行うのが合理的です。

• 影響度：停止・漏えい時の損害の大きさ
• 発生可能性：露出の大きさ、既知脆弱性の多さ、攻撃トレンド
• 変更頻度：デプロイ回数、構成変更、ユーザー数の増減

3-3-2. 推奨頻度マトリクス（例）

リスク水準	代表例	実施頻度	深さ（例）
高	決済、顧客DB、外部公開API、特権IAM	四半期＋主要リリース前	自動＋手動詳細、設定レビュー、ペンテ前提領域の抽出
中	業務SaaS連携、社内基幹、管理ポータル	半期	自動中心＋重点手動、権限レビュー
低	情報系、検証環境	年次	自動スキャン＋差分確認

3-3-3. スコープ設定の七つの質問

1. どのビジネス機能を守るための脆弱性アセスメントか
2. 何が「資産」か（システム、データ、アカウント、鍵）
3. 外部・内部どちらの視点を重視するか
4. 重要データはどこにあり、どの経路を通るか
5. 誰が管理するか（自社、ベンダー、SaaS）
6. 可用性制約は何か（停止不可時間帯、影響度）
7. 成果物は誰に説明するか（経営、開発、顧客、監査）

3-3-4. 実行計画の例（テンプレート）

• 対象と深さ
  • 外部公開：全IP/ドメインの露出棚卸し＋アプリは手動重点
  • 内部要：特権サーバ群はパッチ準拠率と権限棚卸し
  • クラウド：IAMロールの過剰権限検査、公開設定の継続監視
• スケジュール
  • 月次：差分スキャンとアラート確認
  • 四半期：重要資産の詳細アセスメント、是正計画の更新
  • 半期：委託先評価の更新、例外承認の再審査
• 成果物
  • リスクマップ（重大度と影響面）
  • 30・60・90日改善ロードマップ
  • 例外承認一覧と期限、再評価日

実施プロセスとチェック項目

脆弱性アセスメントは、単なる「スキャン」ではなく、再現可能なプロセスです。

つまり、準備で土台を整え、スキャン・診断で事実を集め、分析で優先順位を付け、報告で意思決定を支援し、改善で効果を出す一連の流れを確立します。

4-1. 実施の流れ：準備 → スキャン・診断 → 分析 → 報告 → 改善

4-1-1. 準備（目的・スコープ・体制の確定）

まず、脆弱性アセスメントの「ねらい」を明確にします。なぜなら、目的が曖昧だとスコープが広がりすぎ、成果がぼやけるからです。

• 目的例：外部公開資産の露出削減、決済システムの可用性確保、クラウド設定の健全化
• スコープ定義：対象資産、期間、環境（本番／検証）、除外範囲、停止可否
• 体制と役割：実施者、承認者、連絡経路、緊急時の判断者
• 事前チェック：認証情報の準備、メンテナンス申請、バックアップ、ログ保存方針

簡易RACI（例）

フェーズ	責任（R）	承認（A）	協力（C）	連絡（I）
準備	セキュリティ担当	CISO/情報シ責任者	開発・運用	経営・関係部門
診断	セキュリティ担当/ベンダー	情報シ責任者	開発・運用	経営
改善	開発・運用	サービス責任者	セキュリティ担当	経営・監査

4-1-2. スキャン・診断（自動＋手動で事実収集）

次に、事実を網羅的に集めます。つまり、自動化で広く速く、手動で深く精度を上げます。

• 自動：ネットワーク／ホストの認証スキャン、Web/APIのDAST、クラウド設定のCSPM、コンテナ・イメージの脆弱性検査、依存関係のSCA
• 手動：権限昇格の検証、ビジネスロジックの欠陥確認、設定レビュー、IaCの実地確認
• 影響抑制：本番は低負荷設定、停止リスクのあるテストは検証環境で先行、作業時間帯の合意

4-1-3. 分析（トリアージとリスク評価）

収集した検出結果をそのまま配布しないことが重要です。なぜなら、誤検知や重複が混じると現場が動けないからです。

• 正規化：重複排除、誤検知除外、資産重要度の付与
• 優先度：CVSSなどの技術スコアに、露出度・可用性影響・データ機密性を掛け合わせてランク付け
• 判断基準の例
  • 直ちに対処：外部公開で悪用コードが存在、認証回避、特権奪取
  • 早期対処：重要データに影響、横展開の足がかり
  • 計画対処：限定領域での軽微な設定不備

4-1-4. 報告（経営と現場に伝わるレポート）

報告は「意思決定のための資料」にします。

つまり、経営には要点、現場には再現と修正手順を提示します。

• エグゼクティブサマリ：重大テーマ、影響範囲、対処の優先順位、必要予算の概算
• テクニカル詳細：再現手順、影響資産、証跡、修正案、代替策
• 計画：30・60・90日のロードマップ、担当、期限、リスク受容の根拠

4-1-5. 改善（是正・再診断・定着化）

最後は「直して終わり」にしないことが重要です。したがって、是正後の再診断と仕組み化まで行います。

• 是正：パッチ、設定変更、権限最小化、WAF・監視の強化
• 検証：再診断、回帰テスト、例外承認の期限設定
• 定着：手順の標準化、IaCテンプレート更新、MTTR・準拠率のKPI管理

フェーズ別アウトプット例

フェーズ	主な入力	活動	主な出力	KPI例
準備	目的・資産台帳	スコープ定義	診断計画書	網羅率
診断	認証情報・設定	自動＋手動診断	検出一覧	誤検知率
分析	検出一覧	トリアージ	優先度付きリスト	クリティカル件数
報告	優先度リスト	レポート化	サマリ／詳細報告	承認までのリードタイム
改善	報告・承認	是正・再診断	完了証跡	MTTR、残存リスク

---

4-2. チェックすべき診断項目・典型的な脆弱性リスト（設定ミス、バージョン未更新、アクセス制御不備など）

4-2-1. 分野別チェックリスト（要約）

分野	代表的な項目	ありがちな失敗例	初動対応の方向性
資産・外部露出	ドメイン／IP棚卸し、証明書、公開サービス	放置サブドメイン、期限切れ証明書、不要ポート開放	露出縮小、証明書更新、不要サービス停止
アイデンティティ/IAM	管理者権限、MFA、キー管理	共有アカウント、MFA未設定、長期キー放置	最小権限化、MFA必須、キーのローテーション
ネットワーク	セグメンテーション、VPN、管理ポート	任意IP許可、VPN未パッチ、22/3389の外部公開	ルール最適化、パッチ、踏み台/ゼロトラスト化
ホスト/OS	パッチ、不要サービス、監査設定	旧版OS、SMBv1有効、ログ不備	パッチ適用、サービス整理、ログ設計
Web/API	認証・認可、入力検証、セッション	認可不備、XSS/SQLi、CSRF、ID列挙	権限境界の再設計、入力検証、CSRF対策
依存関係/SCA	ライブラリ、SBOM、既知脆弱性	古い依存の放置、未知の直接/間接依存	依存アップデート、自動アラート、SBOM管理
クラウド/CSPM	公開設定、暗号化、ロール	パブリックストレージ、*.*権限、Root常用	公開制限、KMS暗号、ロール分離
コンテナ/K8s	イメージ、RBAC、シークレット	latest固定、cluster-admin乱用、平文秘密	固定タグ、RBAC最小化、Secret管理
データ保護	転送/保存暗号、バックアップ	平文保存、古いTLS、バックアップ無暗号	TLS更新、暗号化、バックアップ強化
ログ/監視	アラート、改ざん防止	ログ未収集、監視対象外、長期間未保管	収集・可視化、保管期間延長、改ざん対策

4-2-2. 高頻度で見つかる典型的な脆弱性

• 既知脆弱性の未パッチ（OS、ミドルウェア、VPN、FW）
• アクセス制御不備（認可漏れ、越権、ロールの粒度不足）
• 過剰に広いネットワーク許可（任意IP、全送信許可）
• クラウドの公開誤設定（ストレージの世界公開、管理ポート解放）
• 機密情報の露出（ハードコードされた鍵、公開リポジトリの秘密）
• 不十分な暗号設定（旧TLS、自己署名、平文通信）
• 監査ログ不足（誰が・いつ・何をが追えない）

4-2-3. 重大度の即時判断（現場向け目安）

• 即日対応：外部公開で認証回避、リモートコード実行、既に悪用事例があるもの
• 週内対応：横展開の足場（特権昇格、ダイレクトオブジェクト参照）
• 計画対応：限定的な情報露出、代替策で一時保護可能な設定不備

---

4-3. ツール・手法：自動ツール、手動レビュー、コード診断など

4-3-1. 自動ツールの主なカテゴリと得意分野

• ネットワーク/ホストスキャナ：ポート、サービス、パッチ、設定の不備を広く検知
• DAST（動的アプリ診断）：デプロイ後のWeb/APIの挙動から欠陥を発見
• SAST（静的コード解析）：コードのパターンから脆弱性候補を早期に検出
• SCA（依存関係解析）：ライブラリの既知脆弱性とバージョン管理
• IaC/クラウド設定スキャン（CSPM）：テンプレートや実環境の誤設定を自動検出
• コンテナ/イメージスキャン：ベースイメージやパッケージの既知脆弱性検知
• シークレットスキャン：鍵やトークンの混入を検出

4-3-2. 手動レビューとビジネスロジック検証

自動化だけでは見つけにくい「設計上の穴」は、人の目が有効です。

• 権限境界の破り方（水平・垂直）を具体的に試す
• 承認フローの抜け道、金額や在庫など業務ルールの不整合
• 例外系の挙動（タイムアウト、競合、レート制限）
• 設定レビュー（IAMポリシー、ネットワークACL、K8s RBAC など）

4-3-3. コード診断の実務（SAST／SCA／IaC／Secrets）

• 左シフト：プルリク時に自動実行、失敗時はマージブロック
• SBOMの生成と保存、依存の自動更新方針（週次やリリース前）
• IaCはテンプレート段階でポリシー準拠チェック、不可ならCIで失敗
• 重要リポジトリは秘密情報スキャンを常時有効化

4-3-4. 運用のコツ（連携・SLA・重複排除）

• チケット化：重大度ごとのSLA（例：高は7日以内、中は30日以内）
• 重複排除：同一資産・同一CVEは集約し、根本原因でまとめる
• メトリクス：MTTR、残存クリティカル件数、準拠率、再発率
• ワークフロー：検出 → トリアージ → チケット → 是正 → 再診断 → クローズ

4-3-5. 組み合わせモデル（導入規模別の最小セット）

• 小規模チーム：外部露出の定期棚卸し＋認証付きスキャン、SCA、簡易CSPM、手動で権限境界チェック
• 成熟組織：CI/CDにSAST・SCA・Secrets・IaCを組込み、運用側はCSPM・EDR・ログ相関、四半期ごとに網羅的な脆弱性アセスメントと主要システムの手動深掘り

結果の活用と優先順位付け

脆弱性アセスメントの価値は「見つけた」あとに最大化します。

つまり、評価結果をスコアリングし、ビジネスの文脈で優先順位を付け、関係者に伝わるレポートへ落とし込むことが重要です。

5-1. 脆弱性評価のスコアリング・重大度分類（CVSSなど）

5-1-1. CVSSの基礎と使いどころ

• CVSSは脆弱性の技術的な深刻度を数値化するための共通指標です。
• ベーススコア（例：攻撃経路、必要権限、影響の機密性・完全性・可用性）を中心に、環境スコアで自社事情を反映します。
• つまり、脆弱性アセスメントでは「まずCVSSで技術的深刻度を整列」し、その後で事業コンテキストで補正するのが実務的です。

5-1-2. 技術スコアに事業コンテキストを掛け合わせる

• 影響対象データの重要度（個人情報、決済情報、知財）
• 露出面（インターネット公開、社内限定、ゼロトラスト配下）
• 運用上の代替防御（WAF、EDR、監視強度、ネットワーク分離）
• 可用性要件（SLA、ピーク時間帯、復旧時間）
  したがって、CVSSだけでは高くない脆弱性でも、公開APIや特権アカウントに絡む場合は優先度を引き上げます。

5-1-3. 重大度分類とSLAの例（社内標準の叩き台）

重大度	目安（CVSS）	代表例	初動SLA	クローズSLA
クリティカル	9.0以上	公開資産での認証回避、RCE、悪用コード公表	即日	7日以内
高	7.0–8.9	権限昇格、重要データへの不正アクセス	3営業日	14日以内
中	4.0–6.9	情報露出、限定的XSS/設定不備	10営業日	30日以内
低	0.1–3.9	代替策ありの軽微な問題	計画内	次回サイクル

上記は脆弱性アセスメント用の例です。実際は業務影響や監査要件で微調整します。

5-1-4. スコアリング運用の落とし穴と対策

• 落とし穴：ツール出力を未整理のまま配布 → 対策：重複・誤検知のトリアージを必須化
• 落とし穴：CVSSで「高」でも実害が小さい案件に工数集中 → 対策：環境スコアとビジネス影響で補正
• 落とし穴：例外承認の積み上げ → 対策：期限付き例外と再評価日を付与

---

5-2. リスク優先順位の決め方：影響・発生可能性・対策コスト

5-2-1. リスク関数の基本

脆弱性アセスメントでは、次の関数で「並び順」を決めます。
リスク指標 ＝ 影響度 × 発生可能性 × 露出係数
ここに「対策コスト（工数・停止影響）」を加味して、早く・安く・効果が大きい順に着手します。

5-2-2. 三つの評価軸（定義の例）

• 影響度：データ種別、法的影響、SLA違反額、ブランド毀損
• 発生可能性：攻撃容易性、悪用コードの有無、観測トレンド、到達性
• 対策コスト：修正難易度、検証負荷、停止リスク、ベンダー依存
  つまり、影響と可能性が高く、対策コストが低いものが最優先です。

5-2-3. 優先度マトリクス（運用例）

発生可能性＼影響度	低	中	高
高	中	高	最高
中	低	中	高
低	低	低	中

• 「最高」は即時対応キューへ、「高」は今期完了、「中」は計画対応、「低」は受容または次回サイクル。
• したがって、脆弱性アセスメントのレポートでは、このマトリクスに案件をプロットし、意思決定を支援します。

5-2-4. 数値化の叩き台（重み付きスコア）

優先度スコア ＝ 0.5×影響度（1–5）＋ 0.3×発生可能性（1–5）＋ 0.2×露出（1–5） − 0.2×対策コスト（1–5）

• 例：公開APIの認可不備＝ 0.5×5＋0.3×4＋0.2×5 −0.2×2 ＝ 4.6（最優先）
• 例：社内限定の情報露出＝ 0.5×3＋0.3×2＋0.2×1 −0.2×3 ＝ 1.9（計画対応）

5-2-5. バックログ運用（実務のコツ）

• 重大度ごとのSLAをチケットに自動付与
• 同根原因はエピックで束ね、再発防止に投資
• バーンダウン（未解決クリティカル件数/月）とMTTRをダッシュボード化
• だから、脆弱性アセスメントの結果は「単発の一覧」ではなく「継続改善のバックログ」として管理します。

---

5-3. レポート作成のポイントとステークホルダーへの説明方法

5-3-1. 二階建て構成で「読む人」を迷わせない

• エグゼクティブサマリ：意思決定向け（5分で要点がつかめる）
• テクニカル詳細：実装・運用担当向け（再現手順と具体的対策）
  つまり、脆弱性アセスメントのレポートは目的別に二階建てにします。

5-3-2. 5枚で伝わるエグゼクティブサマリ（型）

1. 全体像：対象、期間、網羅率、主要指標
2. 主要リスク上位：三つの要点とビジネス影響
3. 改善計画：30・60・90日のロードマップと必要工数
4. コスト対効果：未対策時の想定損失と削減効果
5. 依頼事項：承認が必要な予算・停止時間・外部支援

5-3-3. テクニカル詳細の必須要素

• 検出ID、資産ID、環境（本番/検証）、発見方法（ツール/手動）
• CVSSや社内スコア、再現手順、影響範囲、証跡（ログ/スクリーン）
• 修正案（恒久・暫定）、代替策、テスト観点、依存タスク
• だから、誰が読んでも同じ手順で再現できる粒度にします。

5-3-4. ステークホルダー別に伝える観点

相手	関心事	提示すべき指標・表現	伝え方のポイント
経営層	事業影響、予算、法的リスク	売上影響、SLA違反額、重大度分布	選択肢と意思決定項目を明確化
プロダクト責任者	ロードマップへの影響	リリース影響、必要停止時間	代替策とリリース計画の両立案
開発/運用	具体的修正と検証	再現手順、テスト項目、依存関係	チケット化と期限、レビュー体制
コンプライアンス/監査	証跡と継続性	診断計画、是正証跡、例外管理	監査観点での整合性を先回り

5-3-5. よくある質問に先回りする

• なぜ今直すのか：悪用可否、公開範囲、代替防御の有無を端的に
• どれだけ止まるのか：停止時間と影響ユーザー数
• 何が最優先か：トップ3と根拠（スコア式・マトリクス）
• いつ終わるのか：SLAとバーンダウン見込み
  その結果、合意形成が速くなり、脆弱性アセスメントの効果が高まります。

5-3-6. 指標（KPI/KRI）の設計例

• KPI：未解決クリティカル件数、MTTR、パッチ準拠率、網羅率
• KRI：公開資産の無認証管理ポート数、例外承認の滞留件数
• したがって、定点観測で改善の進捗と残存リスクを両方見える化します。

5-3-7. 図表・可視化のコツ

• リスクヒートマップ（影響×可能性）
• 時系列のバーンダウン、重大度分布のパレート図
• システム別の残存リスクと対策進捗のガント風チャート
• つまり、数字を「動き」として見せることで、優先順位が腹落ちします。

運用と改善、継続性の確保

脆弱性アセスメントは一度やって終わりではありません。つまり、「定期的に回す仕組み」と「結果を運用へつなげる仕掛け」を作ってはじめて、リスクは下がり続けます。以下では、継続運用の設計と、PDCAに基づくモニタリングの実装ポイントを解説します。

6-1. 定期的／継続的アセスメントの設計と実施方法

6-1-1. 継続運用の設計原則（スケール・再現・証跡）

• スケール：自動化で「広く速く」、手動で「深く正確に」。
• 再現：スコープ・手順・閾値を文書化し、担当が変わっても同じ品質で回せるように。
• 証跡：検出・判断・是正の履歴を残し、監査・説明に耐える状態を保つ。
  したがって、脆弱性アセスメントの運用は「誰がやっても同じ結果」が出る仕組み作りが出発点です。

6-1-2. 年間カデンスとイベントドリブンの併用（例）

頻度	対象	目的	期待アウトプット
月次	外部公開資産、クラウド設定	露出のドリフト検知	差分レポート、即時是正チケット
四半期	重要システム（決済・顧客DB等）	深掘り診断＋優先度見直し	30・60・90日改善計画更新
半期	社内基幹・委託先	準拠率評価・委託先レビュー	例外棚卸し、是正要求
随時（イベント）	大規模リリース、重大CVE、M&A	リスク急変への追随	臨時アセスメント結果と暫定対策

つまり、定期とイベントの二本立てで「抜け」を最小化します。

6-1-3. 自動化の優先順位（最小構成の考え方）

• まずは外部露出（アタックサーフェス）とクラウド設定（CSPM）を常時監視。
• 次にホスト・コンテナ・依存関係（SCA/SBOM）をCI/CDへ組み込み。
• さらに重要アプリにはDAST＋手動の権限境界テストを定期実施。
  この順で自動化すると、脆弱性アセスメントのコストを抑えつつ網羅率を高められます。

6-1-4. 役割分担とRACI（叩き台）

活動	実行（R）	責任/承認（A）	協力（C）	共有（I）
スコープ策定	セキュリティ	CISO/情報シ責任者	開発/運用/事業	監査
診断実施	セキュリティ/ベンダー	情報シ責任者	開発/運用	経営
分析・優先度付け	セキュリティ	情報シ責任者	プロダクト責任者	関係部門
是正・再診断	開発/運用	サービス責任者	セキュリティ	経営/監査

だから、「誰がボールを持つか」を最初から決めておくほど、脆弱性アセスメントは回しやすくなります。

6-1-5. 例外管理とリスク受容のガードレール

• 期限付き例外（例：90日）と再評価日を必須化。
• 代替策（監視強化、WAFルール等）を条件に承認。
• ボトルネックは月次で可視化し、経営判断にエスカレーション。
  この仕組みにより、脆弱性アセスメントの「やりっぱなし」を防げます。

6-1-6. ベンダー・委託先の巻き込み

• 契約に最低限の脆弱性管理要件と報告SLAを明記。
• 年次の第三者レポートや自己評価票を収集。
• 重大インシデントの通知義務と是正期限を規定。
  その結果、サプライチェーン起点のリスクも一緒に下げられます。

---

6-2. セキュリティ態勢のモニタリングと改善サイクル（PDCA等）

6-2-1. 指標（KPI/KRI）の設計と目標値（例）

種別	指標	定義	目標値の例
KPI	未解決クリティカル件数	重大度「高以上」の残件	月次で前月比−30％
KPI	MTTR（是正平均時間）	検出からクローズまで	クリティカル7日以内
KPI	パッチ準拠率	主要OS/中間層の適用率	95％以上
KRI	公開資産の無認証管理ポート	0が望ましいリスク指標	常時0
KRI	例外承認の滞留	期限超過の件数	0を維持

つまり、脆弱性アセスメントの成否は「数字で追える」状態にしてこそ継続改善できます。

6-2-2. PDCAの具体化（脆弱性アセスメント版）

• Plan：年間カデンス、重大度SLA、役割分担、ダッシュボード定義を策定。
• Do：自動スキャン＋手動深掘り、委託先評価、臨時アセスメント。
• Check：月次レビューでKPI/KRIを確認、誤検知率や網羅率も点検。
• Act：根本原因に投資（標準化、IaCテンプレート更新、権限モデル再設計）。
  したがって、PDCAは「結果の見直し」だけでなく「仕組みの更新」まで含めます。

6-2-3. 可視化とダッシュボードの作法

• 役割別ビュー：経営向け要約、プロダクト向けバックログ、運用向けアクション。
• 図表：リスクヒートマップ、バーンダウン、重大度分布のパレート。
• 粒度：全社→事業→システムのドリルダウンを可能に。
  こうして、脆弱性アセスメントの「優先順位」が誰にでも一目で分かります。

6-2-4. 学習ループ（ポストモーテムと標準化）

• インシデントや重大CVE対応後に、原因・検知・是正のギャップを整理。
• 結果を標準手順、IaCテンプレート、セキュアコーディング規約へ反映。
• 再発防止の有効性は次サイクルで検証。
  だから、脆弱性アセスメントは「知見のリポジトリ」を育てる活動でもあります。

6-2-5. 予算・人員配分につなげる効果測定

• 「回避できた損失額 − 対策コスト」を四半期ごとに推定。
• 未解決クリティカルの削減率やMTTR短縮を投資の根拠に。
• ベンダー活用の費用対効果を指標で比較。
  その結果、脆弱性アセスメントの継続投資に社内合意が得やすくなります。

6-2-6. 成熟度モデルでの段階的ロードマップ（例）

レベル	状態	重点施策
Lv1 初期	単発のスキャン中心	年間計画と重大度SLAの策定
Lv2 反復	定期アセスメント確立	自動化の拡充、KPI/KRI導入
Lv3 定着	CI/CD連携・委託先含め運用	例外管理、根本原因への投資
Lv4 最適化	リスクベースで投資最適化	予測型指標、継続的検証（紫チーム等）