BOD 26-04 とは｜KEV と外部公開で決まる対応期限の読み方

はじめに

脆弱性管理の現場では、CVSS スコアの高い順に並べたリストが積み上がり、対応が追いつかない状態が常態化しています。スコア 9.8 の脆弱性が 100 件並んでいるとき、どれから手を付けるべきかをスコアだけで判断することはできません。閉域網の検証機と、インターネットに露出した認証基盤では、同じスコアでもリスクの実態が異なるためです。

この課題に対して、米国 CISA は 2026 年 6 月 10 日、拘束的運用指令 BOD 26-04「Prioritizing Security Updates Based on Risk」を発出しました。CVSS スコアを優先順位付けの主軸から外し、外部公開・KEV 掲載・自動化可否・技術的影響という 4 つの二値判断で対応期限を決める方式へ転換する内容です。

本指令の法的な適用対象は米国の連邦民間行政機関（FCEB）であり、日本の組織に直接の義務は生じません。ただし、KEV カタログが適用対象外の組織にも広く参照されてきた経緯を踏まえると、この 4 変数モデルも同様に事実上の参照基準となる可能性があります。重要なのは、4 変数のうち 3 つは公開データから機械的に取得できる一方、残る「外部公開の有無」だけは自組織の資産管理能力に依存するという構造です。

BOD 26-04 の概要と従来指令からの変更点

BOD 26-04 は、脆弱性の深刻度ではなく、その脆弱性が置かれている状況を基準に対応期限を決める指令です。従来の 2 つの指令を統合・廃止し、単一のリスクベースモデルへ集約しています。

BOD 19-02 / BOD 22-01 の廃止と統合

BOD 26-04 は、2019 年 4 月 29 日発出の BOD 19-02「Vulnerability Remediation Requirements for Internet-Accessible Systems」と、2021 年 11 月 3 日発出の BOD 22-01「Reducing the Significant Risk of Known Exploited Vulnerabilities」を廃止・置き換えるものです。

それぞれの旧指令が定めていた期限は次のとおりです。

旧 2 指令に共通していた課題は、脆弱性そのものをリスクの単位として扱い、それが存在する資産の状況を考慮していなかった点にあります。BOD 26-04 はこの点を修正し、同じ CVE であっても資産の公開状況によって期限が変わる設計を採用しました。

もう 1 つの変更点として、BOD 22-01 には対応を見送る仕組みがありませんでした。KEV に掲載された脆弱性はすべて対応対象です。BOD 26-04 では、4 つの条件をいずれも満たさない脆弱性について「次回のシステムアップグレード時に修正する」という区分が新設されました。限られた対応リソースを、実際にインシデントにつながり得る脆弱性へ集中させるための設計です。

CVSS が優先順位付けの主軸から外れた理由

BOD 19-02 の廃止により、FCEB では脆弱性の優先順位付けに CVSS を用いることが義務ではなくなりました。CISA は実装ガイダンスの中で、その理由を明示しています。

参考: BOD 26-04 Implementation Guidance（CISA）
“CVSS scores such as “critical” or “high” do not prescribe specific actions.”
（「critical」や「high」といった CVSS スコアは、具体的な行動を指示するものではない）
https://www.cisa.gov/news-events/directives/bod-26-04-implementation-guidance-prioritizing-security-updates-based-risk

ここで示されているのは、CVSS を否定する立場ではなく、スコアと行動の間にある曖昧さを排除するという意図です。CISA は同ガイダンスで、CVSS にも脆弱なシステムへの影響（Technical Impact に相当する情報）が含まれ、脅威メトリクスは KEV 掲載の有無に関連し、Automatable は CVSS v4 の補足メトリクスとして存在すると整理したうえで、ラベルを明示的な対応期限に置き換えたと説明しています。

この方針は、FIRST の CVSS SIG が示す利用者向けガイダンスとも整合するとされています。CVSS の Base スコアは脆弱性の技術的特性を表す指標であり、それ単体で優先順位を決める用途は本来想定されていません。BOD 26-04 は、この本来の使い方に立ち返ったうえで、脅威情報と環境情報を組み込む枠組みを SSVC（Stakeholder-Specific Vulnerability Categorization）に求めた形になります。

背景として CISA が挙げているのは、攻撃側の AI 活用によって脆弱性の公開から悪用までの時間が圧縮されているという認識です。CISA は期限を毎年見直し、敵対的な AI 能力の進展に応じて短縮する可能性にも言及しています。現行の 3 日という期限は、今後さらに短くなり得る前提で読む必要があります。

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

BOD 26-04 では、脆弱性ごとに 4 つの問いへ「はい / いいえ」で答え、その組み合わせで対応期限が決まります。4 つはいずれも SSVC の決定点に基づくもので、CISA は実装ガイダンスの FAQ で各変数の判定基準を具体的に示しています。ここでは実務で自分の環境に当てはめられる粒度まで分解します。

外部公開（Publicly Exposed）

自組織が所有または管理する IT 資産が、公衆ネットワーク経由で未認証または信頼されていない主体からアクセス可能な状態にあるかどうかを問う変数です。CISA は、物理的・論理的な設置場所を問わずこの条件を満たせば外部公開とみなすと定義しています。データセンター内にあるか、クラウド上にあるかは判定に影響しません。

判定手段は 1 つに限定されず、CDM プログラムや Cyber Hygiene サービスなど複数の手段を重ねて用い、いずれか 1 つでも外部公開と判定した場合は「Yes」として扱う設計です。CISA 側の探索手段としては、Nmap による能動スキャン、Cyber Hygiene サービスの検出結果、パッシブなネットワーク探索、EDR、NAC、モバイル端末管理システム、クラウドプロバイダーのコントロールプレーン上のインベントリが挙げられています。

実務上、最も重要なのはデフォルトの扱いです。資産の公開状況に関する情報が得られない場合、CISA はその資産を外部公開として扱います。 保守的な側に倒す設計であり、これは「外部公開していない」と主張する側に立証責任があることを意味します。台帳に載っていない資産は、自動的に厳しい期限が適用される側へ回ることになります。

日本の民間組織に置き換えるなら、ASM（Attack Surface Management）や定期的な外部スキャンによって、公開資産の一覧を継続的に更新できているかどうかが、この変数を扱えるかどうかの分岐点になります。

KEV 掲載の有無

CISA の KEV カタログに掲載されているかどうかを問う変数です。掲載の条件は次の 4 点とされています。

• CVE ID が付与されていること
• 実環境での悪用について信頼できる証拠があること
• ベンダー提供の更新など、明確な修正または緩和策が存在すること
• 米国政府の情報システムに重大なリスクをもたらすこと

運用面では、CISA は対象を特定してから 24 時間以内の更新を目標としつつ、追加調査や証拠不足、緩和策の未提供などにより遅延し得るとしています。

ここで押さえておきたい点が 2 つあります。1 つは、PoC コードの公開は掲載の要件ではないことです。掲載済み脆弱性のうち PoC が公開されている割合は高いものの、掲載の前提とはされていません。もう 1 つは、古い CVE が追加されたからといって、現在悪用が続いているとは限らないことです。上記 4 条件を満たせば、年代を問わずいつでも掲載対象となります。

KEV は「現在攻撃を受けているリスト」ではなく「悪用が確認されたリスト」である、という理解が前提になります。

悪用の自動化可能性（Automatable）

攻撃者が偵察から実行までの全工程を自動化できるかどうかを問う変数です。CISA は CVSS v4.2 User Guide と SSVC のコミュニティ定義に整合させると説明しています。

判定のヒューリスティックとして示されているのは、リモートコード実行を達成し、脆弱なシステムに対して確実に動作する PoC コードが公開されていれば、Automatable は「Yes」という基準です。この判定結果は Vulnrichment プログラムを通じて公開されます。

この変数が実務に与える影響は明確です。脆弱性の公開時点では Automatable が「No」だったものが、後日 PoC が公開されたことで「Yes」に変わり、対応期限が短縮される可能性があります。期限は静的な値ではなく、外部状況の変化に応じて再計算される前提で運用する必要があります。

技術的影響（Total control / Partial control）

攻撃者が脆弱なシステムに対してどの程度の制御を得るかを問う変数で、Total control（完全な制御）と Partial control（部分的な制御）の二値で判定します。CISA は、次の問いのいずれかが「はい」であれば Total control とする判定基準を示しています。

• 攻撃者が任意のソフトウェアをインストールして実行できるか
• 脆弱なコンポーネントが実行できるすべての動作を、攻撃者が引き起こせるか
• 脆弱なコンポーネントに対する完全な権限を持つアカウント（管理者や root など）を攻撃者が取得できるか
• CVSS の機密性への影響と完全性への影響が、いずれも High か

いずれにも該当しなければ Partial control となります。サービスクラッシュを引き起こすようなサービス拒否は Partial control 側に分類されます。情報漏えいについては、ログイン認証情報のように資産の完全な制御につながるセキュリティ上重要な情報が露出する場合に限り Total control として扱われます。

なお、ブルートフォース型のサービス拒否や資源枯渇攻撃は、そもそも本指令の対象外とされています。根拠として参照されているのは CVE 採番機関（CNA）のルールです。

参考: CVE Numbering Authority Rules 4.1.6
“Brute-force denial-of-service and brute-force resource exhaustion attacks … should not be determined as vulnerabilities.”
（ブルートフォース型のサービス拒否および資源枯渇攻撃は、脆弱性として判定すべきではない）
https://www.cve.org/ResourcesSupport/AllResources/CNARules

4 つ目の判定基準に注目すると、興味深い構造が見えます。CISA は CVSS を優先順位付けの主軸から外した一方で、技術的影響の判定においては CVSS の機密性・完全性メトリクスを判断材料の 1 つとして残しています。 CVSS を捨てたのではなく、スコアという集約された 1 つの数値ではなく、個別のメトリクスを構成要素として使う形に置き換えたと理解するのが正確です。

組み合わせで決まる対応期限の階層

4 つの変数はいずれも二値のため、組み合わせは 16 通りになります。CISA はこれを Table 1: Remediation Timelines として一覧化し、各組み合わせに対応期限を割り当てています。

出典: CISA BOD 26-04 Table 1: Remediation Timelines
https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk

この表を眺めるだけでは規則性が見えにくいため、階層ごとに条件を整理します。

3 日＋フォレンジック調査の条件

最も厳しい階層は、次の条件をすべて満たす場合です。

• KEV に掲載されている
• 技術的影響が Total control
• 外部公開されている、または悪用が自動化可能である

該当するのは No.1、No.3、No.9 です。ここで注目すべきは No.9 で、外部公開されていない資産であっても、KEV 掲載・自動化可能・Total control が揃えば最も厳しい階層に入ります。 内部資産だから猶予があるという前提は成立しません。

一方、No.11（外部公開なし・KEV 掲載・自動化不可・Total control）は 14 日にとどまります。KEV に載っていて完全な制御を奪われる脆弱性であっても、外部から到達できず自動化もできなければ、緊急度は一段下がるという判定です。

フォレンジック調査を伴わない 3 日の階層は No.2 と No.5 です。特に No.5 は KEV に掲載されていない点が重要で、外部公開・自動化可能・Total control が揃えば、悪用の確認を待たずに 3 日が適用されます。KEV 掲載は最短期限の前提条件ではありません。

フォレンジック調査は、期限内の修正とは別に求められる要件です。実装ガイダンスでは、KEV 追加から 2 時間以内のスコープ特定に始まり、48〜72 時間以内に調査報告書を作成して報告要否を判断するまでの 6 段階が推奨手順として示されています。揮発性データの取得を優先し、パッチ適用前に証拠を保全すること、封じ込めを攻撃者に気づかれない形で実施することなどが明記されています。これは実質的に、修正作業と並行して侵害調査を走らせる体制が求められることを意味します。侵害の兆候を確認する手段については、関連記事『NDR 製品の選定ポイント』も参考になります。

14 日・60 日・次回アップグレード時の区分

残りの階層を整理すると、次の傾向が読み取れます。

KEV 掲載が「Yes」であれば、最も緩い階層でも 14 日です。 No.4、No.10、No.11、No.12 がこれに該当し、60 日や次回アップグレード時の階層に入る組み合わせは存在しません。悪用が確認された時点で、対応期限は最長 2 週間に固定されます。

外部公開が「Yes」であれば、最も緩い階層でも 60 日です。 No.8 が該当し、次回アップグレード時まで先送りできる組み合わせには入りません。

次回アップグレード時まで先送りできるのは No.15 と No.16 のみで、外部公開なし・KEV 未掲載・自動化不可の 3 条件が揃った場合に限られます。ここで注目したいのは No.15 です。技術的影響が Total control であっても、この 3 条件が揃えば先送りが認められます。CVSS で 9.8 が付くような脆弱性が、閉じた環境にあり PoC も存在しなければ、対応を後回しにしてよいという判断です。

これは従来の運用感覚と最も大きく異なる部分です。実装ガイダンスでは、この階層について優先順位付けの対象外としてよいと明言されています。CISA が参照している CVSS 側の見解も、この方向性と整合しています。

参考: CVSS v4.0 User Guide（FIRST）
“should not be used alone to assess risk”
（リスクの評価にスコア単体を用いるべきではない）
https://www.first.org/cvss/v4-0/user-guide

なお、これらの期限は上限として定義されており、より短い期限を自組織で設定することは妨げられていません。リスク許容度が低い組織が独自に厳しい期限を設けることは想定内の運用です。

4 変数の値を取得する方法

4 つの変数のうち 3 つは、CISA が公開データとして供給します。残る 1 つは各組織が自力で判定します。この非対称性が、BOD 26-04 を運用に乗せるうえでの実質的な難所になります。

Vulnrichment が提供する 3 変数

Vulnrichment は、CVE データに SSVC の決定点、CWE ID、CVSS 情報を付与する CISA のプログラムです。付与されたデータは CVE レコードの ADP（Authorized Data Publisher）コンテナに格納され、既存の CVE フィードに自動的に含まれます。取得経路は CVE の API、または GitHub の CVEProject/cvelistV5リポジトリです。

実際のデータを確認します。以下は、2026 年 8 月 4 日に KEV へ追加された Apache Tomcat の CVE-2026-34486 のレコードから、CISA-ADP コンテナ部分を抜き出したものです。

{
  "type": "ssvc",
  "content": {
    "id": "CVE-2026-34486",
    "role": "CISA Coordinator",
    "options": [
      { "Exploitation": "active" },
      { "Automatable": "yes" },
      { "Technical Impact": "partial" }
    ],
    "version": "2.0.3",
    "timestamp": "2026-08-04T17:42:15Z"
  }
}

同じコンテナには、KEV 追加日を示すブロックも並んで格納されています。

{
  "type": "kev",
  "content": {
    "dateAdded": "2026-08-04",
    "reference": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-34486"
  }
}

このレコードから読み取れる 3 変数は、KEV 掲載が「Yes」、自動化可能が「Yes」、技術的影響が「Partial control」です。Table 1 に当てはめると、外部公開されていれば No.2 で 3 日、外部公開されていなければ No.10 で 14 日となります。

ここで 1 つ、実務上の示唆があります。この脆弱性は公開直後から RCE に至る PoC が報告されていましたが、CISA の判定は Total control ではなく Partial control です。 攻撃成立にクラスタリングの有効化やガジェットチェーンの存在といった前提条件が必要であることが反映されたものと考えられます。外部の解説記事が付与するラベルと、Table 1 の判定に用いる値は一致しないことがあります。 期限を計算する際は、必ず ADP コンテナの値を参照する必要があります。

データが揃わない場合の扱いも定められています。CVE の情報項目が得られず、かつ KEV にも掲載されていない場合、メタデータが提供されるまで 60 日として扱われます。KEV に掲載された CVE については、CISA が必ず Vulnrichment データを提供します。 脆弱性情報の収集と対応判断の流れ全般については、関連記事『Oracle 製品の脆弱性対応の考え方』も参考になります。

自組織でしか判断できない「外部公開」の扱い

4 つ目の変数だけは、外部から供給されません。資産が公衆ネットワークから未認証で到達可能かどうかは、自組織の資産管理能力に依存します。

CISA が挙げている判定手段は次のとおりです。

• 脆弱性スキャナーなどの資産管理機能によるタグ付け
• Nmap による能動スキャン
• パッシブなネットワーク探索
• EDR、NAC、モバイル端末管理システムの情報
• クラウドプロバイダーのコントロールプレーン上のインベントリ

タグ付けの項目としては、組織、下位組織、環境、公開状況、資産種別が挙げられています。プライベートアドレス空間の資産も対象に含める点が明示されており、外部公開されていないことを積極的に記録しておくことが求められます。

判定できない場合のデフォルトは「外部公開」です。 情報が得られない資産は、保守的に厳しい側の期限が適用されます。これは、資産台帳の精度がそのまま対応工数に跳ね返る構造を意味します。台帳に載っていない資産、公開状況が未記入の資産が多いほど、3 日や 14 日の階層に振り分けられる脆弱性が増えていきます。

BOD 26-04 はパッチ適用の指令として読まれがちですが、期限を決める 4 変数のうち唯一自組織が握っているのが資産の公開状況である以上、実質的には資産管理の精度を問う指令として設計されています。日本の民間組織がこの考え方を取り入れる場合も、最初の着手点は期限の設定ではなく、外部公開資産の棚卸しになります。

自社の脆弱性管理に取り込む手順

BOD 26-04 は日本の組織に義務を課すものではありませんが、判断ロジックそのものは自組織の運用へ移植できます。ここでは、移植にあたって最初に着手すべき点と、期限を成立させるための設計上の考え方を整理します。

資産の外部公開状況の棚卸し

前章で述べたとおり、4 変数のうち自組織が判定するのは資産の外部公開状況だけです。したがって、着手点は期限の設定ではなく資産の棚卸しになります。

日本では、この領域に対応するガイダンスとして経済産業省の「ASM 導入ガイダンス」が公開されています。同ガイダンスは ASM を次のように定義しています。

参考: ASM（Attack Surface Management）導入ガイダンス（経済産業省）
「組織の外部（インターネット）からアクセス可能な IT 資産を発見し、それらに存在する脆弱性などのリスクを継続的に検出・評価する一連のプロセス」
https://www.meti.go.jp/policy/netsecurity/wg1/ASMguidance.pdf

BOD 26-04 が求める外部公開の判定は、この ASM のプロセスとほぼ重なります。両者を接続して考えると、実務での作業手順は次のようになります。

• 資産に対して、組織・環境・公開状況・資産種別のタグを付与する
• プライベートアドレス空間の資産も対象に含め、外部公開していないことを積極的に記録する
• 能動スキャン、パッシブ探索、EDR、NAC、クラウドのコントロールプレーン上のインベントリなど、複数の手段で公開状況を突き合わせる
• 突き合わせの結果、いずれか 1 つでも外部公開と判定されれば、外部公開として扱う

判定できない資産を「非公開」とみなさないことが要点です。 BOD 26-04 では、情報が得られない資産は外部公開として扱われます。台帳の空欄は安全側ではなく、厳しい側に倒れる設計になっています。

ASM ツールを新規導入しなくても、既存の脆弱性スキャナーやクラウドのタグ機能で公開状況の項目を追加するところから着手できます。まず「自組織の公開資産の一覧を、いつ時点の情報として提示できるか」を確認するのが現実的な第一歩です。

3 日という期限を設計で成立させる

3 日という期限は、既存の運用体制の努力によって達成するものではありません。特に顧客へ納入したシステムでは、提案から実装までの調整を経て 3 日以内に適用することは、多くの場合現実的ではないと考えられます。システムによっては停止がそのまま事業の停止につながるためです。

CISA 自身もこの点を認識しており、実装ガイダンスの FAQ で、認可担当者が変更管理プロセスと業務継続計画を整備し、期限を成立させる前提を作るべきだとしています。あわせて、ミッションクリティカルなシステムには要員を割り当てて手動でテストと適用を行い、重要度の低いシステムは自動化された仕組みで適用するという役割分担の例も示されています。期限は運用でひねり出すものではなく、あらかじめ整えた仕組みで受け止めるもの、という位置づけです。

インフラ設計の観点から言い換えると、3 日で適用できるかどうかは、設計段階でどこまで冗長性を確保したかで決まります。 単一構成のシステムでは、パッチ適用がそのまま計画停止を意味し、調整に要する日数が期限を超えます。一方、冗長構成であれば次のような流れで、業務影響を抑えたまま適用を進められます。

• 待機系に先行して修正を適用する
• 待機系へ切り替え、一定期間の監視で問題がないことを確認する
• 現用系へ修正を適用する
• 必要に応じて元の構成へ戻す

この方式では、業務が影響を受けるのは切り替えの瞬間だけになります。したがって、設計時に詰めるべきはフェイルオーバーに要する時間そのものです。 ヘルスチェックの間隔と判定回数、セッション情報の引き継ぎ可否、切り戻し手順を事前に検証してあるかどうかが、そのまま適用可能な期限の下限を決めます。切り替えに数十秒しかかからない構成であれば緊急適用の選択肢に入りますが、数時間の停止を伴う構成であれば、どれだけ運用側が努力しても 3 日での適用は成立しません。冗長構成での適用順序については、関連記事『FortiGate のアップグレードパスの確認手順』でも具体的な進め方を扱っています。

もう 1 点、設計と同時に決めておきたいのが変更管理の事前合意です。「KEV に掲載され、かつ完全な制御を奪われる脆弱性については、緊急変更として事前承認済みとして扱う」といった取り決めを、システムの導入時点で顧客と合意しておく方法があります。判定基準が 4 変数として明文化されていることは、この種の合意を客観的な根拠に基づいて結ぶうえで有利に働きます。脆弱性が公表されてから承認の可否を協議する体制では、3 日という期限に間に合いません。

それでも間に合わない場合の緩和策

設計上の手当てをしてもなお期限内に対応できない場合について、CISA は明確な立場を示しています。KEV カタログ掲載の脆弱性に対する既知の技術的緩和は、カタログに記載された required action を適用するか、資産をネットワークから切り離すかの 2 択とされています。期限内に実施できない場合は、資産をネットワークから除去することが求められます。

隔離の具体的な手法としては、次が挙げられています。

• 資産そのものの廃止
• 脆弱性を含むソフトウェア製品の削除
• ネットワークセグメンテーション
• 資産の隔離
• ソフトウェア定義境界の適用
• プロキシの経由

免除措置は用意されていません。CISA は指令で求められる対応についてウェイバーや例外を発行しないとしており、実装が困難な場合は個別に相談する運用になっています。

ここで注意したいのは、WAF や IPS による仮想パッチが、CISA の示す緩和策には含まれていない点です。日本の民間組織においては、恒久対処までの時間を稼ぐ手段として仮想パッチが現実的な選択肢になる場面がありますが、BOD 26-04 の枠組みでは根本対処の代替とは位置づけられていません。適用する場合も、期限を延長する根拠にはならないという前提で扱うのが適切です。仮想パッチの適用範囲と限界については、関連記事『FortiGate の仮想パッチ機能の使いどころ』を参照してください。

なお、Table 1 の期限は上限値として定義されています。より短い期限を自組織で設定することは想定内の運用であり、リスク許容度に応じて厳しい基準を採用する余地があります。

まとめ

BOD 26-04 は、CVSS スコアによる一律の優先順位付けを廃し、外部公開・KEV 掲載・自動化可否・技術的影響の 4 つの二値判断で対応期限を決める指令です。4 変数のうち 3 つは CISA の Vulnrichment から機械的に取得でき、自組織が判定するのは資産の外部公開状況だけです。期限そのものよりも、その期限を受け止められる資産管理と冗長設計が整っているかが問われる内容になっています。

• 2026 年 6 月 10 日発出、BOD 19-02 と BOD 22-01 を統合して廃止
• 対応期限は 4 つの二値判断による 16 通りの組み合わせで決定
• KEV 掲載かつ完全な制御を奪われる場合は 3 日＋フォレンジック調査
• 外部公開なし・KEV 未掲載・自動化不可なら次回アップグレード時まで先送り可
• KEV 掲載・自動化可否・技術的影響は Vulnrichment の ADP コンテナから取得
• 公開状況が不明な資産は外部公開として扱われるため台帳の精度が期限に直結
• 3 日という期限は冗長構成と変更管理の事前合意によって設計段階で成立させる

以上、最後までお読みいただきありがとうございました。