■概要

2026年6月10日、米国のCISAが新しい運用指令「BOD 26-04: Prioritizing Security Updates Based on Risk（セキュリティアップデートに対するリスクベースの優先度付け）」を発行しました。これは後述する2つの従来ルール（旧 BOD 19-02、22-01）を統合・廃止し、米国連邦機関の脆弱性対応規則を約7年ぶりに全面的に作り替えるものです。

https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk

この内容を端的に述べると、見つかった脆弱性（CVE）を一律に扱わず、実際のリスクに応じて対応速度を変えるルールです。最も危険なものには「3日以内の修正＋侵害調査」を求める一方、低リスクのものは「次回の更新時」まで繰り延べることができ、対応に緩急をつけた内容になっています。また、従来のようにCVSSスコアに応じて対応する方針は今回で完全に廃止されました。

この指令は、今後も増え続ける脆弱性対処の負荷を調整し、限られたリソースの配分を最適化するための考え方が、国家レベルの制度として示されたものと言えます。リスクの高い脆弱性への対応加速だけでなく「今すぐは対処しないもの」を根拠を持って決める仕組みが初めて制度化された点も特徴です。

指令の法的対象は米国の連邦機関ですが、CISAはBOD 26-04の発表にあたり、あらゆる組織にも同様のリスクベースの考え方を脆弱性管理へ取り入れるよう強く推奨しています。本記事の前半では、自組織の脆弱性運用にお悩みの方向けにBOD 26-04の概要を紹介し、その思想・考え方と、脆弱性情報源としてのVulnrichment活用の観点を解説します。後半では、脆弱性情報マニアの方向けに、BOD 26-04を起点に生じるであろう細かい疑問点に対する分析や考察を記載しています。

用語補足説明
・CISA＝米国のサイバーセキュリティ・インフラセキュリティ庁。国土安全保障省の一部門
・BOD＝拘束的運用指令（Binding Operational Directive）。米連邦機関に特定の対応を法的に義務付ける命令
・連邦機関＝本記事では米国の連邦文民行政機関（FCEB）を指す。国防総省・情報機関は対象外
・脆弱性＝本ブログで言う脆弱性は全てCVEが付与される汎用ソフトの脆弱性を指します
・CVSS＝脆弱性の技術的な深刻度を0〜10で表すスコア

■BOD 26-04 発出の背景

CISAはこの指令の狙いを、プレスリリースと解説ブログ「Patch Smarter, Not Harder（賢く、楽にパッチを）」で説明しています。日本企業・組織にもそのまま当てはまる、脆弱性対処に関する状況整理になっているためポイントを3つに分けて紹介します。

https://www.cisa.gov/news-events/news/patch-smarter-not-harder

―ポイント1：最高リスクへの集中と、「繰り延べ」の公式化

CISA長官代行のNick Andersen氏は発表の中で、この指令は「最高リスクの領域へ労力を集中し、優先度の低い脆弱性のパッチ適用は繰り延べる」権限を各連邦機関に与えるものだと明言しています。この「繰り延べ」も指令の肝で「今すぐはやらない」と決めて対処を後回しにすることを制度として認めています。背景には、旧指令の「修正対象の脆弱性は、すべて同じ期限内に」という一律ルールが、既に守られていない現実があります。CISA自身がブログで引用したVerizonの2026年版DBIRによれば、悪用が確認されているKEV掲載脆弱性ですら、完全修正された割合は26%にとどまり（前年38%から低下）、完全解消までの中央値は43日に悪化しました。一律の期限が現場の処理能力を超えて破綻している以上、本当に危ないものへ対処リソースを寄せ、残りは公式に繰り延べを認める、新BODの設計思想はこの一点に集約されています。

https://www.verizon.com/business/resources/reports/dbir/

―ポイント2：AI時代への対応

CISAは「AIが研究者と攻撃者の双方による脆弱性発見を助け、新しい脆弱性が見つかるペースを激増させている」「攻撃者のAI利用は、パッチ公開から悪用までに防御側へ残された時間をさらに狭めうる」と、AIの進化を指令の直接の動機に挙げています。

ここ約10年の脆弱性の増加ぶりをグラフ化したものが図1です。2025年に採番されたCVEは過去最多の約4.5万件。2026年分は7月上旬までにすでに30,393件に達しており、CVSSを管理するFIRSTも2026年6月の中間予測改定で、年間では前年の約1.5倍にあたる約66,000件との見通しを示しています。

そしてここ最近、この伸びがAIの性能進化によりさらに加速する段階に入ったことを示す印象的な出来事が相次ぎました。Mozillaは2026年4月、Firefoxの脆弱性修正数がたった1ヶ月で直前14ヶ月間の合計を超える423件となったことを公表しました。また、様々なオープンソースプロジェクトやバグバウンティの運営にも影響が生じています。AIを利用して発見した脆弱性報告が殺到し、その精査や対処が開発者側で追いつかないという問題が各所で生じています。

https://www.mozilla.org/en-US/security/advisories/mfsa2026-30/
https://hacks.mozilla.org/2026/05/behind-the-scenes-hardening-firefox/
https://www.first.org/newsroom/releases/20260615

―ポイント3：新旧2指令の統合

これまで連邦機関の脆弱性対応は、2本の指令で規律されてきました。1つはBOD 19-02（2019年4月発行）で、インターネットに公開されたシステムの脆弱性を、CVSSの深刻度に応じてスコア9.0以上のCriticalは15日以内、7.0以上のHighは30日以内に修正することを義務付けるもの。もう1つはBOD 22-01（2021年11月発行）で、悪用が確認された脆弱性をCISAがKEVカタログにまとめ、掲載された脆弱性を一定の期限内に修正させるものです。この2本が作り替えられたのは、同じCVSSスコアでも、資産の設置場所や脆弱性の性質によって、悪用されやすさや影響は大きく異なるためです。BOD 26-04は、旧指令で十分に扱えなかったこの差を、対応期限に反映する仕組みへ再編しました。

この統合には、象徴的な意味もあります。CISA自身が実装ガイダンスのFAQで「BOD 19-02の廃止により、連邦機関はもはや脆弱性の優先度付けにCVSSの使用を義務付けられない」と明言しています。長年、連邦政府の脆弱性対応の公式な基準であり続けたCVSSは、優先度付けの役割から正式に退きました。ただしこれはCVSSという仕組みの否定ではありません。CVSSを考案したFIRST自身が「CVSS Baseスコア単独での優先度付けは不適切であり、実脅威や利用環境の情報と組み合わせて使うべきだ」という指針をかねてより出していましたが、その方針に則ったものだとCISAは説明しています。未だにCVSS Baseスコア基準の対処優先度付けを行っている日系組織は珍しくありませんが、この運用を転換する良い機会かも知れません。

https://www.cisa.gov/news-events/directives/bod-26-04-implementation-guidance-prioritizing-security-updates-based-risk

■対応期限を決める4つの変数

ここまでが、指令の背景です。では本題として、新しい期限は具体的にどう決まるのでしょうか。BOD 26-04では、脆弱性と資産の組み合わせごとに、次の4つの判断指標が設けられています。

ここで重要なのは、4つの問いのうち組織が自力で判断しなければならないのは「①資産の公開状況」だけ、という点です。②脆弱性が悪用されKEVに掲載されているかは、CISAが公開するKEVカタログを見れば分かります。そして③悪用自動化可能性と④技術的影響については、BOD 26-04において「CVE IDを持つすべての脆弱性に対してCISAが提供する」と明記しており、そのデータ配信を担うのが後述するVulnrichmentです。組織側の判断ポイントが資産の露出把握に集約されたことで、この枠組みによる判断は運用に落とせる現実的なものになっています。

4指標の組み合わせは16通りで、それぞれに期限が定められています。BODの内容を判断の流れが追えるよう決定木の形に再構成したのが図3です。左から順に4つの問いに答えていくと、右端の対処期限にたどり着きます。

この決定木からみえる思想はシンプルで、リスクの高い一部に対応資源を集中させる設計だということです。最速の「3日＋侵害調査」に該当するのは、16通り中わずか3つ。逆に、公開されておらず、KEVにも載らず、自動化もできない脆弱性は、たとえ完全制御を許すものでも次回更改まで繰り延べてよいとされており、CVSSスコアの高さではなく、露出と悪用の実態が期限を決めます。ちなみに、パッチだけでなく、公開停止やアクセス制限といった緩和策も正当な対処として認められています。

―実際の試算結果について

CISAは解説ブログの中で、ある大規模な連邦文民機関での初期分析として「3日以内の対応が必要な脆弱性は（資産ごとに数えて）約1%にとどまり、60%超は次回更改まで繰り延べ可能だった」と明かしています。この見解について実際に確かめてみましょう。まず、Vulnrichmentに収録された全CVE（7月上旬時点・SSVC判定付き159,792件）を図3の決定木に当てはめ、全資産を「公開されている」と仮定した場合と「公開されていない」と仮定した場合の期限分布を計算しました。図4では、そのうちCVSS Baseスコアを持つ138,114件をCVSS帯別に分け、2つの仮定で期限がどう変わるかを示しています。実際の組織が日々向き合う脆弱性群は、この2つの仮定の間のどこかに位置します。

全159,792件の集計では、公開されていれば約半数（51.6%）に60日以内の期限が付き、8.7%は3日以内（うち0.8%は侵害調査まで必須）です。公開されていなければ76.6%が「次回更改まで」に倒れ、14日以内を求められるのはわずか1.0%です。CISAが明かした「3日以内は約1%、6割超は繰り延べ可能」という数字も、この2つの仮定が張る幅の中に収まる結果です。図4の帯別分布からも、CVSSスコアの高低と、いま直ちにやるべきかは別の問題だということが分かります。個別事例で考えてみても、CVSS 5.3とスコア低めの、例えばCVE-2023-36844（Juniper J-Web）とCVE-2025-4427（Ivanti EPMM）は、悪用と自動化可能の判定があるため、資産の公開状況を問わず「3日＋侵害調査」です。反対に、CVSS 9.0以上のCritical脆弱性でも、非公開資産に存在する場合は3,437件が繰り延べ候補になります。これは昨今のインシデント発生状況と照らし合わせても、納得性の高い結果となっています。

―KEV掲載脆弱性は、より速く

もう1つ、悪用が確認されたKEV掲載脆弱性の対処期限がどう変わるのかも見ておきましょう。図5がその対比です。旧BOD 22-01下で実際に設定されていた期限は「掲載から21日以内」が中心で全体の64%。次いで14日が17%、初期一括登録の古いCVEを中心とした約6ヶ月の枠が16%、緊急の数日案件が3%でした。同じ対象を新制度で、資産をすべて公開と仮定して振り分けると、83%が「3日＋侵害調査」、8%が「3日」、残る9%も14日----最長でも14日を超えません。逆に、すべて非公開と仮定しても、31%は「3日＋侵害調査」のまま、残る69%も14日以内に収まります。低リスク側を大胆に繰り延べる代わりに、悪用が確認された脆弱性には従来より遥かに速い対応を求める。「危険なものほど速く」の思想が数字に表れています。

■Vulnrichmentについて

「Vulnrichment」は脆弱性判断指標の②KEV掲載、③自動化可能性、④技術的影響について、CISAがCVE IDを持つ脆弱性の分析結果情報を無償配布しているデータ群です。もともとは2024年5月に始まったプロジェクトでした。しかし、BOD 26-04が③と④を「CISAが提供する」と明記し、Vulnrichmentがその配信を担うようになったことで、指令を支える正式な基盤へと位置づけが変わりました。BODの対象でない企業でも使えるため、これを日々参照する脆弱性情報源に加えることもおすすめです。

https://github.com/cisagov/vulnrichment

―使用方法について

Vulnrichmentのデータは上記GitHubの公式リポジトリで、CVE番号ごとにJSONとして公開されています。自組織で発生したCVEの判定を見て、場合によってはBODの優先度付けに照らし合わせてトリアージしてみるとイメージが湧きやすいかもしれません。より簡単な使い方としては、お使いの生成AIへ気になるCVE番号と「Vulnrichment情報をもとにしたBOD 26-04基準の判定をよろしく」と依頼すれば、最新情報へアクセスして回答してくれます。筆者が2026年7月に主要なAIアシスタントで試したところ、ChatGPT・Microsoft Copilot・Claudeは、マイナーなプラグインやOSSライブラリの新しいCVEでも、URLを渡すだけでSSVCの3判定を正確に読み取りました。ただしGeminiは、デフォルト状態ではGitHubリポジトリを読めないようで、正確な値を返しませんでした（2026年7月時点）。

―情報源としての信頼性について

Vulnrichmentは情報掲載が遅く、網羅性も低い、という印象の方もいらっしゃると思います。米国では2026年6月にも、あるセキュリティ研究者が「全CVEの45.8%しかカバーしていない」とする批判を公開しています。かく言う私自身も本記事の執筆にあたり分析し直すまでは、2024年のプロジェクト開始当初の印象のまま、ソースとしての信頼性に疑問を持っていました。しかし、現在は速度・網羅性ともに大きく改善されている事がわかります。全CVEレコードの一次配布元であるcvelistV5の全363,322レコードを分母にとり、どれだけカバーできているかを年別に算出してみました（図6）。

https://github.com/CVEProject/cvelistV5

結論から言えば、45.8%という数字は2021年以前の古いCVEまで含めた全期間の平均であり、直近だけを見ると様相は一変します。CVE-IDの年で見て、2024年は97.2%、2025年は90.6%、2026年は88.8%で、しかもこの分母には取り消し済みのレコードまで含まれるため、有効なCVEに限った実際の網羅率はさらに高くなります。速度の面も、2026年に公開されたCVEでは、公開からCISAの判定が付くまでが中央値0.6日、9割が3日以内に収まっています（月によっては、遅い側の1割が4〜5日程度まで伸びることもあります）。掲載も遅く、情報も不足しているという初期の印象のままの方は、認識のリセットをおすすめします。

■関連ガイド：外部公開資産の把握と脆弱性管理の基礎

今回のトピックに関連する2つのガイドを参考としてご紹介させていただきます。

―簡易ASM実践ガイド

自組織のどの資産が外部に公開されているかを把握することはBOD 26-04において非常に重要な取り組みとなっています。以下記事ではShodanの無償アカウントを使い、自社ドメイン、組織名、IPアドレスから外部公開資産を洗い出す手順を紹介しています。侵入経路になりやすい公開ポートや、攻撃対象になりやすい機器を優先して確認する検索例も掲載しており、専用のASM製品を導入する前の初期調査や予算不足の方でも参考にしていただける構成としています。

https://security.macnica.co.jp/blog/2025/02/asmattack-surface-management.html

―脆弱性対処関連の基礎情報解説

本ブログの内容が難しく理解が追いつかない場合、より基礎的な内容を解説した記事を以下で公開しています。CVSSスコアだけで脆弱性対処の優先順位を決めることの課題と、実際の悪用状況や資産の性質を含めたリスクベース運用への移行を解説しています。

https://mnb.macnica.co.jp/2024/07/asm/priority.html

■まとめ：「やらないこと」も重要

米国で新しい脆弱性対処の基準が出たので参考になるかもしれない、Vulnrichmentという無償の脆弱性情報源がある----この2点が本記事の重要な要旨です。BOD 26-04を「3日以内対応」という見出しだけで受け取ると、脆弱性対応の一層の加速を求める指令に見えます。しかし実データが示すのは逆の側面です。仮に全ての資産が公開されているとしても、最速の「3日＋侵害調査」が必要なのはわずか1,346件（0.8%）。逆に、公開されていない資産なら122,457件（76.6%）は即時の期限を課されず、次回更改まで繰り延べ可能となり、後回しにする根拠が公式に与えられました。この指令の本質は対応加速というよりは、限られた対応リソースの再配分にあると考えます。

日系組織の脆弱性管理では、検出された脆弱性をすべて管理台帳に載せ、すべてに対応目標を設定し、その消化率を指標にする----いわば「全部やる」型の運用が、今も主流だと感じています。この運用が普及した2010年代は、脆弱性数も守るべき資産数も現在より少なく、何とか回せていたのかもしれません。しかし現在は脆弱性数も増え、我々を取り巻く脅威状況も複雑化する中では非現実的な状況となっています。現実に即さない目標は「真に対処すべき1%への対応を、他の99%の作業のために遅らせる」ことになりかねません。

これからの脆弱性対処や組織のセキュリティ運用の成熟度は「どれだけ多く対処したか」ではなく「何を『やらない』と根拠を持って決められるか」で測られるようになると考えています。やらないと決めた分のリソースを、緊急脆弱性対応や侵害調査、脆弱性以外のセキュリティ対策・検討に振り向けることこそが、この指令から日本企業が持ち帰るべきメッセージであるとも感じます。

そして同じことは、フロンティアAIの文脈で次々に登場する新しい脅威論にも言えます。すべてに反応するのではなく、自組織にとって本当にやるべきものは何かを厳選する----BOD 26-04から学ぶべきなのは、まさにその姿勢だと思います。

実務上のポイントは以上です。ここまでお読み頂きありがとうございました。以降は主に脆弱性マニアの方向けのかなり細かい情報となるため、関心のある方のみ引き続きお楽しみください。

■BOD 26-04を起点に生じる疑問点まとめ

ここから先は補足のショートQ&A集です。BOD 26-04やVulnrichmentに関して気になるであろうポイントを、いくつか整理してご紹介します。気になる項目だけ拾い読みで構いません。

―Q1. SSVCとの類似性について

SSVCと似てるなという感覚は正しいです。SSVCは、脆弱性の状況を数点の問いで評価し、対応を4段階の行動に振り分ける意思決定フレームワークで、使う人の立場ごとに複数の決定木が用意されています。なかでも企業がパッチ適用の優先度を決めるための「Deployer（適用者）」向けの木は、①悪用状況（なし／PoCあり／悪用中）、②システムの露出（小／限定／公開）、③自動化可能性（可／不可）、④人的影響（低〜甚大）の4点を評価します。その結果を、Defer（延期）／Scheduled（定期対応）／Out-of-Cycle（定例外で前倒し）／Immediate（即時）の4段階に振り分けます。BOD 26-04を見返すと、資産露出状況・攻撃自動化可否・影響を組み合わせて対応の緊急度を決める骨格は、このDeployer木とほぼ重なります。それもそのはずで、SSVCはカーネギーメロン大SEI/CERTとCISA自身が共同開発したものであり、指令解説ブログの共著者Jonathan Spring氏はSSVCの開発者その人です。つまりBOD 26-04はSSVCに「似ている」というより、同じ作り手・同じ思想から生まれた直系の後継と言えます。

https://www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc

―Q2. なぜ既存のSSVC Deployer木をそのまま使わなかったのか？

BOD 26-04は、既存のSSVC Deployer木とは異なります。なぜSSVCをそのまま採用しなかったのかは公表されていないため独自解釈となりますが、「各自が自組織向けに調整して使う枠組み」を「全連邦機関が一律で従う規則」に変えるにあたり、2つの割り切りをしているように見えます。1つ目は、判断材料の入れ替えです。Deployer木にあった人的影響----その脆弱性が組織のミッションや人命にどれだけ響くかは、各組織が自分で評価する必要があり、答えがぶれます。BODはこれを外し、機械的に判定できる「技術的影響（完全／部分）」に差し替えました。同じく露出状況とKEV掲載を組み合わせて、誰がやっても同じ答えが出る形に整えています。全連邦機関で共通運用する規則にするには、同じ入力から同じ結論が出る構造が重要だったのではないかと考えられます。

そして2つ目は、悪用状況の3値（なし／PoCあり／悪用中）を悪用なし／ありの2値に畳み、SSVCには存在した「PoCあり」という中間状態を判断材料から外しました。この理由は次のQ3で述べますが、ここではBODとSSVCの違いを実データで見てみたいと思います。2025年に採番されSSVC判定が付いたCVE 40,570件を、SSVCのDeployer木とBOD 26-04の両方で評価し、判定を突き合わせました（図7）。ただしDeployer木の「人的影響」と、両モデルの露出は、実データに無いため資産の性格を想定した仮定値です。ここでは対照的な2つの試算結果を抜き出して比較しています。

結果は、BODの設計思想をよく映しています。外部公開された重要サーバ（シナリオX。ここでは影響度が高い資産を想定）では、SSVC Deployer木は91%を「定期対応（Scheduled）」、9%を「前倒し（Out-of-Cycle）」と判定します。同じ集合をBOD 26-04で評価すると、60日が53.4%、14日が38.4%、3日が7.9%、3日＋侵害調査が0.4%となり、すべてに60日以内の期限が付きます。反対に、隔離された低影響の内部資産（シナリオY）では、SSVCは76%を「延期（Defer）」、BODは76.1%を「次回更改」とし、大勢は一致します。BODが露出・悪用・影響の高い一部へ資源を集中させ、それ以外を大胆に緩める設計であることが、Deployer木との差としても確認できます。

―Q3. なぜ「PoCあり」は判断に使われないのか？

SSVCとBODの両方で、脆弱性の悪用状況は重要な判断指標となっています。SSVCでは「PoCの公開」は悪用の一歩手前として、対処を促す指標となっていました。しかしBOD 26-04ではPoCの有無は判断に関与しません。公式な理由は明かされていませんが、PoCの有無は対処優先度の指標にすべきでない、という判断があったのだと考えています。その背景として、次の事情を考察しています。

まず、量の問題です。実際に悪用が確認されている（悪用中）CVEは1,633件、全体のわずか1.0%。対して「PoCあり」は37,270件、23.3%と、実に23倍の規模があります。仮にこれを期限のトリガーに使ってしまえば、3日対応の運用は連邦政府の体制でも立ち行きません。

次に、中身です（図8左）。SSVCにおける「PoCあり」は、必ずしもそのCVE専用の実証コードが公開されていることを意味しません。SSVCでは、公開PoCが存在する場合だけでなく、悪用方法が広く知られている場合も「Public PoC」に分類します。SSVCの公式資料では、CWEだけを根拠に「Public PoC」と判定し得る例として、XSS（CWE-79）やSQLインジェクション（CWE-89）も挙げられています。つまり、これらの脆弱性は、個別のPoCへのリンクがなくても、脆弱性種別そのものを根拠に「PoCあり」と判定され得ます。

実際、「PoCあり」37,270件の内訳では、SQLインジェクションが15.4%、XSSが13.2%を占め、筆者分類ではWeb系の脆弱性が過半に達しました。一方、ExploitDB、Packet Storm、MetasploitモジュールといったハイリスクなPoCや武器化済みexploitなどへの直接リンクを持つものは、合わせても8.0%（2,996件）にとどまります（他は参考情報や実PoCなどの情報が入り混じっています）。このため、Vulnrichmentの「PoCあり」は、そのCVEを攻撃する実物のコードが出回っている、という意味ではありません。実物の存在を確認できるものは一部にとどまり、悪用のやり方が広く知られているだけのものまで含んだ、かなり広い判定だと理解してください。

そして重要なのが、採番経路による判定差です。例えば、WordPressプラグインの脆弱性を扱う採番機関（CNA）は複数ありますが、WPScan経由で採番されたXSSではPoCあり判定が86%だった一方、Patchstack経由では筆者集計上0.5%にとどまりました（図8右）。対象製品や公開時期などの差を除いた因果分析ではありませんが、同じXSSでもPoCあり判定率に約170倍の差がありました。少なくともこの判定は、脆弱性そのものの危険度だけでなく、CNAごとの開示方針や参照情報の付け方にも強く影響されると考えられます。つまりこの判定は、攻撃者の動向の観測値ではなく、開示文化の測定値とも言え、それを対処のトリガーとすることには違和感が生じます。

そして、時間軸の問題もあります。攻撃を実証するPoCがあるという場合でも、中身は玉石混交で、条件の複雑さなどから実際には悪用されないケースも多く存在します。こうしたものを指標に入れても、行動につながらないノイズが増えるだけです。逆に、本当に使えるPoCが公開された場合、ここ数年は攻撃者側が公開情報を即座に武器化するため、実用的で脅威度の高いPoCはしばしば公開から数時間～数日のうちに悪用が始まります。そうしたPoCの影響は、ほどなく「悪用中」としてKEVに現れることになります。ノイズが大半で、かつ本当に危ないものは結局KEVに現れる----それなら、PoCの有無という中間指標を独立して見張る意味は薄い、という見方も考えられます。
※すでにPoCを自組織の警戒シグナルとして使われている場合はそれを否定する意図はありません。特に各PoCの動作や構造を分析し、将来の実害発生リスクを測り優先度を決定している場合は是非それを継続してください。

―Q4. 脆弱性の悪用自動化可能性や技術的影響の値の判定方法は？

本編で見たとおり、Vulnrichmentにおける各脆弱性の分析は速度・網羅性とも実用水準にありました。残る疑問は、BOD 26-04の肝になっている「悪用自動化可能性（Automatable）」と「技術的影響（Technical Impact）」の2つの値がどう作られているかです。各値の定義や一般的な判断基準はSSVC資料で公開されていますが、CISAがVulnrichmentで個々のCVEをどの情報源・証拠・手順に基づいて判定しているかという詳細な手法は未公表です。

そこで、実データからある程度推し量ってみます。自動化「可」とされたCVEの96.3%は、CVSSベクタのAV:N/PR:N/UI:N----「ネットワーク経由で・権限不要・利用者の操作も不要」という3条件と一致し、「完全制御」の81.4%は機密性・完全性・可用性がすべてHighのものと一致していました。多くの場合（8割方）はCVSSの各項目から機械的に導かれ、残り2割ほどに人の判断やその他ロジックが入っている、と見るのが実態に近そうです。BitSight社でも同様の分析結果を公表しています。

https://www.bitsight.com/blog/do-we-need-yet-another-vulnerability-scoring-system-ssvc-thats-yass

―Q5. NVDはどうなった？

これまで、脆弱性情報の参照元のデファクトはNVD（米NISTのNational Vulnerability Database）でした。CVEに独自のCVSSスコアやCPE（製品識別子）を付け、多くのツールが参照する事実上の標準データベースとして20年機能してきた存在です。ところがそのNVDでは、ご存知の通り、2024年初頭から分析の遅れが慢性化しています。予算や分析体制の不足、CVE件数そのものの急増が要因として報じられ、2026年4月15日には、すべてを分析するのではなく、優先度の高いものだけを処理する方式への移行を正式に表明しました。今後、完全な分析（CVSSやCPEの付与）を行う対象を、KEV掲載済み・連邦政府利用・重要ソフトウェア（大統領令14028が定める、OSやブラウザなどシステム権限を持つ基盤的ソフトウェア）等の優先対象に絞る方針へ移行しました。複数の第三者推計では、完全分析の対象は今後発行されるCVEの15〜20%と試算されています。

https://www.nist.gov/news-events/news/2026/04/nist-updates-nvd-operations-address-record-cve-growth

このNVDの劣化状況を実測で確かめたのが図9です。NVDが独自にCVSSを付けた割合は、2023年時点の92%から直近の2026年6月には13%まで低下し、CPEもほぼ100%から47%へ落ち込んでいました。とりわけCPEは、大半のCNAが自分では付けておらずCNA側が記載していたのは1割強にとどまり、事実上NVDが一手に生成してきたものです。なお、後述するVulnrichmentも、CVSSは補うものの、このCPEは埋めていません。

用語補足説明
・CNA＝CVE Numbering Authority。CVE番号の割り当てと、脆弱性情報を記載したCVEレコードの公開を担う認定機関
・CPE＝Common Platform Enumeration。ベンダー名・製品名・バージョンなどを機械可読な形式で識別するための標準表記。NVDでは脆弱性と影響を受ける製品をひも付けるために使われる

ちなみに、NVDの仕事は単なる穴埋めだけではありませんでした。ベンダーやCNAがCVSSスコアを付けている場合でも独自に採点し直し、食い違えばNVD側の解釈を表示する、CVSSのセカンドオピニオン組織としても機能してきました。この独自採点はスコアが高く出がちだったため軋轢も生み、ベンダーや開発者からの反発も珍しくありませんでした。しかし今後は前述の方針転換に伴い、NVDはCNAが既にスコアを付けたCVEには独自採点を行わなくなります。この独自採点は摩擦の火種でしたが、同時に、業界がほぼ唯一頼れる検証層でもありました。その機能が、いま失われつつあります。

では、NVDが埋めなくなった空欄は、いま誰が埋めているのか。ここでもVulnrichmentが価値を発揮しており、CVSS・CWEの補完を行っています。ただしそのやり方は、かつてのNVDとは対照的に控えめです。CNAがスコアを提供していない場合に限って不足分を補い、CNAのデータは決して上書きせず、CNAが後から提供すれば自らの評価を取り下げます。訂正や検証には踏み込まず、空欄を埋める役に徹しているわけです。図10は、CVE採番数の多い上位15のCNAについて、各CNAが採番した脆弱性のCVSSを誰が提供しているかを示しています。

ChromeやAppleなど著名な製品であっても、実はCNA自身ではなくCISAが情報源となっていることがわかります。CISAがCVSSを埋めている件数が多い製品ランキングは、以下の図11の通りです。

ちなみに、2026年6月中旬から、NVDのAPIが返すデータに「ssvcV203」というフィールドが加わり、CISAのSSVC判定データ（Exploitation・Automatable・Technical Impact）が格納されるようになりました。通常の個別ページのメトリクス欄には表示されませんが、API/feedsで構造化データとして取得できます。Webサイト側ではChange History欄にSSVC JSONが表示される場合があります。つまり、すでにNVDを日々見ている方は、参照先を増やさなくても、NVD経由でVulnrichmentの判定をそのまま受け取れます。本節で見たとおり、NVDに載る判定値自体、いまや相当部分がCISA由来です。NVDが自ら大量の脆弱性を分析する時代は終わりつつあり、CISAの判定を運ぶ窓口に近づいている、というのが実情です。

―Q6. 自組織で使うなら、SSVCとBODのどちらがよい？

まず前提として、BOD 26-04とSSVCは別物というより地続きです。Q1で見たとおり判断の骨格は共通で、SSVCが組織ごとに木を調整して使える汎用の枠組みであるのに対し、BODはそれを連邦機関向けに一本の決定木と固定期限に落とし込んだ運用ルール、という関係にあります。そのうえで、自組織で採り入れる観点から、それぞれの特徴を並べてみます。

SSVC（パッチ適用者向けのDeployer木）の特徴は、自由度の高さです。悪用状況・システム露出・自動化可能性に加えて、「その脆弱性が自組織のミッションや人命にどれだけ響くか」という人的影響まで、資産ごとの評価に織り込めます。自組織の事情を細かく反映した優先順位を組める反面、判断項目が多く、それぞれの値を自力で決められるだけの評価体制が求められます。とりわけ人的影響は、公開データには存在せず、組織が自ら判断するほかありません。Q2で整理したとおり対処までの猶予は長めに出るケースが多いです。

BOD 26-04の特徴は、シンプルな構成から来る判断のしやすさです。指標は4つに絞られ、そのうち3つ（KEV掲載・自動化可能性・技術的影響）はCISAの判定（Vulnrichment）をそのまま使えます。組織が自力で答えるのは「その資産は公開されているか」だけです。人的影響のような主観的な評価軸は持たないため、誰が判定しても同じ結論になり、監査にも馴染みます。一方で、資産ごとの重要度を優先順位に反映させる余地は小さく、判定の粒度は粗くなります。しかし、対処要請速度はSSVCより早めに出がちです。

整理すると、自組織の文脈を細かく反映したいならSSVC、判断材料が揃っていて手早く一貫した優先順位を出したい、より厳しくリスクに向き合うならBOD、という違いになると感じます。

―Q7. AI進化で脆弱性数が増えても、パッチ提供や攻撃頻度が変わらなければ今までと同じでは？

本編では、AIによって発見される脆弱性数が増えていると述べました。しかし、利用者へ届くパッチや実際の攻撃が増えなければ、脆弱性管理の実務負荷は今までと大きく変わらないのでは、という疑問もあります。少なくともパッチについては、その前提はすでに崩れ始めています。各社で増えるものは同じではありませんが、パッチの提供頻度、1回当たりの修正量、利用者側に求められる適用速度のいずれかが、すでに引き上げられています（図12）。この4社だけでも、利用者側の負荷が増える経路は一つではありません。F5とAdobeは提供・公開の頻度と修正量、Oracleは提供頻度、Microsoftは1回当たりの修正量と顧客側に求める適用速度の推奨を引き上げています。

https://www.f5.com/company/blog/release-cadence-security-notifications-frontier-ai
https://blog.adobe.com/security/protecting-customers-faster-how-adobe-is-responding-to-ai-accelerated-vulnerability-discovery
https://blogs.oracle.com/security/accelerating-vulnerability-detection-and-response-at-oracle
https://blogs.windows.com/windowsexperience/2026/07/09/evolving-windows-vulnerability-management-to-meet-the-speed-of-ai-powered-discovery/
https://gblogs.cisco.com/jp/2026/06/strengthening-the-foundation-a-predictable-customer-focused-response-to-ai-accelerated-vulnerability-discovery/
https://www.redhat.com/en/blog/strengthening-open-source-supply-chain-red-hat-partners

次に、ゼロデイや脆弱性を悪用した攻撃の頻度についてです。これは完全に筆者個人の予想となりますが増加は不可避であると考えています。ただし、低スキルの攻撃者までがAIを使って次々にゼロデイを開発する、という姿を想定しているわけではありません。従来も、ゼロデイ脆弱性の発見や実用的な攻撃手法の開発・供給元は、高度な技能と資源を持つ限られたグループ（および一部の行き過ぎたセキュリティ研究者）に偏っており、そこで生まれた手法の一部が、販売・流出・模倣などを経てより広い攻撃者層へ拡散するケースが多かったと見ています。

AIがまず押し上げるのは、この上流にいる高度なアクターの探索・解析・悪用開発の生産性でしょう。同じ期間に発見・解析・武器化できる脆弱性が増えれば、新しい攻撃手法が下流へ供給される機会も増えます。一方、経済合理性を重視する大多数の攻撃者にとって、未修正の古い脆弱性や管理不備を抱えた機器は世界中に溢れており、攻撃対象はいわば供給過多の状態です。ゼロデイなど使わずとも侵入経路には事欠かない以上、自ら研究に投資する動機は乏しく、今後もこうした安価で確実な手段を使い続けつつ、稀に上流からのおこぼれに与る。この構造は変わらないと考えています。

パッチ側ではすでに提供・適用周期の短縮が始まり、攻撃側でも高度なアクターの生産性向上を通じて、まもなく実用的な悪用手法の供給が増えると考えられます。AIでCVEが増えても実務は今までと変わらない、とは考えにくい状況です。だからこそ、すべてを同じ速さで処理するのではなく、現実のリスクに応じて対応を選別するリスクベースの脆弱性対処が、これまで以上に重要になります。

以上です。書いた本人でも読んでるうちに脳が辛くなる情報が続きましたが、最後までお読み頂きありがとうございます。