脆弱性情報の追い方と優先度付け ― JVN・NVD・CISA KEVを実務で使い分ける

情報源は役割で使い分ける

脆弱性対応が破綻する典型的な原因は、情報源を一つに絞ることだ。JVN、NVD、CISA KEV、そして製品ベンダーのアドバイザリは、更新の速さも粒度も目的も違う。網羅性を担う情報源、詳細を担う情報源、緊急度を判断する情報源を分けて購読する。

ベンダーのアドバイザリが一次情報

修正版の正確なバージョン番号、回避策、影響を受ける構成の条件を書けるのは製品ベンダーだけだ。パッチ適用の最終判断はここの記述に従う。Microsoft、Cisco、Oracle、Red Hat、利用中のOSSプロジェクトなど、自組織が実際に使っている製品分だけをRSSやメーリングリストで購読する。使っていない製品まで追うと通知が飽和し、重要な告知を見落とす。

JVNは日本語での入り口

JVN(Japan Vulnerability Notes)はJPCERT/CCとIPAが共同運営する。国内製品の脆弱性と、国内で影響の大きい海外製品の情報が日本語で公開される。過去分の検索はJVN iPedia、機械的な取得はMyJVN APIを使う。国内ベンダーのグループウェアやルーター、業務パッケージは海外データベースへの反映が遅い、あるいは載らないことがあり、JVNが実質的な一次情報になる場合がある。JVNとJPCERT/CCの注意喚起は、国内の観測状況を反映する点で海外情報源の代わりにならない。

NVDは自動照合の土台

NVD(NIST National Vulnerability Database)はCVEにCVSSスコアとCPE(製品識別子)を付与する。資産台帳と自動で突き合わせる仕組みを作るなら、CPEを持つNVDのデータが基盤になる。ただし登録や情報付与に遅延が生じることがあり、スコアやCPEが一定期間付かないCVEが存在する。「NVDに情報がない=危険ではない」と読まない運用にしておく。

CISA KEVは悪用の事実を示す

CISA KEV(Known Exploited Vulnerabilities Catalog)は、実際の攻撃での悪用が確認されたCVEだけを列挙する。米国連邦政府機関には是正期限が課されるが、民間組織にとっても優先度判断の実用的な指標になる。JSONとCSVで公開されているため、自組織のCVE一覧と突き合わせる処理を書きやすい。日次で照合する仕組みを作る価値がある情報源はこれが筆頭になる。

CVE番号とCVSSの読み方

CVE番号は識別子であって深刻度ではない

CVE-2021-44228(Log4Shell)のような番号は「採番年-連番」の識別子で、危険度の情報を一切含まない。採番はCNA(CVE Numbering Authority)と呼ばれる組織が行い、大手ベンダーの多くが自社CNAを持つ。一つの根本原因に複数のCVEが振られることも、一つのCVEが多数の製品にまたがることもある。番号は情報を名寄せするキーとして扱い、深刻度の判断材料にはしない。

CVSSは基本値だけで運用しない

CVSSは基本評価基準、脅威(現状)評価基準、環境評価基準の三群からなるが、一般に公開されるのは基本評価基準のスコアだけだ。これは「最も条件が悪い構成での理論値」であり、自組織のリスクではない。数値よりベクタ文字列を読む。AV:N(ネットワーク経由)、PR:N(権限不要)、UI:N(利用者の操作不要)が揃えば、遠隔から無条件で攻撃が成立する。逆にAV:L(ローカル)やPR:H(高権限が必要)は、スコアが高くても前提条件が重い。CVSS v4.0とv3.1は算出方法が異なり、数値をそのまま比較できない。どちらのバージョンのスコアかを確認する習慣をつける。仕様はFIRSTの公式ドキュメントが一次情報になる。

悪用可能性はEPSSとKEVで補う

EPSSは、今後30日以内にそのCVEの悪用が観測される確率を推定し、日次で更新される。整理すると、CVSSは「起きたらどれだけ悪いか」、EPSSは「悪用される見込み」、KEVは「すでに悪用されている事実」を示す。三つは別の軸で、代替関係にない。CVSSが9点台でもEPSSが極めて低いものは多く、逆に中程度のスコアでKEVに載るものもある。スコアの高い順に直す運用は、この差を無視するため効率が悪い。

資産台帳がなければ優先度は付けられない

優先度は脆弱性の性質だけでは決まらない。「自組織のどこに、どういう晒され方で存在するか」と掛け合わせて初めて決まる。台帳に最低限必要なのは、製品名とバージョン、稼働ホストと管理部署、インターネットからの到達可否、前段の認証やWAF・VPNの有無、扱うデータの機密度、停止できる時間帯である。

アプリケーションについては、依存ライブラリまで把握しないと意味がない。SBOM(ソフトウェア部品表)をビルド時に自動生成し、間接依存を含めて記録する。台帳を手作業のスプレッドシートで維持すると必ず実態とずれるため、構成管理ツールや資産管理エージェント、コンテナレジストリのスキャン結果から自動更新する経路を作る。台帳整備は脆弱性対応の前提作業であり、後回しにすると個々の脆弱性ごとに調査コストを払い続けることになる。

「すぐ直す」「計画的に直す」「様子見」の分岐

判断はCVSSの数値ではなく、攻撃者が到達できるかどうかで切る。以下は目安であり、業種や規制要件に応じて自組織の基準に置き換える。

「様子見」は放置とは違う。判断した人、根拠、再評価の期日を残す。この記録がないと、状況が変わったときに誰も気づけない。判断が属人化する場合は、CISAが公開するSSVC(Stakeholder-Specific Vulnerability Categorization)の決定木を参考に、自組織版の分岐図を一枚作っておくとよい。

報告とエスカレーションを時間で定義する

報告様式は事前に固定する。CVE番号と一文の概要、影響を受ける自社資産の一覧、外部からの到達可否、悪用状況(KEV掲載・PoC公開・EPSS値)、暫定の分類とその根拠、恒久対策と回避策、必要な停止時間、次の判断期日。この八項目が揃っていれば、責任者はその場で可否を判断できる。調査中の項目は空欄にせず「調査中・◯時までに報告」と書く。

エスカレーション基準は担当者の主観ではなく時間で決める。「すぐ直す」と判定してから既定の時間内に適用の見通しが立たなければ、自動的に責任者へ上げる。サービス停止を伴う対応は情報システム部門だけで決められないことが多いため、業務部門と経営層の連絡経路と代理者を平時に決めておく。

個人情報の漏えいやそのおそれがある場合は、個人情報保護法に基づく個人情報保護委員会への報告と本人への通知が関わる。報告期限や対象の判断は事案により異なるため、社内で結論を出す前に法務と相談し、個人情報保護委員会の公表資料で最新の要件を確認する。業界固有の届出義務がある場合は、所管官庁のガイドラインが一次情報になる。

着手するなら、この順番で

すべてを一度に整えようとすると始まらない。まず利用製品の一覧を作り、そこに載っている製品のベンダーアドバイザリだけを購読する。次にKEVを日次で取得し、製品一覧と突き合わせるスクリプトを一本書く。この二つだけで「悪用されている脆弱性が自社にある」状態の検知は成立する。CVSSやEPSSによる細かい優先度付けは、その後で精度を上げる作業だ。

運用が回っているかどうかは、脆弱性を何件処理したかではなく、「KEV掲載から自組織の判断確定までの時間」と「様子見に分類した案件の再評価が期日どおり行われた割合」で測る。この二つが悪化したら、情報源ではなく資産台帳か体制側に原因がある。