NISTがNVDを縮小:どのコンテナセキュリティプログラムを再評価すべきか

投稿日: 5月 13日, 2026年

4月 15日、NISTは国家脆弱性データベースの優先強化モデルを発表しました。ほとんどの CVE は引き続き公開されますが、コンテナスキャナーやコンプライアンスプログラムが歴史的に頼ってきた CVSS スコア、CPE マッピング、CWE 分類を受け取るものは減少します。

この変更により、過去2年間NVD映像を取得している誰もが目についていたドリフトが正式に示されました。4月 15 日に変化したのは期待です。NISTはフルカバレッジ濃縮に戻る意向がないと明確に表明しました。NVDがCVEの上にある権威ある二次層として位置するという前提でスキャン、優先順位付け、SLAワークフローを構築したプログラムにとっては、その前提は構造化されたレビューに値します。

何が変わったのか

CVEの3つのカテゴリーは引き続き完全な強化を受けます。

  • CISAの既知の悪用脆弱性カタログにおける1営業日以内の標的となるCVE
  • 連邦政府で使用されるソフトウェアに影響を与える CVE
  • 大統領令で定義される「重要なソフトウェア」に影響を与えるCVE 14028

それ以外のすべては「予定なし」ステータスに移行します。組織は nvd@nist.gov にメールで充実を依頼できます。ただし、サービスレベルのタイムラインは適用されません。NISTはまた、提出したCNAがCVSSスコアを提供した場合の重複を停止しており、3月 1日以前に公開された未強化のCVEはすべて「スケジュールなし」に移行 2026 。

NISTの決定の背後にいる

NISTは、2020年から2025年までのCVE提出件数が263%増加し、Q1 2026は前年同期比で約3分の1増加したと指摘しています。この増加は、CVE番号の拡大と一致しています。CNAの増加、独自の開示プロセスを運営するオープンソースプロジェクトの増加、そして数年前にはCVEには届かなかった問題が浮上するツールの増加です。

公開されたCVE

出典

2023

~29、000

CVE.org

2024

~40、000

CVE.org

2025

~48、000

NIST

2026 (予報)

~59、500 (中央値)

AIはこの曲線の両側で複合的な要素です。1月、Curlの創設者ダニエル・ステンバーグは、6年半続いたプロジェクトのHackerOneバグバウンティを 停止 しました。理由は「千のスロップによる死」です。これは、AI生成の報告書で、本物の研究のように見えながら存在しない脆弱性を記述していました。Node.js、Djangoや他の企業も同様の圧力の中で人材を厳しくしています。注目すべき点としては、Anthropicが4月に発表したClaude Mythos Previewは、FreeBSDのNFSサーバーに存在する 17年前の認証されていないRCEを含む、主要なOSやウェブブラウザで数千のゼロデイ脆弱性を自律的に発見するモデルを説明しました。以前の人類学的研究では、クロード・オープス・ 4が記録されています。6 、本番環境のオープンソースで 500 以上の重大度の高い脆弱性を発見し検証すること。

より多くのノイズとより多くの実際の信号が同じパイプラインに向かっています。NISTは2025年に約42000の価値機関を増やし、年間最多を記録しましたが、それでも輸入量にはさらに遅れをとりました。

コンプライアンスに到達する方法

運用上の問題は、NVDスコアリングが利用できない場合に、どのプログラムが文書化すべきか、そしてその文書が評価全体でどれだけ一貫して機能するかです。

フレームワーク

NVDリファレンス

影響の可能性

FedRAMP

NVD CVSSv3 オリジナルリスク評価として、CVSSv2 とネイティブスキャナースコアが文書化されたフォールバックとして記載されています

CSP間で修復SLAの適用方法にさらなる違いが増えました

PCI-DSS 4。0

113。2外部スキャンはCVSSを参照;ASVの指示はNVDを指しています

無得点の結果に対する合格・不合格判断の曖昧さが増す

NIST SP 800-53 (RA-5)

NVDを例のソースとして挙げています。寛容な言語

直接的な影響は低いですが、監査人は一般的にCVSSに基づく重症度の証拠を期待します

ドーラ / SOC 2

直接的な言及はありません

原則に基づく;深刻度に関する監査の期待は依然として適用されます

これらの枠組みは自動的に崩れるものではありません。成熟した脆弱性管理プログラムは、一般的にSSPやリスクレジスタにフォールバックスコアリングや例外処理に関する文言を含んでいます。そうでないプログラムは、次の監査サイクルまでに必要になる可能性が高いです。

コンテナエコシステムに関連するギャップ

コンテナスキャンにおいて最も重要な2つのNVD入力があります:

  • CPE適用性ステートメントは 、CVEを特定のソフトウェアパッケージにマッピングします。CPE文字列が欠落している場合、主にCPE上で一致するスキャナーは、画像内のどのパッケージが影響を受けるかを特定できません。CVEはデータベース内に存在しますが、スキャンには操作上見えません。
  • CVSSスコアは 優先順位付けやSLAルーティングを推進します。スコアがなければ、CVEは不明の重大度として表示されたり、修復ワークフローの対象外に完全に除外されることがあります。

コンテナのイメージがここで複合的な効果を生み出しています。各イメージはベースレイヤーからパッケージ、アプリケーション依存関係、そして多くの場合、長い推移依存チェーンから継承されます。これらのパッケージのいずれかにNVDが強化されていないCVEを持つ場合、そのギャップは上に構築されたすべての下流イメージに伝わります。複数のアドバイザリーソースを利用し、CPE以外のパッケージ識別子で一致するスキャナーは、リスクが低いです。

画像販売業者に尋ねる価値のある質問

  • NVD以外に、あなたのツールはどのようなアドバイザリーソースを使っていますか?
  • CVEにNVD CVSSスコアがない場合、ツールは何を表示し、修復ワークフローをトリガーするのでしょうか?
  • 「パッチ適用」とはどのように定義しますか?また、その定義はあなたの書面によるCVEポリシーに含まれていますか?
  • あなたの修復SLAはCVE開示日から測定されますか、それともNVD強化日から計測されていますか?
  • 第三者のスキャナーがあなたのクリーンスキャン結果を公開アドバイザリーデータと照合して再現できますか?

Dockerが置かれる場所

Docker Hardened Imagesは、コンテナワークロードにおける脆弱性管理が主にNVDエンrichmentに依存しないように設計されています。各画像にはビルドの出所に関する署名付き証明、CycloneDXおよびSPDX形式のSBOM、OpenVEXのエクスプロイタビリティステートメント、スキャン結果が付属しています。SBOMは外部データベースから推測されるのではなく、SLSAビルドレベル 3 パイプラインから生成されるため、NVDのエンリッチメント状態に関わらずパッケージインベントリは正確です。ハードンドシステムパッケージは、上流の配布タイムラインに依存しないパッケージレベルのパッチ適用を可能にし、これにより修復は配布管理者のリリース頻度やNVDアナリストのキューに制限されません。特定の画像文脈で悪用できない場合、その評価は署名済みのVEX文書として公開され、Trivy、Grype、Wizなどのサードパーティスキャナーがネイティブに利用します。

これらの証明を読み取るスキャン層であるDocker Scoutは、NVD、CISA KEV、EPSS、GitHub advisory Database、13Linuxディストリビューションのセキュリティトラッカーなどのアドバイザリーソース22集約します。スカウトマッチは、CPE文字列が利用できない場合でもパッケージ識別を継続できるNVDのCPE方式ではなく、パッケージURL(PURL)上で行われます。NVDはこのアーキテクチャにとって依然として重要な入力であり、背骨ではなく複数の要素の一つです。

再評価すべき点

監査は3月の3月 1、 2026 の締め切りに対して調査結果を公開しています。その日以前に公開されNVD強化を受けていないCVEはすでに「スケジュールなし」に移動されています。これらの CVE に結びついたオープンな発見を持つプログラムは、トラッカー内の重症度スコアや CPE マッピングが、もはやアクティブなNVDレコードを反映しなくなることがあります。これらの発見のスコアリング基準がNVDとは独立して文書化され、正当化可能であることを確認しましょう。

DHIを運用するプログラムの場合、NVDの方針変更は運用上の対応を必要としません。コンテナセキュリティベンダーをより広く評価するプログラムにとって、次の調達サイクルで注目すべきは、NVDがスタックにおける脆弱性インテリジェンスの一つなのか、それとも主要な情報源なのかということです。

NVDは今後も役割を果たし続けるでしょう。その役割は狭まっており、今後も狭まり続ける兆候が示唆されています。4月の発表をきっかけにデータソースを監査するプログラムは、規制当局や監査人、委員会が脆弱性データの実際の出所を尋ねた際には、より明確な答えを得られるでしょう。

出典とさらなる参考文献

関連記事