英語版で読む
技術 約7分で読めます

NIST NVDの優先度付きenrichmentでSCAツールごとに見落とし方が変わる

セキュリティ 脆弱性 CVE CISA
いけさん目次

TL;DR

変更 2026年4月15日以降のNIST NVD運用。すべてのCVEを均等にenrichする方式から、CISA KEV／米連邦利用ソフト／EO 14028 critical software優先のリスクベース運用へ

影響 優先外CVEはvulnStatus: Deferredのまま、CPE applicability statementsなし。NVDのCPEで資産マッチングするSCA・VM系ツールでfalse negativeが拡大

確認 NVD APIでのvulnStatusとconfigurationsの直接照会、および自社SCAツールの一次ソース（GHSA、OSV、NVD直、独自再分析のどれか）の把握

NIST NVDが、CVEの件数増加に追いつくために運用を変えた。
2026年4月15日以降、NVDはすべてのCVEへ同じようにCVSS、CWE、CPEを付けるのではなく、実害や米政府利用に近いものを優先してenrichする。

これは「NVDが止まる」話ではない。
CVE自体はNVDに追加される。
変わるのは、その後にNISTが付けていた追加情報（NVD enrichment）の扱いだ。
脆弱性管理ツールがNVDのCPEやNIST側CVSSを前提にしている場合、CVEが存在するのに自分の製品へ紐づかない、深刻度が出ない、変更後の再分析が遅れる、という形で見落としが出る。

CVEは載るがNVDの分析は優先順位付きになる

NISTの発表によると、CVE登録数は2020年から2025年で263%増加した。
2025年にNVDがenrichしたCVEも過去最高より45%多い約42,000件に達したが、処理速度の向上を流入量が上回っている。

新しい優先対象は3つだ。

優先対象確認時の読み方
CISA KEVに入ったCVEすでに実際の悪用が確認された脆弱性。NISTは受領から1営業日以内のenrichmentを目標にする
米連邦政府で使われるソフトのCVE米政府資産への影響を重く見る
EO 14028のcritical softwareのCVE権限、ネットワーク、データ制御、信頼境界に関わる基盤ソフトを優先する

優先外のCVEは、NVD上で「Lowest Priority - not scheduled for immediate enrichment」扱いになる。
NVDの解説によると、Not ScheduledはNVD APIのDeferredステータスに対応し、NVDの対象外、あるいはリソース都合でenrichmentが予定されていない状態を指す。
ユーザーは個別にenrichmentを依頼できるものの、自動でキューに乗る前提ではなくなった。

2024年初頭から残っていた未enrichのバックログも、2026年3月1日より前にNVDに公開されたものはDeferredへ移される。
古いCVEがあとから急にCPE付きで検出される期待は下がる。

NVD APIでvulnStatusを直接見る

特定CVEがNVD上でどの状態にあるかは、NVD API v2.0で1コマンドで確認できる。

curl -s 'https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-XXXX-XXXX' \
  | jq '.vulnerabilities[0].cve
        | {id, vulnStatus, lastModified,
           hasCpe: (.configurations|length > 0),
           hasCvssV31: (.metrics.cvssMetricV31|length > 0),
           hasCvssV40: (.metrics.cvssMetricV40|length > 0),
           hasCwe: (.weaknesses|length > 0)}'

返ってくるvulnStatusは次のいずれか。

値意味
ReceivedCVE記述だけ受領、enrichmentまだ
Awaiting Analysisenrichキューに入っている
Undergoing AnalysisNVDアナリストが作業中
Analyzedenrichment完了
Modified後から記述が変更された
Deferredenrichmentが予定されていない（今回の運用変更でNot Scheduled相当）
RejectedCVE自体が却下

hasCpe: false が返ってきたら、CPE applicability statementsが付いていない。SCAツールがCPEマッチングで自社資産を絞っているなら、その状態のCVEは検出から漏れる。

実際にこのブログで扱ったOllamaのCVE-2026-7482、Dirty Frag関連のCVE-2026-43284、CVE-2026-43500を2026年5月時点で叩くと、3件とも vulnStatus は Analyzed または Modified、CPE・CVSS・CWE揃いで返ってくる。KEV対象とkernel基盤ソフトはちゃんと優先されている、と読める。

対照的に、2026年4月下旬に公開されたCVE-2026-6584（TransformerOptimus SuperAGI 0.0.14のauthorization bypass）を同じコマンドで叩くと、結果はこうなる。

{
  "id": "CVE-2026-6584",
  "vulnStatus": "Deferred",
  "lastModified": "2026-04-29T01:00:01.613",
  "hasCpe": false,
  "hasCvssV31": true,
  "hasCvssV40": false,
  "hasCwe": true
}

CVE自体はNVDに存在し、CVSS v3.1とCWEはCNA側で付いている（NVDが付けたものではない）が、CPEは空のままだ。SCAツールが「NVDに cpe:2.3:a:transformeroptimus:superagi:* 系のapplicabilityがあるか」で資産マッチングしていると、このCVEは引っかからない。AIエージェント基盤側の認可バイパスなのに、NVD経由の自動検知だけだと見落とす形になる。

bulk取得APIでvulnStatus=Deferredをフィルタする運用にすれば、日々追っているソフトのCVEでDeferredが増えていないか可視化できる。

SCAツールごとに参照元が違う

依存関係スキャナーや脆弱性管理(VM)ツールは、それぞれ独自のデータベースを持つか、複数の情報源を組み合わせている。NVDがリスクベースのenrichment運用に切り替わったとしても、ツールがNVDだけを見ていなければ影響度は変わる。

ツール主なデータソースNVDへの依存度
Snyk独自のSnyk Vulnerability DB（NVD、GHSA、各言語エコシステムのadvisoryを取り込んで再分析）中（独自CVSS・影響範囲を付け直す）
Trivy（Aqua）trivy-db（NVD、GHSA、distro security tracker、エコシステム別advisoryの集約）中〜高（パッケージマッチングでNVDのCPEとdistro advisoryを併用）
Grype（Anchore）NVD、GHSA、distro advisory高（NVDのCPEマッチングが中核）
Dependabot（GitHub）GitHub Advisory Database (GHSA)低（GHSAが一次。NVD由来のCVEもGitHub側で再キュレート）
OSV-Scanner（Google）OSV.dev（GHSA、PyPA、RustSec、Go vulndb等のアグリゲータ）低（パッケージエコシステム別advisoryが優先）

ざっくり言うと、GHSA・OSV経由のツール（Dependabot、OSV-Scanner）は、NIST NVDのenrichment遅延の影響を受けにくい。GHSAやOSVは別チーム・別運営で、CVEに対して独自にパッケージマッピングを付けるためだ。SCA系プロダクトでも、Snykのように再分析して自社DBを持つものは、NVDのDeferredをある程度自前で補える。

一方、NVDのCPEを資産マッチングの軸にしているGrypeや、NVD直参照系のVMツール、社内独自のCVE取り込みパイプラインがNVDだけを舐めている場合は、優先外CVEで取りこぼしが増える側に回る。SuperAGIのCVE-2026-6584のように、AIエージェント基盤やニッチOSSのCVEはこの穴に落ちやすい。

自社の脆弱性管理がどのデータソースに依存しているかは、ツール選定資料のキャッチコピーではなく、trivy-db の更新先、Snyk側のVulnerability Sources設定、Dependabotが使うecosystem-specific advisoryあたりで実際に確認する。

KEVは優先度の強い信号だが全部ではない

実際の悪用が確認されたCVEを集めるCISA KEVは、今回のNVD運用でも明確に優先対象になっている。
悪用済みの脆弱性はCVSSの理論値よりも先に対処すべきであり、優先順位として合理的だ。

ただし、KEVにないCVEを軽く見ていいわけではない。
KEVは悪用確認後の信号であるため、ゼロデイ直後、限定的な攻撃、研究者のPoC公開直後の段階では反映が遅れる。
また、保守者がセキュリティ修正をしたのにCVEを取っていない「silent patch」のケースは、そもそもKEV以前にCVEとして存在しない。

脆弱性管理ツールを提供するAikidoの解説でも「CVEになっていない修正はNVDにも出ない」と指摘されている。
自社製品への誘導は混じっているが、changelogやcommit messageからサイレントパッチを拾う必要性は変わらない。

EUVDとSRPで観測点が増える

NVDの優先順位変更に対し、EU側の情報源としてEUVDが浮上する。
ENISAが2025年5月に公開したEuropean Vulnerability Databaseは、CSIRT、ベンダー、既存DB、CISA KEVなどを束ねて、緩和策やexploitation statusも提供する。NVDをそのまま置き換えるものではなく、ENISA自身も複数ソースの相互接続を前提にしている。

2026年9月11日からは、Cyber Resilience Actに基づき、製品メーカーが実際の悪用や重大インシデントをSingle Reporting Platform (SRP)へ報告する義務も始まる。SRPはEU市場向け製品の報告用システムで、EUVDとは別物だ。

NVDだけが正解だった時代から、KEV・GHSA・OSV・EUVD・SRPが役割を分担して持つ時代に移行しつつある、というのが大局の流れになる。

運用で見直す箇所

NIST NVDが「全CVEを均等にenrichする一次情報源」ではなくなった前提で、確認するポイントを並べる。

  • 自社SCA・VMツールが何を一次ソースにしているか確認（GHSA直 / OSV経由 / NVD直 / 独自再分析）
  • NVDのCPE未付与（hasCpe: false）を「対象なし」と自動で弾かない。vulnStatus=Deferredは別経路で確認するフラグとして扱う
  • CISA KEV入りは即時優先、ただしKEV非掲載を安全判定の根拠にしない
  • 自社で使う重要OSSは、GitHub Advisory・OSV・ベンダーのリリースノートを別経路で追う
  • EUVDはNVDの代替ではなく追加の観測点。EU市場向け製品はSRPの報告義務（2026-09-11〜）にも目を通しておく
  • 定期ジョブで自分が追っているCVEに対してNVD APIを叩き、Deferredへの遷移を検知する仕組みを置く