この記事の対象読者

セキュリティ系のニュースで「CVE-2025-XXXX」という文字列を見かけて気になっている方
脆弱性管理をこれから学びたいエンジニア
Pythonでセキュリティ系のツールを触ってみたい方

この記事で得られること

1. CVEとは何か — その正体と、なぜ世界中のエンジニアが同じ番号を参照するのかが理解できる
2. CVE番号が発行されるまでの流れと、登場する組織の役割がわかる
3. CVSS・CWE・NVDなど周辺概念との関係が整理できる
4. PythonでCVE情報を取得・分析する実践スクリプトが手に入る
5. 2025年の資金危機と、CVEプログラムの「これから」がわかる

この記事で扱わないこと

個別CVEの攻撃手法の詳細（攻撃コードの解説等）
企業向け脆弱性管理ツール（Tenable, Qualys等）の導入ガイド
ペネトレーションテストの実施方法

1. はじめに — なぜCVEを知るべきなのか

ソフトウェアの世界には、毎日のように新しい「病気」が見つかっている。

2025年だけで48,174件もの脆弱性が公開された。1日あたり約131件。もはや人間が手作業で追いかけられる数ではない。

この膨大な脆弱性のひとつひとつに**世界共通の「診断書番号」を振る仕組み。それがCVE（Common Vulnerabilities and Exposures）**だ。

本記事では、CVEを「病院の診療システム」という比喩を使って解説していく。ソフトウェアの脆弱性を「病気」、CVE番号を「診断コード」と捉えると、この仕組みの全体像が驚くほどスッキリ見えてくる。

CVEは「シーブイイー」と読む。"Common Vulnerabilities and Exposures"（共通脆弱性識別子）の略称だ。

読者がこのセクションで得たのは「CVEが存在する理由」だ。次のセクションでは、CVEの構造そのものに踏み込んでいく。

2. CVEの基本構造 — 「診断書番号」のフォーマットを読み解く

2.1 CVE IDのフォーマット

CVE番号は、病院でいえば「診断コード」にあたる。どの病院（ベンダー）に行っても、同じ病気（脆弱性）には同じコードが振られる。だから世界中の医師（セキュリティ研究者）が同じ言語で会話できる。

CVE-2025-32432
 │    │     │
 │    │     └─ 通し番号（シーケンス番号）
 │    └──────── 採番年（≠発見年。採番された年）
 └───────────── プレフィックス（固定）

よくある誤解: CVE-2025-XXXXXの「2025」は脆弱性が発見された年ではなく、CVE IDが採番された年だ。採番と公開にタイムラグがあるケースは珍しくない。

2.2 CVEレコードに含まれる情報

ひとつのCVEレコードは、患者の「カルテ」のようなものだ。以下の情報が記載されている。

フィールド	内容	病院の比喩
CVE ID	一意の識別番号	診断コード
Description	脆弱性の概要説明	症状の説明
References	参考情報・アドバイザリへのリンク	参考文献・検査結果
Affected Products	影響を受ける製品・バージョン	罹患した臓器・部位
CNA	採番した組織	診断した専門医

2.3 CVEの「状態」

CVEには複数の状態がある。カルテにも「暫定診断」と「確定診断」があるのと同じだ。

状態	意味
RESERVED	番号が予約済みだが、まだ詳細は非公開（診察中）
PUBLISHED	脆弱性情報が公開済み（確定診断が出た）
REJECTED	無効と判定された（誤診だった）

CVE番号の構造を理解したところで、次はこの「診断書」がどのような流れで発行されるのかを見ていこう。

3. CVEが発行されるまでの流れ — 「診断書」ができるプロセス

3.1 登場する組織と役割

CVEの発行プロセスには複数の組織が関わる。病院のシステムに例えると、それぞれの役割がはっきりする。

組織	役割	病院の比喩
MITRE	CVEプログラムの運営・管理。1999年に開始	病院の運営本部
CNA (CVE Numbering Authority)	CVE番号を採番する権限を持つ組織。2025年時点で365以上	各科の専門医（診断コードを発行できる）
CVE Board	プログラムの方向性を助言する委員会	病院の理事会
NVD (National Vulnerability Database)	NISTが運営する米国の脆弱性データベース。CVSSスコアを付与	国立の医療記録データベース
CISA	米国国土安全保障省のサイバーセキュリティ部門。CVEの資金提供元	病院への予算を出す行政機関

3.2 CVE発行のステップ

大手ベンダー（Microsoft、Google、Apple等）は自らがCNAであり、自社製品の脆弱性に対して直接CVE番号を採番できる。いわば「院内で診断コードを発行できる大病院」だ。

CVEが発行される仕組みを理解したので、次は「重症度をどう測るのか」という話に進もう。CVE単体では「何が壊れているか」しかわからない。「どれくらいヤバいのか」を示すのが、CVSSだ。

4. CVEの周辺概念 — CVSS・CWE・KEV を整理する

CVEは脆弱性の「名前」を付けるだけの仕組みだ。病院の比喩でいえば、CVEは「この患者は○○病です」という診断名。だが医師は診断名だけでなく、重症度、病気の分類、緊急対応の要否も判断する必要がある。

4.1 CVSS — 重症度のトリアージスコア

**CVSS（Common Vulnerability Scoring System）**は、脆弱性の「重症度」を0.0〜10.0のスコアで数値化する仕組みだ。病院でいえば、救急搬送時のトリアージ（緊急度判定）にあたる。

CVSSスコア	深刻度	病院の比喩
0.0	なし	健康
0.1〜3.9	Low	経過観察
4.0〜6.9	Medium	外来治療
7.0〜8.9	High	入院治療
9.0〜10.0	Critical	緊急手術

CVSSスコアは複数の評価軸（攻撃元区分、攻撃条件の複雑さ、必要な特権レベル等）を組み合わせて算出される。

\text{CVSS Base Score} = f(\text{Impact}, \text{Exploitability})

CVSSスコアだけで優先度を決めるのは危険。スコアが高くても実際に悪用されていない脆弱性もあれば、スコアが中程度でも攻撃が活発な脆弱性もある。後述するKEVやEPSSと組み合わせて判断すべきだ。

4.2 CWE — 病気の「分類体系」

**CWE（Common Weakness Enumeration）**は、脆弱性の「種類」を分類する体系だ。CVEが個別の「この患者は○○病」なら、CWEは「○○病は感染症の一種である」という医学的分類にあたる。

CWE ID	名称	概要
CWE-79	Cross-Site Scripting (XSS)	2025年最多の脆弱性分類。8,000件超
CWE-89	SQL Injection	データベースへの不正クエリ注入
CWE-862	Missing Authorization	認可チェックの欠如
CWE-74	Injection	全般的なインジェクション
CWE-506	Embedded Malicious Code	悪意のあるコードの埋め込み

4.3 KEV — 「いま流行っている病気」リスト

**KEV（Known Exploited Vulnerabilities）**は、CISAが管理する「実際に攻撃に悪用されていることが確認された脆弱性」のカタログだ。病院でいえば「いま地域で流行している感染症リスト」にあたる。

KEVに載っている脆弱性は今すぐ対応が必要だ。CVSSスコアが中程度でも、KEVに載っていれば優先的にパッチを当てるべきである。

4.4 EPSS — 「今後悪用される確率」の予測

**EPSS（Exploit Prediction Scoring System）**は、ある脆弱性が今後30日以内に悪用される確率を0〜1で予測するモデルだ。病院でいえば「この病気が重症化する確率予測」にあたる。

周辺概念を整理できた。ここまでが「知識編」だ。次のセクションでは、PythonでCVE情報を実際に取得・分析するスクリプトを書いていく。手を動かすと理解が一段深まるはずだ。

5. 実践: PythonでCVE情報を取得・分析する

5.1 環境構成

項目	環境A（開発）	環境B（本番/CI）	環境C（テスト）
OS	Windows 11	Ubuntu 24.04 (Docker)	WSL2 Ubuntu
Python	3.11	3.11	3.11
用途	ローカル調査	定期スキャン	動作確認

5.2 CVE情報取得スクリプト

NVDのAPIを使ってCVE情報を取得し、重症度別に集計するスクリプトだ。

"""
CVE情報取得・分析スクリプト
NVD API 2.0を使用して直近のCVE情報を取得し、重症度別に集計する
"""
import json
import urllib.request
import urllib.parse
from datetime import datetime, timedelta, timezone
from collections import Counter


NVD_API_BASE = "https://services.nvd.nist.gov/rest/json/cves/2.0"


def fetch_recent_cves(days: int = 7, max_results: int = 50) -> list[dict]:
    """直近N日間のCVEを取得する"""
    end = datetime.now(timezone.utc)
    start = end - timedelta(days=days)

    params = {
        "pubStartDate": start.strftime("%Y-%m-%dT%H:%M:%S.000"),
        "pubEndDate": end.strftime("%Y-%m-%dT%H:%M:%S.000"),
        "resultsPerPage": str(max_results),
    }
    url = f"{NVD_API_BASE}?{urllib.parse.urlencode(params)}"

    req = urllib.request.Request(url, headers={"User-Agent": "CVE-Analyzer/1.0"})
    with urllib.request.urlopen(req, timeout=30) as resp:
        data = json.loads(resp.read().decode())

    return data.get("vulnerabilities", [])


def extract_severity(vuln: dict) -> str:
    """CVSSv3.1のベーススコアから重症度を判定する"""
    cve_data = vuln.get("cve", {})
    metrics = cve_data.get("metrics", {})

    # CVSSv3.1を優先、なければCVSSv3.0を参照
    for key in ("cvssMetricV31", "cvssMetricV30"):
        if key in metrics:
            score = metrics[key][0]["cvssData"]["baseScore"]
            if score >= 9.0:
                return "CRITICAL"
            elif score >= 7.0:
                return "HIGH"
            elif score >= 4.0:
                return "MEDIUM"
            elif score > 0:
                return "LOW"
            return "NONE"

    return "UNSCORED"


def analyze_cves(vulns: list[dict]) -> None:
    """CVE情報を重症度別に集計・表示する"""
    severity_counter = Counter()
    cwe_counter = Counter()

    for vuln in vulns:
        severity = extract_severity(vuln)
        severity_counter[severity] += 1

        # CWE情報を抽出
        cve_data = vuln.get("cve", {})
        for weakness in cve_data.get("weaknesses", []):
            for desc in weakness.get("description", []):
                cwe_id = desc.get("value", "Unknown")
                if cwe_id != "NVD-CWE-noinfo":
                    cwe_counter[cwe_id] += 1

    print("=" * 50)
    print(f"  CVE分析結果（直近取得分 {len(vulns)} 件）")
    print("=" * 50)

    # 重症度別集計
    print("\n■ 重症度別の件数:")
    severity_order = ["CRITICAL", "HIGH", "MEDIUM", "LOW", "NONE", "UNSCORED"]
    severity_emoji = {
        "CRITICAL": "🔴", "HIGH": "🟠", "MEDIUM": "🟡",
        "LOW": "🟢", "NONE": "⚪", "UNSCORED": "❓",
    }
    for sev in severity_order:
        count = severity_counter.get(sev, 0)
        bar = "█" * count
        emoji = severity_emoji.get(sev, "")
        print(f"  {emoji} {sev:<10}: {count:>3} {bar}")

    # CWEトップ5
    print("\n■ CWE（脆弱性分類）トップ5:")
    for cwe, count in cwe_counter.most_common(5):
        print(f"  {cwe:<15}: {count} 件")


def main():
    print("NVD APIからCVE情報を取得中...")
    try:
        vulns = fetch_recent_cves(days=7, max_results=100)
        if not vulns:
            print("取得できたCVEが0件でした。期間を広げて再試行してください。")
            return
        analyze_cves(vulns)
    except Exception as e:
        print(f"エラーが発生しました: {e}")
        print("NVD APIのレートリミットに引っかかった可能性があります。")
        print("APIキーの取得を検討してください: https://nvd.nist.gov/developers/request-an-api-key")


if __name__ == "__main__":
    main()

5.3 特定パッケージの脆弱性チェックスクリプト

自分のPython環境にインストールされているパッケージに既知の脆弱性がないか確認するスクリプトだ。

"""
Python環境の脆弱性簡易チェッカー
pip list の出力からパッケージ名を抽出し、NVD APIで脆弱性を検索する
"""
import json
import subprocess
import urllib.request
import urllib.parse
import time


NVD_API_BASE = "https://services.nvd.nist.gov/rest/json/cves/2.0"


def get_installed_packages() -> list[tuple[str, str]]:
    """pip listからインストール済みパッケージを取得"""
    result = subprocess.run(
        ["pip", "list", "--format=json"],
        capture_output=True, text=True
    )
    packages = json.loads(result.stdout)
    return [(p["name"], p["version"]) for p in packages]


def search_cves_for_package(package_name: str, max_results: int = 5) -> list[dict]:
    """指定パッケージ名でNVDを検索"""
    params = {
        "keywordSearch": package_name,
        "resultsPerPage": str(max_results),
    }
    url = f"{NVD_API_BASE}?{urllib.parse.urlencode(params)}"
    req = urllib.request.Request(url, headers={"User-Agent": "PkgChecker/1.0"})

    with urllib.request.urlopen(req, timeout=30) as resp:
        data = json.loads(resp.read().decode())
    return data.get("vulnerabilities", [])


def check_top_packages(top_n: int = 10) -> None:
    """主要パッケージのCVEを確認"""
    packages = get_installed_packages()[:top_n]
    print(f"上位 {len(packages)} パッケージの脆弱性を確認中...\n")

    for name, version in packages:
        try:
            vulns = search_cves_for_package(name)
            count = len(vulns)
            status = "⚠️ 要確認" if count > 0 else "✅ 検出なし"
            print(f"  {name} ({version}): {status} ({count}件)")
            time.sleep(6)  # APIレートリミット対策
        except Exception as e:
            print(f"  {name} ({version}): ❌ 取得失敗 ({e})")


if __name__ == "__main__":
    check_top_packages()

NVD APIにはレートリミットがある（APIキーなし: 5リクエスト/30秒、APIキーあり: 50リクエスト/30秒）。大量のパッケージをチェックする場合はtime.sleep()を適切に挟むこと。

5.4 環境別の設定ファイル

# config_dev.yaml（開発環境）
nvd_api:
  base_url: "https://services.nvd.nist.gov/rest/json/cves/2.0"
  api_key: ""  # 開発時はキーなしでOK
  rate_limit_sec: 6
  timeout_sec: 30
scan:
  days_range: 7
  max_results: 50
  severity_filter: ["CRITICAL", "HIGH"]

# config_prod.yaml（本番/CI環境）
nvd_api:
  base_url: "https://services.nvd.nist.gov/rest/json/cves/2.0"
  api_key: "${NVD_API_KEY}"  # 環境変数から取得
  rate_limit_sec: 1
  timeout_sec: 60
scan:
  days_range: 1  # 毎日実行なので直近1日
  max_results: 200
  severity_filter: ["CRITICAL", "HIGH", "MEDIUM"]
notification:
  slack_webhook: "${SLACK_WEBHOOK_URL}"

# config_test.yaml（テスト環境）
nvd_api:
  base_url: "https://services.nvd.nist.gov/rest/json/cves/2.0"
  api_key: ""
  rate_limit_sec: 6
  timeout_sec: 10
scan:
  days_range: 30
  max_results: 10
  severity_filter: ["CRITICAL"]

Pythonで実際にCVE情報を触れるようになった。次のセクションでは、CVEにまつわるトラブルとその対処法を整理する。

6. よくあるトラブルと対処法

CVEを扱う現場で遭遇しがちな問題をまとめた。病院の比喩でいえば「よくある誤診・見落としパターン集」だ。

#	トラブル	原因	対処法
1	NVD APIがHTTP 403を返す	APIキーなしでのレートリミット超過	`time.sleep(6)`を挟む or APIキーを取得する
2	CVE番号があるのにNVDに情報がない	NVDへのデータ連携が遅延している（バックログ問題）	cve.orgで直接確認する。NVDは分析付加に時間がかかる
3	CVSSスコアが付いていない	NVDの分析が追いついていない（2025年時点でCPEカバー率57.6%）	ベンダーアドバイザリで独自評価する。EPSSも併用
4	同じ脆弱性に複数のCVE IDがある	異なるCNAが別々に採番した重複	REJECTEDステータスを確認。正規のIDに寄せる
5	CVE IDの年号と実際の発見年が違う	CVE IDの年号は「採番年」であり「発見年」ではない	採番年と公開日を区別して管理する
6	`keywordSearch`で関係ない結果が大量に返る	キーワード検索はDescription全文に対するマッチ	CPE名で絞り込む（`cpeName`パラメータ使用）
7	REJECTED状態のCVEをスキャナが検出する	ツールがREJECTED状態を考慮していない	CVEのステータスを必ず確認してからトリアージする

NVDのバックログ問題は深刻だ。2024年春の処理遅延以降、CVE公開からNVDでの分析完了まで数週間〜数ヶ月かかるケースがある。NVDだけに依存せず、ベンダーアドバイザリやGitHub Security Advisory（GHSA）も併用すべきだ。

7. ユースケース別ガイド

ユースケース1: Webアプリ開発者 — 依存パッケージの脆弱性管理

PythonやNode.jsでWebアプリを開発している場合、使用ライブラリの脆弱性を定期的にチェックする必要がある。

# Python: pipのaudit機能（pip 22.2+）
pip audit

# Node.js: npm audit
npm audit

# GitHub Dependabotを有効化（リポジトリの Settings > Security）
# → 脆弱性が見つかるとPRが自動生成される

ポイント: これらのツールは内部的にCVE/GHSAデータベースを参照している。CVEという「共通言語」があるからこそ、ツール横断で同じ脆弱性を追跡できる。

ユースケース2: インフラエンジニア — CIパイプラインでの脆弱性スキャン

Dockerイメージの脆弱性をCIで自動チェックする構成例。

# .github/workflows/vuln-scan.yml
name: Vulnerability Scan
on:
  push:
    branches: [main]
  schedule:
    - cron: '0 9 * * 1'  # 毎週月曜9時に定期実行

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'fs'
          scan-ref: '.'
          severity: 'CRITICAL,HIGH'
          exit-code: '1'  # CRITICAL/HIGHがあればCIを失敗させる

ユースケース3: セキュリティ担当者 — KEVベースの緊急対応フロー

CISAのKEV（Known Exploited Vulnerabilities）カタログに新規追加されたCVEは、即座に対応すべき最優先事項だ。

"""
KEVカタログの新規追加CVEを通知するスクリプト
"""
import json
import urllib.request
from datetime import datetime, timedelta, timezone

KEV_URL = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"


def check_new_kev_entries(days: int = 1) -> list[dict]:
    """直近N日以内に追加されたKEVエントリを取得"""
    req = urllib.request.Request(KEV_URL, headers={"User-Agent": "KEVChecker/1.0"})
    with urllib.request.urlopen(req, timeout=30) as resp:
        data = json.loads(resp.read().decode())

    cutoff = datetime.now(timezone.utc) - timedelta(days=days)
    new_entries = []

    for vuln in data.get("vulnerabilities", []):
        added = datetime.strptime(
            vuln["dateAdded"], "%Y-%m-%d"
        ).replace(tzinfo=timezone.utc)
        if added >= cutoff:
            new_entries.append(vuln)

    return new_entries


if __name__ == "__main__":
    entries = check_new_kev_entries(days=7)
    if entries:
        print(f"⚠️ 直近7日間でKEVに {len(entries)} 件追加されました:\n")
        for e in entries:
            print(f"  {e['cveID']}: {e['vendorProject']} - {e['product']}")
            print(f"    対応期限: {e['dueDate']}")
            print()
    else:
        print("✅ 直近7日間のKEV新規追加はありません。")

8. 2025年の資金危機とCVEの未来 — 「病院が閉鎖されかけた日」

8.1 何が起きたのか

2025年4月15日、セキュリティ業界に激震が走った。

CVEプログラムを25年間運営してきたMITRE社への米国政府からの資金が、翌4月16日に失効するという情報が流れたのだ。...orz

これは病院の比喩でいえば「国立の診断コード管理システムが、翌日から停止します」という通告に等しい。全世界のセキュリティツール、脆弱性データベース、インシデント対応フローがCVEに依存しているなかで、その根幹が止まりかけた。

8.2 危機の経緯

日付	出来事
2025年4月15日	MITREのBarsoum副社長がCVE理事会に資金失効を通知。Krebs on Securityが報道
2025年4月16日	CISAが緊急で11ヶ月の契約延長を実行。即日でサービス継続が確定
2025年4月16日	CVE理事会メンバーがCVE Foundation（非営利団体）の設立を発表
2026年1月	CISAがCVEプログラムの予算を「保護された項目」に格上げ。恒久的な資金確保へ
2026年3月	EUおよび国際連合体が独自のCVE採番システムを立ち上げ

8.3 この危機が示す教訓

(;ﾟдﾟ)ﾎﾟｶｰﾝ ...世界のサイバーセキュリティの根幹が、ひとつの政府契約に依存していたという事実は衝撃的だった。

この事件以降、以下の動きが加速している:

CVE Foundation — CVEプログラムの独立性を確保するための非営利組織
EU独自のCVE採番システム — 米国一国依存からの脱却
AIによる脆弱性報告の爆増 — GitHubへの脆弱性報告が90日間で224%増加（AI生成レポートの影響）

2026年3月時点で、CVEプログラムの資金問題は一応の解決を見ている。CISAの予算内で「保護された項目」に格上げされ、毎年の契約更新で綱渡りする状況は改善された。

9. 学習ロードマップ

CVEの世界は奥深い。ここまでの知識を踏まえて、次に何を学ぶべきか。

レベル1: 基礎固め（本記事の内容 + α）

CVEの基本概念と番号体系
CVSS/CWE/KEV/EPSSとの関係
NVD APIの詳細仕様（フィルタ条件、ページネーション）
GitHub Security Advisory（GHSA）の仕組み

レベル2: 実務適用

脆弱性管理ポリシーの策定（SLA、対応期限の設定）
CI/CDパイプラインへの脆弱性スキャン組み込み
SBOM（Software Bill of Materials）の導入と運用
CNA登録プロセスの理解

レベル3: 高度なセキュリティ運用

CVE Numbering Authority（CNA）としての活動
脆弱性の報告と協調的開示（Coordinated Vulnerability Disclosure）
SSVC（Stakeholder-Specific Vulnerability Categorization）による高度なトリアージ
VEX（Vulnerability Exploitability eXchange）ドキュメントの作成

まとめ

CVEは、ソフトウェア世界の「診断書番号」だ。

1999年にMITREが始めたこのプログラムは、26年以上にわたって世界中のセキュリティ対応を支えてきた。2025年には48,174件もの脆弱性が登録され、2025年4月には資金失効という存亡の危機すら経験した。

正直なところ、CVEの仕組みを調べれば調べるほど「こんな重要なインフラが、こんなに脆い基盤の上に成り立っていたのか」と驚く。セキュリティの世界では「単一障害点を作るな」とよく言われるが、CVEプログラム自体がまさに単一障害点だったというのは皮肉な話だ。

とはいえ、CVE Foundationの設立やEUの動きを見ると、この仕組みが消えることはないだろう。形を変えながらも「脆弱性に共通の名前を付ける」という思想は生き続ける。

エンジニアとして、CVE番号をただの文字列として流し読みするのではなく、その背景にある仕組みを理解しておくこと。それが、自分のコードとシステムを守る第一歩になるはずだ。

参考文献

関連記事

セキュリティ周辺の知識を深めたい方は、以下の記事もあわせてどうぞ。

Dockerってなんだ？ — コンテナの脆弱性スキャンに必要な前提知識
Kubernetesってなんだ？ — クラスタ環境のセキュリティ管理
Pythonで始めるプログラミング — スクリプト作成の基礎
PyPIってなんだ？ — サプライチェーン攻撃の理解に
MCPってなんだ？ — AIエージェントのセキュリティ課題

最後まで読んでいただきありがとうございます。この記事が役に立ったら、いいね・ストックお願いします。