情報システム部の共有フォルダに、月次の脆弱性スキャンレポートが整然と並んでいます。重大度「緊急」の件数は3か月前から右肩下がりで、グラフだけを見ると管理はうまくいっているように見えます。ところが内部監査の担当者がネットワーク機器の保守契約一覧と突き合わせてみると、スキャン対象リストに載っていない拠点ルーターが4台見つかりました。そのうち1台は、ベンダーのサポートがすでに終了した機種でした。
これは多くの会社で起こりうる、ごくありふれた場面です（本記事の事例はすべて架空のモデルケースです）。脆弱性管理は「スキャンして、パッチを当てる」業務だと思われがちです。しかし、スキャンが見ているのは「スキャン対象として登録された資産」だけです。登録されていない資産の脆弱性は、レポートの数字にいつまでも現れません。
内部監査が脆弱性管理を見るときに問うべきなのは、「緊急の件数は減ったか」ではなく「見えていない資産はないか」「残っているリスクを誰が、どの根拠で受け入れたのか」です。この記事では、その問いを監査手続に落とし込む方法を解説します。
この記事の要点
- 脆弱性管理の監査は、スキャン結果より先に資産台帳の網羅性を確かめます。台帳から漏れた資産は、どれだけ優秀なスキャナーでも検出できません
- 優先度はCVSSの点数だけでなく、悪用の事実（CISAのKEVカタログ等）、外部公開の有無、資産の重要度を組み合わせて決めるのが国際的な流れです
- 監査の核心は「期限内の対応率」と「例外（リスク受容）の承認と期限管理」の2点です
- パッチを当てられない資産は必ず出ます。例外を禁止するより、承認者・代替策・再評価日が記録されているかを見ます
- 評価は自社のリスク許容度と監査人の判断を踏まえて行います。本記事の期限や基準は一例です
脆弱性管理とは何か：なぜ「パッチ管理」だけでは足りないのか
用語の整理
脆弱性とは、ソフトウェアや設定の弱点で、攻撃者に悪用されると情報漏えいやシステム停止につながるものを指します。公開された脆弱性には、CVE（Common Vulnerabilities and Exposures）という共通の識別番号が振られます。日本では、JPCERT/CCと情報処理推進機構（IPA）が共同で運営するJVN（Japan Vulnerability Notes）が、国内製品を含む脆弱性情報を公開しています。
脆弱性管理は、資産を把握し、脆弱性を発見し、優先度をつけ、修正または緩和し、その結果を確認する一連のプロセスです。パッチ管理はその中の「修正」を担う部分にすぎません。米国国立標準技術研究所（NIST）のSP 800-40 Rev.4「Guide to Enterprise Patch Management Planning」（2022年4月）は、パッチ適用を技術の「予防保全」と位置づけ、組織のリーダーと事業部門、IT部門が一緒に全社的な戦略を作るべきだとしています。
パッチの話が「経営の話」になった理由
SP 800-40が2013年のRev.3から大きく書き直された背景には、パッチを個々の技術作業として扱っていては追いつかないという認識があります。ソフトウェアの数が増え、クラウドやSaaS、個人の端末まで管理対象が広がった結果、すべてを即日修正することは現実的でなくなりました。どれを急ぎ、どれを待ち、どれを受け入れるかは、事業への影響を踏まえた判断、つまり経営判断になります。
内部監査が関与する意味はここにあります。IT部門だけで完結している限り、「当てられないパッチ」のリスクは現場の判断で静かに積み上がります。内部監査は、その判断が組織として承認されたルールに沿っているかを確かめる役割を担います。
基準・フレームワークでの位置づけ
主要なフレームワークは、いずれも脆弱性管理を独立した管理項目として扱っています。監査の評価基準を設定するときの拠り所として押さえておきましょう。
| フレームワーク | 該当箇所 | 監査での使いどころ |
|---|---|---|
| NIST CSF 2.0 | ID.AM（資産管理）、ID.RA-01（資産の脆弱性の識別・検証・記録）、PR.PS（プラットフォームセキュリティ） | 資産把握から修正までの一貫性を見る枠組み |
| ISO/IEC 27001:2022 附属書A | 5.9（情報及びその他の関連資産の目録）、8.8（技術的ぜい弱性の管理） | ISMS認証取得企業では既存の規程・記録を活用できる |
| NIST SP 800-40 Rev.4 | 全社的なパッチ管理計画、リスク対応の選択肢 | 例外・緩和策・リスク受容の考え方 |
| 経済産業省・IPA「サイバーセキュリティ経営ガイドライン」 | 経営者が指示すべき重要項目 | 経営層への報告・資源配分の妥当性 |
NIST CSF 2.0を使った監査全体の組み立てはサイバーセキュリティ監査の進め方で、ISMSの内部監査との関係はISO/IEC 27001とISMS内部監査で解説しています。
監査の出発点は資産台帳：見えない資産は守れない
なぜ台帳の網羅性が最重要なのか
脆弱性スキャナーは、指定されたIPアドレスの範囲やエージェントを導入した端末を調べます。裏を返すと、範囲外のネットワークセグメント、エージェントが入っていない端末、IT部門が把握していないクラウド環境は、最初から検査の外にあります。スキャン結果の「緊急ゼロ」は、「検査した範囲に緊急がない」という意味でしかありません。
NIST CSF 2.0が資産管理（ID.AM）を識別機能の最初に置き、そのうえでID.RA-01として資産の脆弱性の識別を求めているのは、この順序に意味があるからです。監査の手続も同じ順序で組み立てます。
網羅性を確かめる突合の手続
台帳の網羅性は、台帳の中身を眺めても確かめられません。台帳とは独立した情報源と突き合わせ、「台帳にないもの」を探すのが基本です。
| 突合する情報源 | 見つかりやすい漏れ | 手続の例 |
|---|---|---|
| 固定資産台帳・リース契約一覧 | 拠点のサーバー、ネットワーク機器 | 資産番号で照合し、台帳未登録の機器を抽出 |
| 保守契約・ライセンス一覧 | 業務部門が独自に導入した製品 | 契約先製品名と台帳のソフトウェア一覧を照合 |
| クラウドの請求明細・アカウント一覧 | 部門が個別契約したクラウド環境 | 請求元アカウントIDとスキャン対象を照合 |
| ネットワーク機器のARP・DHCP記録 | 未登録端末、検証用機器 | 一定期間に通信した機器のMACアドレスと台帳を照合 |
| 外部公開IPアドレス・DNSレコード | 公開サーバー、キャンペーン用サイト | 自社ドメインのサブドメインと公開資産一覧を照合 |
特に見落とされやすいのが外部公開資産です。キャンペーンサイトや検証環境が役目を終えた後も放置され、更新されないまま公開され続けることがあります。攻撃者が最初に探すのはこうした資産です。
ソフトウェア部品の把握（SBOM）
近年は、機器単位だけでなく、ソフトウェアに組み込まれた部品（オープンソースのライブラリ等）の把握も求められています。経済産業省は「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引」を公表しており、2024年8月のver2.0では脆弱性管理プロセスの具体化が加えられました。
内部監査の段階としては、自社開発システムについて「使用しているライブラリの一覧が取れるか」「新しい脆弱性が公表されたとき、影響するシステムをどのくらいの時間で特定できるか」を質問するところから始めるのが現実的です。
優先度の決め方を評価する：CVSSだけで並べていないか
CVSSは「深刻度」であって「危険度」ではない
CVSS（Common Vulnerability Scoring System）は、FIRSTが管理する脆弱性の深刻度の評価方法です。2023年11月にv4.0が公開され、基本評価（Base）、脅威（Threat）、環境（Environmental）、補足（Supplemental）の4つの指標群に整理されました。多くの組織では、ベンダーやデータベースが公表する基本評価の点数をそのまま優先度に使っています。
しかし基本評価は、脆弱性そのものの技術的な性質を示すもので、自社の環境で実際にどれだけ危ないかは示しません。インターネットから到達できない閉じたネットワーク上の「緊急」と、外部公開サーバー上の「重要」では、後者のほうが急ぐべき場合があります。CVSS自体も、脅威や環境の指標で調整することを想定しています。
「悪用されているか」を加える流れ
もう一つの軸が、実際に悪用が確認されているかどうかです。米国のCISA（サイバーセキュリティ・インフラストラクチャセキュリティ庁）は、悪用が確認された脆弱性をKEV（Known Exploited Vulnerabilities）カタログとして公開しています。CISAは2026年6月、連邦政府機関向けの拘束的運用指令BOD 26-04を出し、KEVカタログや外部公開の有無などを組み合わせたリスクベースの対応期限を示しました（従来のBOD 22-01等を置き換えるもの。詳細は公式で確認してください）。
また、FIRSTが提供するEPSS（Exploit Prediction Scoring System）は、公開された脆弱性が今後30日以内に悪用される確率を推定する指標です。日本企業に米国の指令が適用されるわけではありませんが、「深刻度×悪用の事実×露出度×資産の重要度」で優先度を決める考え方は、自社のルールを評価する際の参考になります。
優先度・対応期限ルールの記入例
以下は、社内規程で定める優先度と対応期限の一例（架空のモデルケース）です。期限の長さは業種やシステム構成で大きく変わるため、数値そのものより「判断軸が明文化されているか」を監査で確かめます。
| 優先度 | 判定条件（いずれかに該当） | 対応期限の例 | 期限超過時の扱い |
|---|---|---|---|
| P1 | KEV掲載または悪用報道あり、かつ外部公開資産 | 7日以内（緩和策は24時間以内） | CISO承認の例外申請が必須 |
| P2 | CVSS基本値9.0以上、または重要資産上のKEV掲載 | 14日以内 | 部門長承認の例外申請 |
| P3 | CVSS基本値7.0以上 | 30日以内 | 部門長承認の例外申請 |
| P4 | 上記以外 | 次回の定期保守時 | 四半期ごとに一覧で報告 |
監査でよく見つかるのは、規程上は期限があるのに、「期限をいつから数えるか」が決まっていないケースです。ベンダーの公表日なのか、スキャンで検出した日なのか、チケットを起票した日なのかで、実際の対応日数は数週間変わります。起算点の定義は必ず確認しましょう。
パッチ適用の運用状況をテストする
監査手続の組み立て
整備状況（ルールが適切に作られているか）を確かめたら、運用状況（ルールどおりに動いているか）をテストします。脆弱性管理はデータが豊富な領域なので、サンプルに頼らず全件分析ができる場合も多くあります。
| # | 監査手続 | 入手する資料 | 確かめること |
|---|---|---|---|
| 1 | スキャン対象と資産台帳の照合 | スキャン対象一覧、資産台帳 | 台帳の資産がすべてスキャン対象か、除外に理由があるか |
| 2 | スキャン実施状況の確認 | スキャン実行ログ | 規程の頻度どおりに実施され、失敗したスキャンが再実行されているか |
| 3 | 検出から対応までの日数分析 | 脆弱性管理ツールのエクスポート | 優先度別の期限内対応率、期限超過の分布 |
| 4 | 修正後の検証 | 再スキャン結果、変更記録 | 「対応済み」とされた脆弱性が再スキャンで消えているか |
| 5 | 変更管理との整合 | 変更申請・承認記録 | パッチ適用が承認済みの変更として実施されたか |
| 6 | 経営報告の確認 | 会議資料・議事録 | 期限超過や例外の状況が経営層に報告されているか |
手続4は見落とされがちですが重要です。チケットが「完了」になっていても、再起動が行われずパッチが有効になっていない、あるいは一部のサーバーだけに適用されていた、ということがあります。修正の記録ではなく、再スキャンで「消えたこと」を証拠にします。
期限内対応率の見方
期限内対応率は、監査でよく使う指標です。ただし、平均値だけを見ると問題が隠れます。たとえば、全体の対応率が95%でも、残り5%がすべて外部公開サーバーのP1であれば、リスクは深刻です。優先度別・資産区分別に分けて集計し、長期未対応の上位を個別に確認します。
また、スキャン設定の変更で検出件数が急に減っていないかも確かめます。検出ルールの除外設定が広すぎると、数字は改善したように見えても、実態は変わっていません。除外設定の一覧とその承認記録は、例外管理と同じ厳しさで確認すべき資料です。
変更管理との接点
パッチ適用は本番環境への変更です。緊急パッチを理由に変更管理の手続を省略していると、別の障害や不正な変更の温床になります。緊急変更の事後承認がきちんと行われているかは、変更管理の監査手順の観点とあわせて確認します。バックアップや障害対応の体制はIT運用管理の監査も参考にしてください。
例外管理とリスク受容：当てられないパッチをどう扱うか
例外は「なくす」ものではない
製造装置を制御する端末、ベンダーの動作保証が古いOSに限られる業務システム、サポート終了後の移行が間に合わない機器など、すぐにはパッチを当てられない資産は、どの会社にも存在します。SP 800-40 Rev.4も、パッチ適用以外のリスク対応として、緩和策の導入や、リスクの受容、資産の隔離・廃棄といった選択肢があることを示しています。
監査で問題にすべきなのは、例外の存在そのものではありません。例外が「誰の判断で」「どの代替策を前提に」「いつまで」認められているかが記録され、期限が来たら再評価されているかです。記録のない例外は、実質的には「放置」と区別がつきません。
例外申請書の記入例
以下は例外（リスク受容）申請の記入例です（架空のモデルケース）。この項目がそろっているかを、監査のチェックリストとしても使えます。
| 項目 | 記入例 |
|---|---|
| 対象資産 | 第2工場 ライン制御端末 PC-F2-07（資産番号 F2-0342） |
| 対象の脆弱性 | OSの既知脆弱性（CVE番号を列挙、優先度P2） |
| 適用できない理由 | 装置ベンダーの動作保証が現行OSバージョンに限定されるため |
| 代替策（緩和策） | 工場ネットワークを業務ネットワークから分離、USBポートを無効化、通信を許可リスト方式に制限 |
| 残存リスクの評価 | 外部からの到達経路はないが、保守作業時の持込媒体経由のリスクが残る |
| 承認者 | 製造本部長、情報セキュリティ責任者 |
| 有効期限・再評価日 | 2027年3月末（装置更新計画の確定時に再評価） |
| 恒久対策 | 2027年度設備更新計画で後継機に置換 |
例外管理の監査チェックリスト
- 例外の承認権限が規程で定められ、リスクの大きさに応じて承認者が上がる仕組みになっている
- すべての期限超過脆弱性に、対応中のチケットか承認済みの例外のどちらかが紐づいている
- 例外に有効期限があり、期限切れの例外が一覧で把握されている
- 代替策が実際に設定されていることを、設定画面やネットワーク構成図で確かめている
- 例外の件数と内容が、少なくとも年に一度は経営層に報告されている
- サポート終了製品の一覧と、置換計画・予算が紐づいている
代替策の確認は特に重要です。申請書に「ネットワーク分離」と書かれていても、実際にはファイアウォールのルールに業務ネットワークからの通信を許す設定が残っている、ということはよくあります。書類と設定の両方を見ることで、例外管理の実効性を評価できます。
クラウド・委託先・SaaSでの確認ポイント
責任分界によって見るものが変わる
クラウドサービスでは、どこまでを利用者が管理し、どこからを事業者が管理するかという責任分界が、脆弱性管理の範囲を決めます。仮想サーバーを借りる形態（IaaS）ではOSのパッチは利用者の責任になることが一般的ですが、SaaSではアプリケーションの修正は事業者の責任です。
監査では、利用しているクラウドサービスごとに責任分界を一覧にし、利用者側の責任範囲がスキャン対象や運用ルールに含まれているかを確かめます。コンテナのイメージや仮想マシンのテンプレートも、古い部品を含んだまま複製され続けるリスクがあるため、更新ルールを確認します。
委託先・SaaS事業者の評価
事業者側の責任範囲は、自社では直接テストできません。SOC2報告書などの第三者保証報告書で脆弱性管理に関する統制と例外事項を確認し、報告書の対象外となる部分（相補的な利用者統制）を自社が実施しているかを確かめます。SOC報告書の読み方はITGCとクラウド時代の評価ポイントで解説しています。
また、委託先で重大な脆弱性が見つかったときに、自社へ通知される契約上の取り決めがあるかも確認しておきたい点です。通知の仕組みがなければ、インシデントが起きてから初めて知ることになります。
よくある失敗と対策
失敗1：スキャン結果だけで「有効」と結論する
スキャンレポートの件数推移だけを見て評価を終えると、台帳の漏れや除外設定の問題を見逃します。対策は、独立した情報源との突合で網羅性を先に確かめることです。監査手続の順序を「資産→スキャン→対応→検証」に固定しておくと、この失敗を防げます。
失敗2：期限の起算点を確認していない
「重要度高は30日以内」という規程があっても、起算点が曖昧なら期限内対応率の数字は操作できてしまいます。起算点、期限延長の条件、延長の承認者を規程で確認し、ツールの設定と一致しているかも確かめます。
失敗3：例外申請の「中身」を見ていない
例外の件数や承認印の有無だけを確認し、代替策が実在するかを見ないケースがあります。例外は残存リスクを組織が引き受ける判断なので、前提となる代替策が機能していなければ判断そのものが崩れます。少数でもよいので、代替策の設定を実地に確かめましょう。
失敗4：技術的な指摘に終始する
「サーバーXにパッチ未適用」という個別の指摘を並べても、IT部門の作業リストが増えるだけで、根本原因は解決しません。台帳の更新責任が決まっていない、事業部門が導入したシステムが管理の外にある、といった仕組みの問題として報告すると、経営層が資源配分を判断しやすくなります。
よくある質問
内部監査部門に技術の専門家がいなくても監査できますか？
できます。資産台帳の網羅性、優先度ルールの明文化、期限内対応率、例外の承認と期限管理は、いずれも記録と突合で確かめられる項目です。脆弱性の技術的な内容の評価や診断が必要な場合は、外部の専門家やIT部門以外のセキュリティ担当の協力を得る方法があります。
ペネトレーションテストと脆弱性スキャンの違いは何ですか？
脆弱性スキャンは、既知の脆弱性をツールで網羅的に検出する作業です。ペネトレーションテスト（侵入テスト）は、専門家が攻撃者の視点で実際に侵入を試み、複数の弱点の組み合わせで何ができるかを確かめます。前者は日常の管理、後者は管理の有効性を定期的に検証する手段と位置づけるとよいでしょう。
パッチ適用の期限は何日にすべきですか？
一律の正解はありません。悪用の事実、外部公開の有無、資産の重要度によって期限を分け、事業への影響や検証の手間も踏まえて自社で決めるものです。監査としては、期限の妥当性を検討した記録があるか、実績が期限を大きく超えていないかを確認します。
J-SOXのIT全般統制と脆弱性管理はどう関係しますか？
財務報告に関係するシステムのパッチ適用は、本番環境への変更として変更管理の対象になることが一般的です。また、脆弱性が放置されると不正アクセスによってデータやプログラムが改ざんされるリスクがあり、アクセス管理の前提にも影響します。どこまでを評価範囲とするかは、監査人と協議して決めます。
まとめ
脆弱性管理の監査は、スキャン結果の数字から始めるのではなく、「見えていない資産はないか」を問うところから始まります。そのうえで、優先度の判断軸と期限の起算点が明文化されているか、期限内に対応され再スキャンで消えたことが確認されているか、当てられないパッチの例外が承認・代替策・期限とともに管理されているかを順に確かめます。
次の一歩として、スキャン対象一覧と資産台帳、クラウドの請求明細の3つを並べて、差分を洗い出すところから着手してみてください。アクセス権の観点はアクセス管理の監査手順、インシデント発生時の体制はインシデント対応態勢の監査もあわせてご覧ください。
脆弱性管理やサイバーセキュリティ監査の進め方についてのご相談は、お問い合わせからお寄せください。
参考資料
- NIST SP 800-40 Rev.4「Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology」（2022年4月） https://csrc.nist.gov/pubs/sp/800/40/r4/final
- NIST「The NIST Cybersecurity Framework (CSF) 2.0」（NIST CSWP 29, 2024年2月） https://www.nist.gov/cyberframework
- ISO/IEC 27001:2022「Information security, cybersecurity and privacy protection — Information security management systems — Requirements」
- CISA「Known Exploited Vulnerabilities Catalog」 https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- CISA「BOD 26-04: Prioritizing Security Updates Based on Risk」 https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk
- FIRST「Common Vulnerability Scoring System v4.0」 https://www.first.org/cvss/
- FIRST「Exploit Prediction Scoring System (EPSS)」 https://www.first.org/epss/
- JVN（Japan Vulnerability Notes） https://jvn.jp/
- 経済産業省「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引ver2.0」（2024年8月）
- 経済産業省・独立行政法人情報処理推進機構「サイバーセキュリティ経営ガイドライン Ver 3.0」
