共通脆弱性識別子（CVE）とは何か？
午前3時に脆弱性を発見した場合でも、CVE識別子があれば、セキュリティツール、ベンダーのアドバイザリ、脅威インテリジェンスフィードがすべて同じ脆弱性を標準化された名称で参照できます。これにより、対応まで数日ではなく数時間しかない場合でも混乱を排除できます。
MITRE コーポレーション（DHS指定）は、CVEを管理し、脆弱性を報告する際にセキュリティツールが参照する辞書として機能しています。CVEの標準化により、1つの識別子（CVE-YYYY-NNNN形式）で発見、評価、優先順位付け、修正、検証の各ワークフローを一貫して追跡できます。
MITREのCWE Top 25 Methodologyによると、2025年には39,450件の脆弱性レコードを処理するシステムを運用しています。すべてを修正することはできないため、効果的な優先順位付けには標準化された識別が必要です。
.jpg)
CVEとCVSSの違いとは？
CVEとCVSSは異なる問いに答えます。CVEは脆弱性が「何か」を示し、CVSSはその「深刻度」を示します。
CVE（共通脆弱性識別子）はCVE-YYYY-NNNN形式の識別子を提供し、YYYYは割り当て年、NNNNは連番です。これにより、セキュリティスタック全体で一貫した追跡が可能となります。
CVSS（共通脆弱性評価システム）は、0.0から10.0までの深刻度スコアを3つの異なる指標で提供します：
- 基本指標：脆弱性自体の本質的な特性を評価
- 時間的指標：エクスプロイトの有無やパッチ状況など時間依存の要素を考慮
- 環境指標：資産の重要度や既存のセキュリティ制御など、特定環境への影響を評価
CVEとCVSSを組み合わせることで、効果的な優先順位付けが可能となります。脆弱性スキャナーがCVE-2021-44228を検出し、脅威フィードがCVSS基本スコア10.0を確認、環境スコアは脆弱なLog4jインスタンスがインターネットに公開されているか隔離されているかで調整されます。これにより、迅速かつ正確な対応判断が可能となります。
サイバーセキュリティにおけるCVEの重要性
脅威アクターは脆弱性を武器化し、 脆弱性管理プロセスが対応に取り組む間に攻撃を仕掛けます。CVEの標準化はこのタイムラインギャップを解消するものではありませんが、ツールが検出した脆弱性が何かを特定するために無駄な時間を費やすことを防ぎます。より迅速なトリアージと対応判断が可能となります。
CVEの標準化がなければ、スキャナーは「Apache Log4jのリモートコード実行」と呼び、脅威インテリジェンスフィードは「Log4Shell」と参照し、ベンダーアドバイザリは「JNDIインジェクション脆弱性」と記載するかもしれません。CVE-2021-44228はこの混乱を解消します。1つの識別子、1つの脆弱性、すべてのセキュリティツールで一貫した追跡が可能です。
ENISAのThreat Landscape 2025によると、脆弱性の悪用は欧州組織への侵入の21.3%を占めています。これは、脅威アクターが脆弱性悪用を企業侵害の初期アクセス経路として利用するケースが増加していることを示しています。
CISAのKnown Exploited Vulnerabilitiesカタログは、 1,484件の脆弱性が実際のサイバー攻撃で積極的に悪用されていることを追跡しています。これは全CVEの1%未満ですが、企業にとって最も高いリスクをもたらします。CVEの標準化により、CISAは明確な識別子でこのカタログを公開でき、セキュリティツールが即座に活用できます。
CVE悪用の実世界への影響
2021年のColonial Pipeline ランサムウェア攻撃は、脆弱性が武器化された場合の影響を示しました。攻撃者はレガシーVPNの脆弱性（多要素認証の欠如）を悪用して初期アクセスを獲得し、その後DarkSideランサムウェアを展開し、5,500マイルの燃料パイプラインインフラを暗号化しました。この攻撃により6日間の全面運用停止、米国東海岸での燃料不足、4.4百万ドルの身代金支払いと数千万ドルの復旧費用が発生したと DOJの裁判資料で報告されています。
2017年のEquifaxデータ侵害は、CVE-2017-5638（Apache Strutsの脆弱性）のパッチ適用失敗が原因で、1億4,700万人の個人情報が漏洩しました。 FTCの和解資料によると、この侵害でEquifaxは少なくとも5億7,500万ドルの和解金を支払い、サイバーセキュリティ強化や法的費用を含めると総額14億ドルを超えました。この脆弱性は2か月前に公開されパッチも提供されていましたが、Equifaxの環境では未適用でした。
これらの事例は、脆弱性が発見からセキュリティダッシュボードに至るまでの流れを理解する重要性を示しています。その流れは特定のワークフローに従います。
共通脆弱性識別子（CVE）ワークフローの理解
CVE割り当てワークフローは、脅威アクターが攻撃を仕掛けるまでに数時間の猶予があるか、数週間の猶予があるかを左右します。脆弱性は発見からスキャナーによる検出まで、5つの明確な段階を経て進行します：
- 発見：研究者、ベンダー、またはセキュリティチームが ペネトレーションテスト、脅威ハンティング、 インシデント対応などで脆弱性を特定
- 報告：脆弱性をCVEナンバリング機関（CNA）に報告。CNAは対象製品をカバーする認定組織
- CVE IDリクエスト：CNAが問題が脆弱性として認定されるか評価し、正式なプロセスを開始
- ID予約：CNAが検証済み脆弱性にCVE識別子を予約し、ベンダーがパッチを公開前に調整できるようにする
- 公開：CNAがCVEレコードを公開し、説明、影響を受ける製品、修正ガイダンスなど完全な脆弱性情報を提供
このワークフローは管理する組織に依存します。誰がCVE識別子を割り当てるかを理解することで、どこに脆弱性を報告し、どれだけ早く標準化された追跡が始まるかを把握できます。
CVEの割り当てと管理を行う組織
CVEナンバリング機関（CNA）は、それぞれの定義された範囲内でCVE識別子を割り当てており、世界中で数百のCNAが活動しています。CNAにはベンダー組織、オープンソースプロジェクト、CERT組織、バグバウンティプロバイダーが含まれます。この分散モデルにより、各CNAが自社製品分野の専門知識を活かし、中央集権型よりも迅速な脆弱性処理が可能となります。
CNAプログラムは階層構造で運用されています。最上位にはMITREがプライマリCNAおよびプログラム管理者として方針策定とグローバルネットワークの調整を担います。Root CNAは特定分野や地域のCNAグループを管理します。例えば、CISAは重要インフラ分野のRoot CNA、Japan CERT Coordination Center（JPCERT/CC）はアジア太平洋地域のCNAを調整します。この階層構造により、標準の一貫性と地域専門性、迅速な対応が両立されます。
主要なテクノロジーベンダーは自社製品のCNAとして機能します。Microsoft、Google、Apple、Cisco、Oracleは自社ソフトウェアやハードウェアで発見された脆弱性にCVE識別子を割り当てます。セキュリティ研究者がこれら製品の脆弱性を発見した場合、ベンダーのセキュリティチームに直接報告し、CVE割り当てとパッチ開発が同時に進行します。この統合により、発見から修正までのタイムラインが短縮されます。
MITREは現在利用されている基盤インフラを確立し、グローバルCNAネットワークの調整を継続しています。MITREは1999年にCVEリストを作成し、提出物の審査プロセスや脆弱性分析の標準を策定しました。プログラムは1組織から始まり、現在は40か国以上、300以上のCNAによるグローバルネットワークへと拡大し、ソフトウェア脆弱性の拡大と分散専門性の必要性を反映しています。
脆弱性を発見した場合、適切なCNAを特定することで、どれだけ早くCVE識別子が割り当てられるかが決まります。まず、対象ベンダーが公式CVEウェブサイトのCNAリストに掲載されているか確認してください。ベンダーがCNAでない場合は、CERT/CCなどの調整センターや該当分野のRoot CNAに報告します。オープンソースプロジェクトの脆弱性については、Apache Software Foundation、Linuxカーネルセキュリティチーム、Python Software Foundationなど、多くの主要プロジェクトが独自のCNAを運用しています。
CVEの発見と報告方法
セキュリティチームは複数のチャネルを通じて脆弱性を発見しており、それぞれCVE識別子の割り当てやセキュリティツールへの到達速度に影響する特徴があります。
- セキュリティリサーチはCVE発見の最大の源です。独立系研究者、学術機関、ベンダーのセキュリティチームがソフトウェアやハードウェアを体系的に分析し、攻撃者より先に弱点を特定します。これらの発見は通常、責任ある開示手順に従い、ベンダーにパッチ開発の猶予を与えてから公表されます。
- バグバウンティプログラムは外部研究者に脆弱性の発見とベンダーへの報告を奨励します。大手テクノロジー企業はバウンティプログラムを運用し、数千件のCVEが特定されています。研究者がこれらのプログラムを通じて報告すると、ベンダーのCNAが即座にCVE割り当てプロセスを開始し、修正策の開発を進めます。
- 脅威ハンティングとインシデント対応は、アクティブな調査中に脆弱性を発見することが多いです。セキュリティチームが不審な活動を調査する際、攻撃者が未知の弱点を悪用していることを発見する場合があります。これらの発見は緊急のCVE割り当てや迅速な開示につながることが多いです。
- ベンダーテストはソフトウェア開発中にリリース前の脆弱性を検出します。静的解析、動的テスト、コードレビューにより、既存バージョンに影響する場合やセキュリティコミュニティへの開示が有益な場合にCVE識別子が付与されます。
脆弱性を発見した場合、報告プロセスは確立されたガイドラインに従います。FIRST.orgの協調開示フレームワークが多くの組織で採用されており、ベンダーまたは適切なCNAに連絡し、再現可能な技術情報を提供し、公衆の安全と修正期間のバランスを取った開示スケジュールに合意します。多くのベンダーは90日以内の修正を目標としていますが、重大な脆弱性が積極的に悪用されている場合は、より迅速な開示が求められることもあります。
年間数千件のCVEが公開される中、どの脆弱性タイプが最大のリスクとなるかを把握することが、セキュリティ対策の優先順位付けに役立ちます。
CVEで追跡される主な脆弱性タイプ
CISAのKnown Exploited Vulnerabilitiesカタログは、脅威アクターが最も頻繁に武器化する脆弱性タイプを明らかにしています：
- Out-of-bounds Write（CWE-787）：メモリ破損による任意コード実行を可能にし、1位にランクイン
- クロスサイトスクリプティング（CWE-79）：攻撃者が悪意のあるスクリプトをWebアプリケーションに注入し、被害者のブラウザで実行
- SQLインジェクション（CWE-89）：攻撃者が入力フィールドを通じて悪意のあるSQLコマンドを注入
- OSコマンドインジェクション（CWE-78）：認証なしで直接システムアクセスを可能にし、5位にランクイン
これらの一般的な脆弱性パターンを理解することで、CVE識別子が割り当てられる前に ゼロデイ脅威を認識できます。
どの脆弱性タイプが存在するかを知るだけでは不十分です。攻撃者が実際にどのようにこれらの弱点を悪用するかを理解することが、防御戦略の策定に役立ちます。
攻撃者によるCVEの悪用方法
攻撃者はCVEで追跡される脆弱性を主に以下の攻撃パターンで利用します。
- リモートコード実行チェーン：インジェクションやメモリ破損の脆弱性を利用。Out-of-bounds Write（CWE-787）、コマンドインジェクション（CWE-78）、Use After Free（CWE-416）がCISAのKEVカタログで上位を占めます。
- 認証バイパス：暗号検証の弱点を悪用。CISAは、細工されたSAMLメッセージによるSSOバイパスを許すエンタープライズVPN製品を文書化しており、正規認証情報なしで不正アクセスが可能となります。
- コマンドインジェクション：認証なしで直接システムを侵害。攻撃者はWebフォーム、APIパラメータ、ファイルアップロードを通じて悪意のあるコマンドを注入し、アプリケーション権限で実行させます。
これらの攻撃パターンは、脆弱性管理プログラムにおけるCVE追跡の重要性を説明しています。
脆弱性管理におけるCVEの役割
CVE識別子は、発見、評価、優先順位付け、修正、検証の各ワークフローで脆弱性を一貫して追跡するのに役立ちます。脆弱性スキャナーが欠陥を検出しCVE識別子を割り当てることで、 脅威インテリジェンスフィード、ベンダーアドバイザリ、エクスプロイトデータベースと相関できます。CISA KEVカタログと資産インベントリを突き合わせることで、どの資産が積極的に悪用されている脆弱性を含むかを特定できます。
CVE標準化によるワークフローコミュニケーションの効率化
CVE番号は、脆弱性管理ワークフロー全体でコミュニケーションを効率化する標準化識別子として機能します。脆弱性を発見または通知を受けた際、CVE番号によりすべてのチームメンバー、セキュリティツール、ベンダーが同じ問題を一貫したラベルで参照できます。この統一性により誤解が減り、意思決定が迅速化され、修正作業の優先順位付けと調整が効果的に行えます。
標準化された参照点により、さまざまなセキュリティシステムとの統合が可能となります。脅威インテリジェンスフィード、脆弱性スキャナー、パッチ管理ソリューションがすべて共通の目標、すなわち迅速かつ正確な脆弱性修正に向かって連携します。EDRがCVE-2021-44228に関連する不審な活動を検出した場合、 SIEMが同じ識別子で脆弱性スキャンデータと相関します。チケッティングシステムは同じ参照で修正進捗を追跡し、コンプライアンスレポートも標準化された用語で対応を記録します。
CVEの標準化は、組織全体のセキュリティ評価、監査報告、取締役会向けプレゼンテーション、規制当局への提出書類など、報告やコンプライアンスプロセスも簡素化します。3つの異なるアラートが同じ脆弱性を指しているか確認するのに何時間も費やす代わりに、すべてのシステムでCVE-2021-44228を即座に認識し、限られた時間を実際の修正作業に集中できます。
セキュリティツール間の対応調整
CVE識別子により、セキュリティオペレーションセンターは異なるセキュリティツール間で脆弱性の優先順位付けとトリアージを効率的に行えます。新たな脆弱性が出現した際、CVE識別子が一貫した参照点となります。脆弱性スキャナーがCVE-2024-12345を検出し、脅威インテリジェンスフィードがCVE-2024-12345の悪用状況を提供、パッチ管理システムがCVE-2024-12345の展開状況を追跡し、チケッティングシステムがCVE-2024-12345のワークフローを管理します。
この標準化により調整ミスが減り、意思決定が迅速化されます。CVE標準化により、リソースを効果的に配分し、パッチを企業全体で一貫して適用できます。統一された参照により自律的なワークフローが実現し、セキュリティオーケストレーションプラットフォームがスキャナーの検出結果と脅威インテリジェンスを自動的に相関し、影響を受ける資産のチケットを作成し、単一の識別子で修正進捗を追跡します。
リスクベースの優先順位付け
優先順位付けにはCVSSだけでなく、EPSS（Exploit Prediction Scoring System）とCISAのKnown Exploited Vulnerabilitiesカタログを統合することで、実際に確認されたリスクを持つごく一部のCVEに集中できます。
まずCISAのKEVカタログを即時の優先フィルターとして使用します。残りのCritical/High CVEにはEPSS確率スコアを適用します。組織の状況にはStakeholder-Specific Vulnerability Categorization（SSVC）を活用します。
NISTのサイバーセキュリティフレームワーク2.0は、脆弱性管理を「統治」「特定」「保護」「検知」「対応」「復旧」の6機能で整理しています。
CVE標準化は大きなメリットをもたらしますが、脆弱性管理ワークフローに影響する課題も存在します。
CVEシステムの課題と限界
脆弱性管理ワークフローは、不完全なNVDデータに依存すると失敗を経験します。脆弱性スキャナーが新しいCVEを検出しても、NVDが「分析保留」と返す場合、デフォルトでCriticalとして扱う（アラート疲労を招く）か、ベンダーアドバイザリや脅威インテリジェンスフィードで手動調査するしかありません。
MITREの手法によると、2025年には 39,450件の脆弱性レコードを処理するシステムを運用しており、このボリュームは分析リソースを上回っています。
NVDデータの限界とマルチソースインテリジェンスの必要性
National Vulnerability Databaseは有用なCVSSスコアや脆弱性説明を提供しますが、NVDだけに依存した脆弱性データ分析・追跡では、セキュリティ体制にギャップが生じます。NVD最大の限界は環境コンテキストの欠如です。CVSSスコアは理論上の深刻度を示しますが、実際の悪用可能性や自組織への具体的影響は反映されません。Criticalと評価された脆弱性でも、影響を受けるコンポーネントがインターネット非接続のセグメントで稼働していればリスクは最小です。逆に、顧客データを処理するインターネット公開アプリケーションの中程度の脆弱性が最優先リスクとなる場合もあります。
NVDデータは実際の悪用状況に関するコンテキストが不足しています。CVSS基本スコアは理論上の深刻度を評価しますが、脅威アクターが現実世界で脆弱性を武器化しているかどうかは示しません。この情報ギャップにより、理論上Criticalな脆弱性の修正に数週間費やし、攻撃者が積極的に悪用している中程度の脆弱性を見落とすリスクが生じます。
大規模なNVDバックログがこれらの課題をさらに悪化させています。 NISTのNVDプログラム更新によると、2024年にCVE提出が32%増加した一方で処理能力は制約されており、バックログは拡大し続けています。最近の脆弱性は「分析保留」状態が数週間から数か月続くことが多く、悪用リスクが最も高い初期段階でセキュリティチームがCVSSスコアを得られません。ベンダーアドバイザリ、脅威インテリジェンスフィード、CISA Known Exploited Vulnerabilitiesカタログなど追加インテリジェンスを統合しなければ、過剰対応や過小対応のリスクがあります。
正確な脆弱性管理にはマルチソースインテリジェンスが不可欠です。製品固有のコンテキストや修正ガイダンスにはベンダーアドバイザリ、悪用指標や攻撃者戦術・技術・手順（TTPs）には脅威インテリジェンスフィード、CISAのKEVカタログで悪用確認状況、 セキュリティ研究コミュニティとの関係で新興脅威の早期警戒を得る必要があります。この統合アプローチにより、理論上の深刻度だけでなく実際のリスクに基づいて優先順位付けできます。
その他のシステム課題
CVEカウントルールには脆弱性の追跡方法に限界があり、一部のセキュリティ弱点はCVE IDが付与されない場合があります。大規模なNVDバックログと相まって、これらのギャップに対応するため、セキュリティチームはベンダーアドバイザリ、CISAアラート、脅威インテリジェンスフィードなど複数の情報源を統合する必要があります。
分散型CNAモデルはスケーラビリティを向上させますが、一貫性の課題も生じます。数百のCNAが定義範囲内で運用しているため、CVEレコードの品質や完全性にばらつきがあります。
協調開示におけるタイムライン管理は、厳密な日数要件ではなく、発見者とベンダー間の明確な期待値に依存します。セキュリティチームは、ベンダーが脆弱性の深刻度、悪用状況、修正の複雑さに基づいて閾値を設定することを理解することで、開示ウィンドウを予測できます。
これらの課題にもかかわらず、実証済みのプラクティスにより、脆弱性管理プログラム内でCVEを効果的に管理できます。
CVE管理のベストプラクティス
複数のインテリジェンスソースを組み合わせたリスクベースの優先順位付けを実施すべきです。まずCISAのKnown Exploited Vulnerabilitiesカタログを即時の優先フィルターとして使用します。これらの 1,484件の脆弱性は、最も迅速な対応が必要な実際の悪用が確認されたものです。
CISA KEVによる戦略的優先順位付け
CISAのKnown Exploited Vulnerabilitiesカタログは、 パッチ管理戦略の基盤とすべきです。修正タイムラインを悪用状況に直接合わせます。KEV掲載脆弱性は、理論上のリスクではなく実際の脅威であるため、2～7日以内の対応が求められます。CISAが脆弱性をKEVカタログに追加した時点で、脅威アクターは既に実際の攻撃で利用しています。
KEVカタログを活用し、即時修正だけでなく脅威インテリジェンス活動も強化します。新規KEVエントリを定期的に確認し、脅威アクターが優先する脆弱性タイプ、標的業界、構築している攻撃チェーンを把握します。このインテリジェンスは検知戦略に反映されます。CISAがVPN製品の認証バイパス脆弱性をKEVに追加した場合、特定CVEのパッチ適用済みでも異常な認証パターンの監視を強化します。
KEV統合により検知能力とインシデント対応準備が向上します。KEV掲載脆弱性の悪用手法に特化した検知ルールを構築します。CISAがCVE-2024-12345が特定エンドポイントへの細工HTTPリクエストで悪用されていると文書化した場合、そのリクエストパターンを検出するネットワークシグネチャを作成します。SIEMを設定し、悪用試行を資産インベントリと自動的に相関させ、緊急パッチが必要なシステムと既に保護されているシステムを特定します。
パッチ管理戦略
査読済み研究によると、EPSSとCISAのKEVカタログを統合することで、CVSSのみのアプローチに比べて18倍の効率向上が得られました。悪用状況と深刻度に基づき、以下のパッチタイムラインを適用します：
| 優先カテゴリ | タイムライン | 根拠 |
| CISA KEV（既知の悪用） | 2～7日 | 実際の悪用 |
| Critical Severity + High EPSS | 7～14日 | 高い悪用確率 |
| Critical Severity + Low EPSS | 30日 | 悪用証拠なし |
| High Severity + High EPSS | 14～30日 | 中程度の深刻度かつ悪用可能性高 |
| High Severity + Low EPSS | 60日 | 中程度の深刻度かつリスク低 |
複数のインテリジェンスソース（ベンダーアドバイザリ、自律的データエンリッチメント、 セキュリティ研究コミュニティとの関係）を統合します。
リーチャビリティ分析を活用し、修正負担を軽減します。リーチャビリティ分析により、ライブラリ内に存在しても実際のデプロイメントで呼び出されない脆弱性を特定し、修正作業を大幅に削減できます。
重要度分類付きの詳細な資産インベントリを維持します。インターネット公開資産、ビジネスクリティカルシステム、機密データ処理システムを追跡します。明確な責任範囲でパッチSLAを文書化します。パッチ例外を認める場合は、代替制御策、期間、承認権限を記録します。
これらのベストプラクティスを実践するには、継続的な脆弱性検出とインテリジェントな優先順位付けをサポートするツールが必要です。
SentinelOneによるCVEリスク管理支援
スケジュールされたスキャンに依存しない継続的な脆弱性検出が必要です。 Singularity Vulnerability Managementは、既存のSentinelOneエンドポイントエージェントを通じてリアルタイムで環境を監視し、OSやアプリケーション全体の脆弱性を既存エンドポイント基盤で検出します。
Singularity Platformはセキュリティ環境全体の統合可視化を提供し、脆弱性データと脅威インテリジェンスフィードを相関させ、即時対応が必要な問題を自動的にフラグします。MITRE ATT&CK評価では、SentinelOneは他のエンドポイントセキュリティプラットフォームに比べて88%少ないアラート（12件、他社は178,000件）を生成し、誤検知疲労を排除しつつ実際の脅威への集中を実現します。
Singularity Platformエコシステムとの統合により、 Singularity Endpoint、 Singularity Cloud、 Singularity Identity、 Singularity XDR機能全体で統合可視化が可能です。脆弱性データは広範な脅威検知・対応ワークフローに直接連携し、脆弱性が積極的に悪用されている場合に調整された対応を実現します。 Purple AIは、早期導入企業によると脅威調査を最大80%高速化し、自然言語によるセキュリティ分析でチームの能力を強化します。
この自律型アプローチにより、従来のスキャン型検出と脆弱性公開のギャップを解消します。ネットワーク型スキャナーのインフラ負荷や帯域消費、スケジューリングの複雑さなしに継続的な評価が可能です。
SentinelOneのデモを予約し、Singularity Vulnerability Managementが継続的検出、自律的優先順位付け、統合脅威対応でエンタープライズ全体のCVEリスクをどのように低減するかをご確認ください。
重要なポイント
CVEの標準化は、セキュリティスタック全体のコミュニケーション課題を解決し、スキャナー、脅威フィード、ベンダーアドバイザリが同じ識別子で脆弱性を参照できるようにします。 年間39,450件のCVEレコードのうち、実際に悪用が確認されているのは1%未満であり、効果的な優先順位付けが対応可能な作業量とアラート疲労を分離します。
まずCISAのKEVカタログに掲載された1,484件の実際に悪用されたCVEにチームの限られた時間を集中し、残りの脆弱性にはEPSS確率スコアを適用します。研究によれば、この統合アプローチはCVSSのみの手法に比べて18倍の効率向上をもたらし、より多くの悪用脆弱性を検出できます。
NVDのバックログにより、完全なエンリッチメントを待つことはできません。ベンダーアドバイザリ、CISAアラート、脅威フィード、NVDデータを組み合わせたマルチソースインテリジェンスパイプラインを構築し、実際に悪用されている脆弱性に対して2～7日以内の修正ウィンドウを確保してください。
よくある質問
CVE（共通脆弱性識別子）は、公開されたセキュリティ脆弱性に割り当てられる標準化された識別子です。各CVEはCVE-YYYY-NNNNの形式に従い、YYYYは年、NNNNは一意の連番です。
MITRE CorporationがCVEシステムを管理しており、セキュリティツール、ベンダー、研究者が業界全体で一貫して脆弱性を参照できるようにしています。
CVE Numbering Authorities（CNA）が、それぞれの定義された範囲内でCVE識別子を割り当てます。CVEプログラムには、ベンダー組織、研究者組織、オープンソースプロジェクト、CERT組織、バグバウンティプロバイダーなど、数百のCNAが含まれます。
これらのCNAはMITREによって調整された分散型階層構造で運用されており、グローバルなセキュリティエコシステム全体で迅速な脆弱性追跡を可能にしています。
脆弱性は、ソフトウェアやハードウェアに存在するセキュリティ上の弱点全般を指します。CVEは、公開され、リリース済みソフトウェアに影響を与える脆弱性にのみ割り当てられる標準化された識別子です。
ペネトレーションテストで多数の脆弱性が発見される場合もありますが、CVEの基準を満たすものだけが識別子を受け取ります。ゼロデイ脆弱性は、ベンダーがパッチを準備するまでCVE IDが付与されません。
セキュリティチームは、セキュリティリサーチ、ベンダーテスト、バグバウンティプログラム、脅威ハンティング、およびインシデント対応を通じて脆弱性を発見します。
脆弱性を発見した場合、影響を受ける製品に基づいて適切なCVEナンバリング機関に報告します。責任ある開示は、FIRST.orgのガイドラインに従い、明確な調整ポリシーと実行可能なタイムラインで行われます。
いいえ。約20万件の既知CVEのうち、CISAのKnown Exploited Vulnerabilitiesカタログで実際に悪用が確認されているのは1,484件のみで、全体の1%未満です。
セキュリティチームは、この悪用が確認されたサブセットを優先し、残りの脆弱性にはEPSSなどのリスクベース手法を活用するべきです。
まずCISAのKEVカタログで悪用が確認されたものから対応し、次にEPSSで悪用可能性、CVSSで重大度、SSVCで組織的文脈を評価します。
調査によると、この統合的アプローチはCVSSのみの手法と比べて18倍の効率向上をもたらします。リーチャビリティ分析で未露出の脆弱性を特定し、資産の重要度に応じて調整してください。
組織は、プロアクティブな検出と迅速な対応を組み合わせた多層的アプローチによってCVEリスクを低減します。新たなCVEが環境に影響を与える際に特定できるよう、定期的な評価ではなく継続的な脆弱性スキャンを実施してください。CISAのKEVカタログによる確認済みの悪用や、EPSSスコアによる悪用確率を用いて、修正の優先順位を決定します。
新しいCVEが公開された際に影響を受けるシステムを迅速に特定できるよう、正確な資産インベントリを維持してください。多層防御として、ネットワークセグメンテーション、エンドポイント保護、アクセス制御などの対策を導入し、脆弱性が存在する場合でもリスクの露出を制限します。重大な脆弱性に対しては、明確な責任者とエスカレーション経路を定めたパッチSLAを文書化して確立してください。
