--- title: "BOD 26-04とは？KEVの是正期限を4変数で決める仕組みと自社運用への移し方" url: "https://www.issoh.co.jp/tech/details/18233/" published: 2026-10-10 updated: 2026-10-10 categories: ["セキュリティ"] publisher: "株式会社一創" --- # BOD 26-04とは？KEVの是正期限を4変数で決める仕組みと自社運用への移し方 BOD 26-04は、米国のCISAが2026年6月10日に出した連邦文民機関向けの拘束的運用指令（Binding Operational Directive）です。KEVカタログに載った脆弱性を一律の期日で直させてきたBOD 22-01と、CVSSの深刻度で期限を決めていたBOD 19-02を廃止し、公開露出・KEV掲載・攻撃の自動化可能性・技術的影響という4つの変数で是正期限を3日から次回更新時まで振り分ける方式へ切り替えました。本記事では、16通りの全判定表、KEVカタログの期限日数が実際にどう変わったかの集計、CISAが公開するデータで自社資産の期限を自動判定するPythonコード、日本企業が社内の脆弱性対応ルールへ移すときの判断までを順に扱います。 ## まとめ｜BOD 26-04で変わった是正期限の決め方と日本企業が取り入れる範囲 期限を決める軸が「脆弱性の深刻度」から「その脆弱性がどの資産に、どんな条件で存在するか」へ移りました。同じCVEでも、インターネットから届く機器なら3日、社内に閉じた機器なら14日、悪用の記録がなく影響も限定的なら次回の定期更新時でよい。ここが一番大きな変化です。 KEVに載った脆弱性は、どの組み合わせでも最長14日です。2026年6月10日以降にKEVへ追加された122件では、99件が3日期限でした。BOD 22-01時代に多かった21日期限は姿を消しています。 民間企業に法的な義務はありません。それでも、判定に使う4変数のうち3つはCISAがCVEごとに無償で公開しており、自社が用意するのは「その資産が公開されているか」の1項目だけです。資産台帳に公開・内部の区分を持てるなら、社内SLAの土台として取り入れる価値があります。区分を持てない段階なら、先に棚卸しから始めてください。 ## BOD 26-04の概要｜BOD 22-01とBOD 19-02に代わる2026年6月指令 正式名称は「Prioritizing Security Updates Based on Risk」。原文は[CISAのBOD 26-04本文](https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk)で読めます。 ### 発行日と対象範囲｜米連邦文民機関が対象で民間企業に法的拘束力はない 対象は連邦文民行政機関（FCEB）が使う連邦情報システムです。国家安全保障システムや国防・情報機関の一部システムは対象から外れています。オンプレミスに加え、FedRAMP認定クラウドを含む第三者ホスティングの環境にも及びます。 請負業者は、調達契約で指示されない限り直接の対象ではありません。ただし機関側には契約内容の見直しが求められており、米政府と取引のある事業者には契約経由で要件が降りてくる可能性があります。日本企業が直接縛られることはありません。 ### BOD 22-01からの変更点｜一律の期日からリスク4変数による期限の算出へ 2021年11月3日に出た[BOD 22-01](https://www.cisa.gov/news-events/directives/bod-22-01-reducing-significant-risk-known-exploited-vulnerabilities-revoked)は、KEVに載った脆弱性をCISAが示す期日までに直させる仕組みでした。期日は掲載ごとに決まり、資産がインターネットに面しているかどうかは問いません。旧URLは現在、末尾に「revoked」が付いた失効版のページへ転送されます。 BOD 19-02（2019年4月29日）はインターネットから到達できるシステムの是正期限をCVSSの深刻度で定めていました。これも廃止され、実装ガイダンスのFAQには、連邦文民機関は優先順位付けにCVSSを使うことをもはや求められない、と明記されています。CVSSの使用が禁じられたわけではありません。スコアの計算と読み方は[CVSSとは？深刻度スコアの見方・計算方法とv4.0の変更点](https://www.issoh.co.jp/tech/details/5096/)で整理しています。 ### 段階的な義務｜即時・60日・180日の3フェーズで求められる作業の中身 義務は発行時から順に3段階に分かれ、各段階の時期と作業内容を下表に示します。日付は2026年6月10日の発行日から数えたものです。 | フェーズ | 時期 | 主な作業 | | --------- | -------- | ------------------------- | | Phase I | 発行時から即時 | 脆弱性管理方針の見直し、KEV監視、CDM経由報告 | | Phase II | 発行から60日 | CVEとKEVのデータを判断の基礎にする手順へ更新 | | Phase III | 発行から180日 | 表1の期限内是正、外部到達資産の継続特定・タグ付け | Phase IIIは2026年12月上旬に当たり、新しい期限表の全面適用はここからです。資産のタグには組織、環境（本番・開発）、露出（公開・内部）、資産種別を含めるよう求められています。CISAは免除や例外を出さないと明言しており、期限内に直せない資産はネットワークから外すか分離する選択肢しか残りません。 ## 是正期限を決める4変数と16通りの判定表を読み解く｜3日から次回更新まで 期限表は、脆弱性の優先度付け手法SSVC（Stakeholder-Specific Vulnerability Categorization）を下敷きにしています。CISAの実装ガイダンスは、判定の決定木を[CERT/CCのSSVCリポジトリ](https://github.com/CERTCC/SSVC)にある機械可読のJSONとして参照しています。 ### 4つの変数の定義｜公開露出・KEV掲載・自動化可能性・技術的影響の基準 - 公開露出（Publicly Exposed）：物理的・論理的な置き場所に関係なく、認証されていない、または信頼されていない相手が公衆網から到達できるか。判定するのは機関自身 - KEV掲載（In KEV）：CVEが[KEVカタログ](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)に載っているか - 自動化可能性（Automatable）：偵察・武器化・配送・悪用の4段階を攻撃者が確実に自動化できるか - 技術的影響（Technical Impact）：ソフトウェアの挙動を完全に握られるか（Total）、限定的な制御や情報露出にとどまるか（Partial） 技術的影響がTotalになる目安として、実装ガイダンスは任意のソフトウェアを実行できる、管理者やrootの権限を得られる、CVSSの機密性と完全性の影響がともにHighである、などを挙げています。認証情報を確実に漏らす脆弱性もTotal扱いで、DoSは原則Partialです。 ### 16通りの全組み合わせ｜SSVCの判定表JSONから書き起こした是正期限 SSVCリポジトリの[BOD 26-04の判定表JSON](https://github.com/CERTCC/SSVC/blob/675fda1e1c7c7d97763ff57ce549183da61f2fba/data/json/decision%5Ftables/cisa/cisa%5Fbod%5F26%5F04%5F1%5F0%5F0.json)にある16行を、期限の短い順に並べ替えました。 | KEV掲載 | 公開露出 | 自動化 | 技術的影響 | 是正期限 | | ----- | ---- | --- | ------- | -------- | | あり | あり | 可 | Total | 3日＋トリアージ | | あり | あり | 不可 | Total | 3日＋トリアージ | | あり | なし | 可 | Total | 3日＋トリアージ | | あり | あり | 可 | Partial | 3日 | | なし | あり | 可 | Total | 3日 | | あり | なし | 不可 | Total | 14日 | | あり | あり | 不可 | Partial | 14日 | | あり | なし | 可 | Partial | 14日 | | あり | なし | 不可 | Partial | 14日 | | なし | あり | 不可 | Total | 14日 | | なし | あり | 可 | Partial | 14日 | | なし | なし | 可 | Total | 60日 | | なし | あり | 不可 | Partial | 60日 | | なし | なし | 可 | Partial | 60日 | | なし | なし | 不可 | Total | 次回更新時 | | なし | なし | 不可 | Partial | 次回更新時 | 表から読み取れる規則は二つです。KEVに載った時点で期限は14日以内に収まり、60日や次回更新時にはなりません。逆に、KEVに載っていなくても公開資産で自動化可能かつTotalなら3日になる。悪用の記録がまだ無い脆弱性でも、条件次第で最短の区分に入ります。 ### 3日＋フォレンジックトリアージ｜侵害の有無まで確かめる最も厳しい区分 最上位の区分は、3日以内の是正に加えて、資産がすでに侵害されていないかを調べるフォレンジックトリアージを求めます。実装ガイダンスは手順を6段階で示し、対象範囲の特定（2時間以内）、揮発性データを優先した証拠保全、重要パッチの適用、隔離、侵害・横展開・永続化・持ち出しの分析、報告書とエスカレーション判断（48〜72時間）という目安を置いています。時間の目安は推奨で、必須なのは適切なトリアージを実施することです。 KEVフィードにはこの区分を示す `forensicTriage` の項目が加わりました。CVE-2025-62593（Ray）はこの区分の実例で、KEV追加が2026年8月17日、期日が8月20日です。攻撃の中身は[ShadowRay 2.0とは？Rayクラスタを狙う自己増殖ボットネット](https://www.issoh.co.jp/tech/details/16905/)で解説しています。 ### 期限が動く仕組み｜インターネットから外すと緩みKEV追加で縮む流れ 期限の起点は、CISAがKEVへ追加した時点と、機関がCDMダッシュボードに脆弱性を記録した時点のうち早いほうです。そして期限は資産の状態に追従します。 公開されていた資産をインターネットから外せば公開露出が「なし」になり、期限は緩む側へ動く。反対に、内部資産の脆弱性が後からKEVへ載れば、その時点で期限は縮みます。パッチをすぐ当てられない機器について、先に公開経路を閉じる判断が期限上も意味を持つ仕組みです。 ## KEVカタログの期限はどう変わったか｜2026年6月以降の追加122件の集計 [KEVカタログのJSONフィード](https://www.cisa.gov/sites/default/files/feeds/known%5Fexploited%5Fvulnerabilities.json)を2026年10月10日に取得し、追加日と期日の差を数えました。カタログの版は2026.10.08、収録は1,739件です。 ### 期限日数の分布｜21日中心から3日中心へ移ったKEVフィードの実測値 | 追加時期 | 3日 | 7日 | 14日 | 21日 | その他 | | ------------------- | --- | -- | --- | ---- | --- | | 2025年6月1日〜2026年6月9日 | 31件 | 9件 | 55件 | 161件 | 10件 | | 2026年6月10日以降 | 99件 | 0件 | 23件 | 0件 | 0件 | BOD 22-01の時代は21日が標準でした。BOD 26-04以降は3日と14日の2種類だけになり、8割が3日です。3日のうち78件にはフォレンジックトリアージの指定が付いています。 2026年10月8日には、2015年のISC BINDや2016年のApache Strutsといった古いCVEが3日期限で追加されました。実装ガイダンスは、稼働中のレガシー製品がすべてパッチ済みだとは仮定しない、と説明しています。古い番号だから対応済みのはず、という思い込みは通用しません。 ### KEVのdueDateと自社の期限は一致しない｜Starletteの例で見る判定の差 KEVに表示される期日は、CISAが手元のデータで「公開資産に存在する証拠があるか」を推定して計算したものです。資産ごとの最終判断は機関が行うと実装ガイダンスは書いています。 CVE-2026-48710（FastAPIの土台であるStarlette）は2026年9月2日に追加され、期日は9月16日の14日でした。ところが、インターネットに公開したAPIサーバでこのCVEを抱えている場合、判定表に当てはめると3日になります。KEVの期日を見て「2週間ある」と読むと、公開系では11日遅れる計算です。このCVEの仕組みと該当判定、FastAPIの依存制約を踏まえた修正手順は[Starletteの脆弱性CVE-2026-48710の影響条件と修正手順](https://www.issoh.co.jp/tech/details/18235/)で解説しています。 ## Vulnrichmentのデータで自社資産の是正期限を自動判定する手順 4変数のうち3つは機械的に取れます。自社で用意するのは公開露出の区分だけです。 ### データの取得元｜CVEレコードのADPコンテナに入るSSVCの3項目を読む CISAは[Vulnrichment](https://github.com/cisagov/vulnrichment)というプログラムで、CVEレコードにSSVCの判定値やCWE、CVSSを補います。値はCVEレコードのADP（Authorized Data Publisher）コンテナに入り、GitHubのリポジトリやCVEのAPIから取得できます。 SSVCの部分は `containers.adp[].metrics[].other` のうち `type` が `ssvc` の要素で、`Exploitation`・`Automatable`・`Technical Impact` の3項目が並びます。CVE-2025-62593ではそれぞれ active・yes・total でした。KEVに載ったCVEにはVulnrichmentのデータが必ず付くとされています。SSVCの判定を製品の中で自動化したSaaSとしては、[FutureVulsのSSVC優先度判定とAPI連携の手順](https://www.issoh.co.jp/tech/details/18130/)も参考になります。 ### Pythonで判定する｜KEVフィードとVulnrichmentと判定表を突き合わせる 標準ライブラリだけで動くコードです。CVE番号と公開区分（public か internal）を渡すと、期限区分とKEVの期日を表示します。 ``` import json, sys, urllib.request TABLE = "https://raw.githubusercontent.com/CERTCC/SSVC/675fda1e1c7c7d97763ff57ce549183da61f2fba/data/json/decision_tables/cisa/cisa_bod_26_04_1_0_0.json" KEV = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json" VR = "https://raw.githubusercontent.com/cisagov/vulnrichment/develop/{y}/{d}xxx/{cve}.json" def get(url): req = urllib.request.Request(url, headers={"User-Agent": "Mozilla/5.0"}) with urllib.request.urlopen(req, timeout=30) as r: return json.load(r) def ssvc(cve): _, y, n = cve.split("-") rec = get(VR.format(y=y, d=int(n) // 1000, cve=cve)) for adp in rec["containers"].get("adp", []): for m in adp.get("metrics", []): o = m.get("other", {}) if o.get("type") == "ssvc": return {k: v for opt in o["content"]["options"] for k, v in opt.items()} return {} cve, exposed = sys.argv[1], sys.argv[2] == "public" kev = {v["cveID"]: v for v in get(KEV)["vulnerabilities"]} s = ssvc(cve) key = { "cisa:KEV:1.0.0": "Y" if cve in kev else "N", "cisa:PE:1.0.0": "Y" if exposed else "N", # 未評価のときは実装ガイダンスの既定値（Automatable=no / Technical Impact=total） "ssvc:A:2.0.0": "Y" if s.get("Automatable", "no") == "yes" else "N", "ssvc:TI:1.0.0": "T" if s.get("Technical Impact", "total") == "total" else "P", } row = next(r for r in get(TABLE)["mapping"] if all(r[k] == v for k, v in key.items())) print(cve, "".join(key.values()), "期限区分:", row["cisa:BOD2604:1.0.0"], "KEVのdueDate:", kev.get(cve, {}).get("dueDate", "-")) ``` 2026年10月10日にStarletteのCVEで実行した結果です。4文字はKEV・公開露出・自動化・影響の順を表します。 ``` $ python bod2604.py CVE-2026-48710 public CVE-2026-48710 YYYP 期限区分: 3D KEVのdueDate: 2026-09-16 $ python bod2604.py CVE-2026-48710 internal CVE-2026-48710 YNYP 期限区分: 14D KEVのdueDate: 2026-09-16 ``` 判定表のURLはコミットを固定しています。SSVC側で表の版が上がったときに結果が黙って変わらないようにするためで、更新は差分を確認してから取り込んでください。脆弱性スキャナの出力と資産台帳の公開区分をCVE番号で結合すれば、この関数を資産ごとに回せます。 ### 未評価のCVEの扱い｜既定値は自動化不可・影響は完全制御として計算する 公開されたばかりのCVEは、Vulnrichmentの評価が付く前に手元へ届くことがあります。実装ガイダンスは、KEVに無く判定値も無いCVEを、第三者が情報を出すまで自動化「不可」・影響「Total」として扱うと定めています。上のコードの既定値はこれに合わせました。 公開露出の情報が無い資産は「内部」として扱う、という規定もあります。ただし社内運用へ移すなら、ここは逆にすべきです。区分が分からない資産を内部扱いにすると、棚卸し漏れの資産ほど期限が緩くなります。区分不明は公開扱い、と決めておくほうが事故が起きにくい。 ## 日本企業の脆弱性対応へ移す｜CVSS基準の社内SLAを組み替える判断 民間に義務が無い以上、取り入れるかどうかは自社の体制で決めます。判断の材料を三つに分けて示します。 ### 公開露出の棚卸しが先｜資産台帳に露出区分のタグが無い組織は始めない 4変数のうち、自社にしか判定できないのが公開露出です。CISA自身も、機関がこの区分を出していない資産はグローバルIPで通信しているか、ネットワーク機器かといった手がかりで推定するしかない、と書いています。 資産台帳に「公開・内部」の列が無い組織がBOD 26-04型の期限表だけ導入すると、全資産が内部扱いになって期限が一律に緩むか、全資産が公開扱いになって3日期限が溢れるかのどちらかです。外部から見える資産を継続的に洗い出す手段は[脆弱性対応の自動化｜ASM・BAS・ASVの使い分けと限界](https://www.issoh.co.jp/column/details/2372/)で比較しています。 ### 取り入れてよい条件と見送る場面｜KEVの運用が回っていない段階は過剰 取り入れてよいのは、次の二つがそろう組織です。資産台帳に公開区分があり、脆弱性スキャナの結果をCVE番号で台帳と結合できること。そして、3日以内に本番機器へパッチを当てる変更手順が実際に通ることです。 見送るべきなのは、KEVに載った脆弱性すら追えていない段階です。この場合はBOD 26-04の16通りを持ち込むより、KEV掲載分を14日以内に直すという一本のルールから始めるほうが回ります。判定表は「KEVなら最長14日」という性質を持つので、この簡略ルールは表と矛盾しません。脆弱性管理を一度きりで終わらせず継続的な露出面管理へ広げるなら、[CTEMとは？脆弱性管理との違い・5つの段階と導入判断](https://www.issoh.co.jp/tech/details/13277/)の枠組みが次の段階になります。 ### 外部へ任せる範囲｜露出面の確認と侵害調査を切り出すときの線引き 判定コードの運用、KEVの監視、パッチの適用までは手順が明確なので、内製で十分に回ります。経験の差が出るのは、どの資産が本当に外から届くのかを外側から確かめる作業と、3日＋トリアージ区分に当たったときに侵害が無いと言い切れるかの判断です。 この二つを外部へ出すなら、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)のように対象範囲と報告の粒度を先に決めて依頼すると早い。台帳の公開区分を自社で一度作ってから渡すと、診断は「台帳に無い公開資産を見つける」作業に集中でき、費用も抑えられます。 ## よくある質問 BOD 26-04について、検索で多く見かける疑問に答えます。 ### BOD 26-04は日本企業にも適用されますか？ 適用されません。対象は米国の連邦文民行政機関が使う連邦情報システムで、請負業者も調達契約で指示されない限り直接の対象外です。ただし米政府機関と取引がある場合、契約の見直しを通じて同等の要件が求められる可能性があります。義務とは別に、KEVのフィードやVulnrichmentのデータは誰でも無償で取得できるため、社内の優先順位付けにそのまま組み込めます。 ### BOD 22-01の期日でKEVを管理していた運用はどう変えるべきですか？ KEVフィードの期日をそのまま自社の期限にしている場合、公開資産では遅れる可能性があります。KEVの期日はCISAが公開資産に存在する証拠を推定して計算したもので、Starletteの例では期日が14日でも、公開APIサーバで判定すると3日です。最低限、公開資産のKEV掲載分は3日を目標に置き直してください。2026年6月10日以降、KEVの期日は3日と14日の2種類だけになっています。 ### CVSSはもう使わなくてよいのですか？ BOD 19-02の廃止で、連邦文民機関はCVSSによる優先順位付けを求められなくなりました。使用を禁じたわけではありません。CVSSの機密性と完全性の影響がともにHighであることは、技術的影響をTotalと判定する目安の一つとして実装ガイダンスに残っています。社内ではCVSSを影響度の参考値として残し、期限は露出とKEVで決める併用が現実的です。 ### フォレンジックトリアージは具体的に何をすればよいですか？ 実装ガイダンスは6段階を示しています。対象範囲の特定と帯域外の連絡経路の確保、揮発性データを優先した証拠保全、証拠を取ってからのパッチ適用、攻撃者に気づかれない形での隔離、侵害・横展開・永続化・持ち出しの分析、報告書とエスカレーション判断です。所要時間の目安は最大72時間ですが、時間は推奨で、要件は適切な分析を行うことにあります。KEVに個別の手順が付いた場合はそれに従います。 ### Vulnrichmentに評価が無いCVEはどう判定すればよいですか？ 実装ガイダンスの既定値では、KEVに無く評価も無いCVEを自動化「不可」・技術的影響「Total」として扱います。この組み合わせなら、公開資産で14日、内部資産で次回の定期更新時です。評価は後から付くことがあるため、判定は一度きりにせず、スキャンのたびに取り直す作りにしてください。KEVに載ったCVEにはVulnrichmentのデータが必ず付くとされています。 ## 関連記事 - [CVSSとは？脆弱性の深刻度スコアの見方・計算方法とv4.0の変更点を解説](https://www.issoh.co.jp/tech/details/5096/)：BOD 19-02が基準にしていたスコアの読み方です。 - [FutureVulsとは？SSVCの優先度判定と料金・スキャナ導入とAPI連携の手順](https://www.issoh.co.jp/tech/details/18130/)：SSVCを製品で回す場合の手順を扱っています。 - [CTEMとは？脆弱性管理との違い・5つの段階と企業の導入判断を解説](https://www.issoh.co.jp/tech/details/13277/)：露出面を継続して管理する枠組みです。 - [デジタル庁GSSの不正アクセスと約24.6万件｜CVSS中のVPN脆弱性を何で優先するか](https://www.issoh.co.jp/tech/details/18091/)：公開機器の脆弱性が侵入口になった実例です。 - [ShadowRay 2.0とは？Rayクラスタを狙う自己増殖ボットネットと露出面の閉じ方](https://www.issoh.co.jp/tech/details/16905/)：3日＋トリアージ区分に当たったCVEの事例です。 --- 出典: [BOD 26-04とは？KEVの是正期限を4変数で決める仕組みと自社運用への移し方]()（株式会社一創）