SCS評価制度の脆弱性管理要件：パッチ適用ポリシー・CVSSスコア活用・JVN/NVDの実務活用

1. SCS評価制度で脆弱性管理が重視される背景

SCS評価制度（経済産業省主導・IPA運用、2026年度末ごろ開始予定）において、脆弱性管理は基本的かつ重要な要件の一つです。その理由は明確です。既知の脆弱性（CVE番号が割り当てられ、パッチが公開されているもの）を放置した結果、サイバー攻撃の侵入口となるケースが国内外で後を絶たないからです。

JPCERT/CCが公表するインシデント分析レポートでも、「既知の脆弱性を悪用した攻撃」が侵入経路の大きな割合を占めていることが繰り返し指摘されています。CISAのKEV（Known Exploited Vulnerabilities）カタログに掲載される脆弱性の多くは、パッチが公開されてから数週間〜数ヶ月後に実際の攻撃に使用されています。

サプライチェーンの弱点として「パッチ未適用の古いソフトウェアを使い続けている中小サプライヤー」が攻撃の踏み台になることを防ぐために、SCS評価制度は脆弱性管理を中核的な要件として位置づけています。

2. ★3/★4の脆弱性管理要件（必須・推奨の違い）

SCS評価制度の脆弱性管理要件は、★3と★4で求められる内容・深さが大きく異なります。★3は「基本的なパッチ適用管理」、★4は「体系的な脆弱性管理プログラムの確立」が求められます。

★3（基本）の脆弱性管理要件

★3では、日常的なセキュリティ更新（パッチ適用）の実施が主要要件となります。具体的な要求事項の概要として以下が含まれます。

• OSの定期的なセキュリティアップデート：Windows・macOS・Linuxなど使用OSのセキュリティパッチを定期的に適用する仕組みを持つこと。自動更新の設定または月次の手動適用ルールの整備。
• ソフトウェアのアップデート：ブラウザ・オフィスソフト・業務アプリケーションのアップデートを定期的に実施。
• ネットワーク機器のファームウェア更新：ルーター・スイッチ・VPN機器等のファームウェアを最新に保つこと。
• アップデート記録の保持：パッチ適用の実施記録（いつ、何を、どのバージョンに更新したか）を保管すること。
• 緊急パッチの対応手順：Critical/High評価の脆弱性に対する緊急対応手順を文書化すること。

★4（標準）の追加要件

★4では、★3の要件に加え、より組織的・体系的な脆弱性管理プログラムが求められます。

• 脆弱性スキャンの定期実施：エンドポイント・サーバー・ネットワーク機器に対する定期的な脆弱性スキャン（推奨：四半期ごと以上）の実施とその記録。
• リスクベースの優先順位付け：CVSSスコア・悪用可能性・自社環境への影響度を組み合わせた優先順位付けプロセスの確立。
• 脆弱性追跡・是正確認：検出された脆弱性をトラッキングし、対応完了（パッチ適用またはリスク受容の記録）を確認するプロセス。
• 例外処理プロセス：業務上の理由でパッチ適用が困難な場合の代替措置（ネットワーク分離・アクセス制限等）と記録管理。
• EOL管理：サポート終了ソフトウェア・ハードウェアの一覧管理と移行計画の策定・実施。
• KEVカタログの参照：CISAのKEVカタログを定期的に参照し、自社環境に影響する悪用済み脆弱性を優先的に対処するプロセス。

3. CVSSスコアによる優先順位付け（Critical/High/Medium/Low）

CVSS（Common Vulnerability Scoring System）は、脆弱性の深刻度を0〜10のスコアで表すシステムです。CVSS v3.1が現在も広く使用されており（CVSS v4.0は2023年10月に公表）、SCS評価制度においてもパッチ適用の優先順位付けの基準として参照されます。

CVSS v3.1 スコア区分表

重要な注意点：上記のパッチ適用期限の目安は一般的なガイドラインです。業種・組織の規模・システムの重要度によって異なります。また、CVSSスコアだけを基準にすることには限界があります。スコアが比較的低くても、実際に攻撃コードが広く出回っている（PoC公開・KEVカタログ掲載）場合は、優先度を高める必要があります。

CVSSスコアだけでなく悪用可能性も考慮する

脆弱性の優先対応を判断する際には、CVSSスコアに加えて以下の要素も考慮することが推奨されます。

• KEVカタログ掲載：CISAのKEVカタログに掲載されている脆弱性は、実際に攻撃に悪用されていることが確認済みです。CVSSスコアが中程度でもKEV掲載のものは優先対応が必要です。
• PoC（Proof of Concept）コードの公開：攻撃コードが公開されると、攻撃難易度が大きく下がります。PoC公開後の対応は迅速さが求められます。
• 自社環境への影響：自社で実際に使用しているソフトウェア・バージョンに影響するかどうか。使用していない製品の脆弱性より使用中の製品の脆弱性を優先。
• インターネット公開資産への影響：インターネットに直接公開されているシステム（VPN機器・Webサーバー・メールサーバー等）の脆弱性は、内部システムより優先度が高い。

4. JVN・NVD・CISA KEVカタログの実務活用

脆弱性情報を効率的に収集・管理するために、主要な脆弱性データベースを定期的に確認することが重要です。それぞれの特徴と実務での活用方法を解説します。

JVN（Japan Vulnerability Notes）

JVN（https://jvn.jp/）は、IPA・JPCERT/CCが共同で運営する日本の脆弱性情報データベースです。

• 特徴：日本語での情報提供。国内ソフトウェアの脆弱性も掲載。対応情報・ベンダー情報へのリンクが充実。
• 実務活用：JVN#XXXXXXXX形式の識別番号が付与された脆弱性情報を確認。特に国産ソフトウェア・業務システムに関する脆弱性は、英語資料の前にJVNで確認できることが多い。
• RSS・メール通知：JVNのRSSフィードを購読することで、新規脆弱性情報を自動取得できる。重要な通知はJPCERT/CCのメーリングリストへの登録も有効。
• 活用頻度：週1回以上、JVNの新着情報を確認することを推奨。

NVD（National Vulnerability Database）

NVD（https://nvd.nist.gov/）は、NIST（米国立標準技術研究所）が管理する脆弱性データベースです。

• 特徴：CVE全件のCVSS v3.1/v4.0スコアと詳細情報を英語で提供。CPE（Common Platform Enumeration）による製品・バージョン検索が可能。
• 実務活用：使用中のソフトウェア・バージョンに対するCVEを検索し、CVSSスコア・対応バージョン・参考URLを確認。パッチ適用の優先順位付けの基礎データとして活用。
• API活用：NVD APIを利用することで、特定製品の脆弱性情報を自動取得・台帳管理に組み込める。

CISA KEV（Known Exploited Vulnerabilities）カタログ

CISAのKEVカタログ（https://www.cisa.gov/known-exploited-vulnerabilities-catalog）は、実際にサイバー攻撃で悪用が確認された脆弱性のリストです。

• 特徴：CVSSスコアに関わらず「実際に攻撃に使われている」脆弱性のみをリスト化。米国政府機関には一定期間内でのパッチ適用が義務付けられている。
• 実務活用：自社で使用しているソフトウェアがKEVカタログに掲載されているかを定期確認（週1回推奨）。KEV掲載のものはCVSSスコアに関わらず最優先で対応。
• JSON/CSV形式での取得：KEVカタログはJSON・CSV形式でダウンロード可能。社内の脆弱性管理台帳と照合する仕組みを整備できる。

5. パッチ適用ポリシーの策定ポイント

SCS評価制度では、場当たり的なパッチ適用ではなく、組織的なポリシーに基づいた体系的な管理が求められます。パッチ適用ポリシーに含めるべき主要な構成要素を解説します。

パッチ適用ポリシーの主要構成要素

1. 対象範囲と責任分担

• 対象となる資産（OS・業務アプリ・ブラウザ・ネットワーク機器等）を明確化
• パッチ適用の実施責任者と承認者を指定
• クラウドサービス（SaaS・PaaS）は責任分界点を明確化（プロバイダー側の更新と自社対応の切り分け）

2. CVSSスコアに基づく対応期限

• Critical（9.0-10.0）：72時間〜1週間以内に対応（業務システムへの影響を考慮した緊急対応手順を定める）
• High（7.0-8.9）：1週間以内（遅くとも1ヶ月以内）に対応
• Medium（4.0-6.9）：次回の定期パッチサイクル（月次）で対応
• Low（0.1-3.9）：四半期ごとの定期対応サイクルで計画的に対応
• KEVカタログ掲載：スコアに関わらず最優先対応（72時間〜1週間以内目標）

上記の期限はあくまで目安です。自社の業種・システムの重要度・リスク許容度に合わせて設定し、経営者の承認を得た上で文書化することが重要です。

3. テスト・検証手順

• 重要システムへのパッチ適用前に、テスト環境での動作確認を実施するプロセスを定める
• パッチ適用後の動作確認項目を事前に定義
• テスト環境がない場合の代替手順（段階的展開・ロールバック手順）を文書化

4. 例外処理プロセス

業務上の理由でパッチ適用が困難な場合の対処方法を定める。

• 例外申請フォームと承認プロセス（誰が承認するか）の整備
• パッチ適用できない期間の代替措置（ネットワーク分離・アクセス制限・監視強化）
• 例外の有効期限と再評価サイクル（6ヶ月以内に再評価等）
• 例外承認記録の保管（評価審査時の証跡として）

5. 緊急対応手順

• Critical脆弱性が公開された際の緊急対応フロー（検知→評価→承認→適用→確認）
• 緊急時の連絡体制（夜間・休日の対応も含む）
• 緊急対応時のバックアップ・ロールバック手順

6. 記録・報告

• パッチ適用記録（対象資産・CVE/脆弱性番号・適用前バージョン・適用後バージョン・適用日時・担当者）の保管
• 未適用の脆弱性リストと対応期限の管理
• 月次・四半期ごとの対応状況を経営層へ報告するプロセス

6. EOL（サポート終了）ソフトウェアの管理と代替計画

EOL（End of Life：サポート終了）ソフトウェアは、セキュリティ上の最大リスクの一つです。EOL後はベンダーからのセキュリティパッチが提供されなくなるため、新たに発見された脆弱性が永続的に残り続ける状態になります。SCS評価制度では特に★4でEOL管理が要件に含まれます。

EOL管理台帳の作成（Excelによる管理例）

まず自社で使用しているソフトウェア・OSのEOLを一元管理する台帳を作成します。

EOL対応の優先順位

• 最優先：インターネットに公開されているシステム・サーバーのEOLソフトウェア（Webサーバー・VPN機器・メールサーバーのOS等）
• 優先：重要業務データを扱うシステムのEOLソフトウェア（基幹業務システム・データベース等）
• 通常：内部ネットワーク限定・非重要システムのEOLソフトウェア

EOL期間中の暫定対策

移行計画を策定していても、業務上の理由でEOL後のソフトウェアを短期間使い続ける必要がある場合があります。その場合、以下の暫定対策を実施し、記録・承認を残すことが重要です。

• EOLシステムをネットワーク的に分離（インターネット直接接続の遮断）
• EOLシステムへのアクセスを必要最小限のユーザーに限定
• EOLシステムのログ監視を強化
• 仮想パッチ（WAF・IPS等）による脆弱性の緩和
• 移行完了期限と責任者の明確化・経営者承認の取得

7. 脆弱性スキャナの活用（概要）

★4の脆弱性管理要件を満たすためには、定期的な脆弱性スキャンの実施が求められます。脆弱性スキャナは、社内システム・エンドポイント・ネットワーク機器に存在する既知の脆弱性を自動的に検出するツールです。

脆弱性スキャンの主な種類

• エンドポイント脆弱性スキャン：PCやサーバーにインストールされているソフトウェアのバージョンをチェックし、既知の脆弱性（CVE）との照合を行うもの。エージェント型（端末にソフトをインストール）とエージェントレス型がある。
• ネットワーク脆弱性スキャン：ネットワークに接続された機器のオープンポート・サービスをスキャンし、脆弱性を検出するもの。内部ネットワークと外部公開サービスの両方に対して実施することが推奨される。
• Webアプリケーション脆弱性スキャン：公開Webサイト・Webアプリケーションの脆弱性（SQLインジェクション・XSS等）を検出するもの。

特定の脆弱性スキャナ製品を推薦することは本記事の目的ではありませんが、商用・オープンソースを問わず多くのツールが存在します。選定の際は、SCS評価制度の要件への適合性・管理コスト・レポート機能・日本語サポートの有無を考慮することを推奨します。

8. UPAS ZTAによるIT資産可視化と脆弱性管理の統合

脆弱性管理の前提となるのは、「どのIT資産が存在し、何のソフトウェアが動いているか」という正確なIT資産の可視化です。手動でのExcel管理では、資産の変化（新規PCの追加・ソフトウェアのインストール・シャドーITの発生）を追跡するのに限界があります。

UPAS ZTAによるIT資産自動検出

Net PeaceのUPAS ZTAは、ネットワークに接続されたIT資産を自動検出・一元管理する機能を持ちます。SCS評価制度の脆弱性管理要件への対応において、以下の形で活用できます。

• IT資産の自動検出・台帳化：ネットワーク上のデバイス・ソフトウェア・バージョン情報を自動収集し、資産台帳を常に最新の状態に保ちます。手動管理と比較して、未把握のデバイス（シャドーIT）の検出が容易になります。
• EOLデバイス・ソフトウェアの自動検知：サポート終了が近い・既に終了しているデバイス・ソフトウェアを自動的に特定し、アラートを生成します。EOL管理台帳の継続的な更新に必要な工数を大幅に削減できます。
• 未認証デバイスの検出：IT管理部門が把握していない未登録デバイスの接続を検知し、不正接続リスクを低減します。
• SCS評価の証跡管理：資産管理の記録・更新履歴を自動保管するため、SCS評価審査時の証跡として活用できます。

9. よくある質問（FAQ）

Q1. ★3対応でCVSSスコアをどこで確認すればいいですか？

CVSSスコアは、JVN（https://jvn.jp/）またはNVD（https://nvd.nist.gov/）で確認できます。CVE番号で検索するとスコアと詳細情報が表示されます。JVNは日本語情報が充実しているため、まずJVNで確認し、詳細な技術情報が必要な場合にNVDを参照する流れが実務的です。

Q2. 自動更新（Windows Update）を有効にしておけば★3の脆弱性管理要件を満たせますか？

Windows Updateの自動更新は★3対応の重要な基盤ですが、それだけでは不十分な場合があります。Windowsが自動更新されても、業務アプリ・ブラウザ・Java・ネットワーク機器のファームウェアは別途対応が必要です。また、更新適用の記録（いつ更新されたか）を保持するプロセスの整備も必要です。

Q3. KEVカタログは日本の中小企業にも関係ありますか？

はい、関係があります。KEVカタログに掲載される脆弱性は米国の脅威情報が中心ですが、記載されている製品（VPN機器・Windows・Adobe・Exchange等）は日本の中小企業でも広く使われています。KEVに掲載された脆弱性を持つ製品は「世界中で実際に攻撃に使われている」ことを意味するため、優先対応の基準として非常に実用的です。

Q4. パッチを当てると業務システムが動かなくなる恐れがある場合はどうすればよいですか？

このリスクは多くの現場で直面する現実的な課題です。対応として、（1）テスト環境での事前検証、（2）段階的展開（一部の端末で先行適用して動作確認後に全展開）、（3）パッチ適用前の完全バックアップ取得、（4）ロールバック手順の事前準備、（5）業務への影響が低い時間帯（深夜・休日）での適用、が有効です。パッチを「今すぐ適用できない」と判断した場合は、例外処理プロセスを通じて記録・承認・代替措置の実施が必要です。

Q5. 脆弱性管理はどれくらいの頻度で実施する必要がありますか？

★3では「定期的な」脆弱性管理が求められます。最低でも月次でのパッチ適用確認と記録、週次でのJVN・KEVカタログ確認が実務的な基準です。★4ではこれに加え、四半期ごと以上の頻度での脆弱性スキャン実施が推奨されます。Critical脆弱性については月次サイクルを待たず、発見後72時間〜1週間以内の対応が目標です。

10. まとめ

SCS評価制度における脆弱性管理要件の要点をまとめます。

• ★3の脆弱性管理：OSとソフトウェアの定期的なアップデート・パッチ適用・記録保持が基本要件。
• ★4の脆弱性管理：定期的な脆弱性スキャン・CVSSスコアに基づく優先順位付け・KEVカタログ参照・EOL管理・例外処理プロセスが必要。
• CVSS v3.1スコア区分：Critical（9.0-10.0）→72時間〜1週間、High（7.0-8.9）→1週間〜1ヶ月、Medium（4.0-6.9）→1ヶ月、Low（0.1-3.9）→四半期。
• 脆弱性情報源：JVN（日本語）・NVD（英語詳細）・CISA KEVカタログ（実際の悪用リスト）を週次で確認。
• パッチ適用ポリシー：対応期限・例外処理・緊急対応手順・記録管理を含む文書ポリシーを策定。
• EOL管理：使用中ソフトウェアのEOL台帳を整備し、移行計画を立案・実施。
• IT資産の可視化：UPAS ZTA等のツールで資産管理を自動化することで、脆弱性管理の効率と精度を向上。

脆弱性管理は「一度やったら終わり」ではなく、継続的に運用するプロセスです。SCS評価制度の取得・維持に向けて、今からパッチ適用ポリシーの策定と脆弱性情報の定期収集フローを整備することをお勧めします。最新のSCS評価制度情報はIPA公式ページでご確認ください。