はじめに：「CVSS 7.0以上は30日以内」― その運用、まだ続けていますか？

多くの企業の脆弱性管理規程には、こうした期限が定められています。

• Critical（CVSS 9.0以上）：15日以内
• High（CVSS 7.0以上）：30日以内

日本企業で最もよく見かける運用のひとつです。監査でも説明しやすく、社内規程にも書きやすい。

では、 この運用は現在の脅威環境において、まだ適切でしょうか。

この数字はどこから来たのか

「Critical 15日／High 30日」という組み合わせの直接の出自は、米国CISAが 2019年4月 に発出した拘束的運用指令 BOD 19-02「Vulnerability Remediation Requirements for Internet-Accessible Systems」 です。インターネット公開システム上のCritical脆弱性は初回検知から15暦日以内、Highは30暦日以内に修復せよ、という要件でした。さらに遡ると、2015年のBOD 15-01が「Criticalを30日以内」と定めています。PCI DSSの要件6.3.3も、深刻度の高いパッチを1か月以内に適用することを求めています（対象範囲はバージョンにより異なります※1）。

日本の多くの規程が参照している数字は、この系譜の上にあります。つまり、 2019年時点の脅威環境を前提に設計された期限 です。

図1：「30日ルール」の系譜と、BOD 26-04による転換

2019年と現在で、何が変わったか

7年前の前提が、いま成り立っているかを確認します。

攻撃側の速度が上がりました。 2026年版のVerizon Data Breach Investigations Report（22,000件超の侵害を分析）では、脆弱性の悪用が初期侵入ベクターの第1位となり、31%を占めました。前年の20%から上昇し、同レポート19年の歴史で初めて認証情報の窃取が首位から陥落しています※2。

防御側の速度は下がりました。 同レポートによれば、CISA KEV（悪用が確認された脆弱性カタログ）に掲載された脆弱性が完全に修復された割合は26%で、前年の38%から低下。完全解決までの日数の中央値は32日から43日へと延びています。

つまり 「30日」という期限は、すでに中央値で守られていません。 規程に書かれている数字と、現場が実際に到達できる速度が乖離しています。

そして2026年、AIが変数として加わりました。 脆弱性の発見から悪用までの時間が、AIによってさらに圧縮されつつあります。日本でもこれは政策課題として扱われており、2026年5月18日に政府全体のパッケージ「Project YATA-Shield」が公表され、5月22日には金融庁と日本銀行が連名で金融機関等に対し「フロンティアAIによる脅威変化を踏まえた短期的な対応」を要請しています。後者では、CVSSスコアだけに依存しないリスクベースの優先順位付けが明示的に求められました（詳細は第3章）。

そして、30日ルールの源流は撤回されました

2026年6月10日、CISAはBOD 19-02を廃止しました。

後継として発出されたのが BOD 26-04「Prioritizing Security Updates Based on Risk」 です。BOD 19-02と、KEV対応を定めたBOD 22-01の両方を廃止・統合し、CVSSの深刻度に応じて一律の期限を割り当てるという、10年以上続いた考え方を明確に転換しました。

BOD 26-04は米国連邦民間行政機関（FCEB）向けの指令であり、日本企業に法的拘束力はありません。しかし、 自社の規程が参照している数字の源流が撤回されたのであれば、なぜ撤回されたのか、そして代わりに何が採用されたのかは知っておく価値があります。

本記事では、BOD 26-04が採用した優先順位付けの仕組みを整理したうえで、それをServiceNow Vulnerability Responseでどう実装するかを検討します。

目次

1. BOD 26-04の要点 ― 実装に必要な範囲だけ
2. ServiceNow VRでどう対応するか
3. 日本企業への示唆 ― 金融庁・日銀要請との対比

1. BOD 26-04の要点 ― 実装に必要な範囲だけ

BOD 26-04の全体解説は他に良い記事があるので、ここでは ServiceNowで実装する際に必要になる部分だけ を押さえます。

1-1. 4つの二値変数

BOD 26-04は、CERT/CCが策定した SSVC（Stakeholder-Specific Vulnerability Categorization）の決定木に基づき、以下4つの変数の組み合わせで是正期限を決定します。

変数	判定内容
Asset Exposure
（公開曝露）	当該資産がインターネット等から到達可能か
KEV Status	CISA Known Exploited Vulnerabilities カタログに掲載されているか
Automatable
（悪用の自動化可能性）	攻撃者がキルチェーンのステップ1〜4（偵察・武器化・配送・エクスプロイト）を信頼性高く自動化できるか
Technical Impact
（技術的影響）	Total（ソフトウェア挙動の完全な制御、または当該システム上の全情報の完全な開示）か、Partial（限定的な制御・情報露出）か

1-2. 是正期限の決定表（16通り・5階層）

4変数はいずれも二値なので、組み合わせは16通りです。実装ガイダンスの判定表（Appendix A / Table 1）は、この16通りを5つの是正期限に対応づけています。

是正期限	KEV	公開曝露	自動化	技術的影響
3日＋フォレンジック調査	yes	yes	yes	Total
yes	yes	no	Total
yes	no	yes	Total
3日	yes	yes	yes	Partial
no	yes	yes	Total
14日	yes	yes	no	Partial
yes	no	yes	Partial
yes	no	no	Partial
yes	no	no	Total
no	yes	yes	Partial
no	yes	no	Total
60日	no	yes	no	Partial
no	no	yes	Partial
no	no	yes	Total
次回システム更新時
（＝延期）	no	no	no	Total
no	no	no	Partial

条件式を誤りやすい箇所です。 「KEV収載かつ Technical Impact = Total なら3日＋フォレンジック」と要約したくなりますが、 KEV=yes・曝露=no・自動化=no・Total の組み合わせは14日 です。最上位階層に入るには、Total かつ KEV収載に加えて 公開曝露または自動化のいずれかが必要 です。ベンダー各社の解説でもこの点が省略されている例があるため、条件式は必ず判定表と照らして組んでください。

図2：4変数から是正期限が決まる構造

この数字がBOD 26-04の本質です。厳しくなったのではなく、 「本当に急ぐべき1%」を特定してリソースを集中させ、残りを正式に延期してよいと認める 仕組みです。全件を同じ期限で追いかけるのをやめる、という意思決定がここにあります※3。

1-3. 期限が「動く」という設計

もうひとつ実装上重要な特徴があります。 是正期限は静的ではありません。

• KEVに新規収載された → 期限が短縮される
• 当該システムをインターネットから切り離した → 「公開曝露」がNoになり、期限が緩和される

つまり緩和策（mitigation）が期限計算に反映されます。「すぐに直せないなら曝露を減らす」という現実的な選択肢が、制度に組み込まれています。最上位階層では、完全なパッチ適用だけでなく緩和アクションも期限充足として扱われるとされています。

また、期限のカウント起点は 「KEV収載時」または「当該資産上での検知時」のいずれか早い方 です。曝露状況が判定できない資産は「公開曝露あり」とみなされ、最短のクロックが適用されます。分からないものは危険側に倒す設計です。

この章のポイント： BOD 26-04は「4つの二値変数 → 16通り → 5階層の是正期限」という決定木であり、スコアリングモデルではありません。そして期限は状況変化に応じて動的に変わります。この2点が、次章の実装設計をそのまま決めます。

2. ServiceNow VRでどう対応するか

前提のお断り： 本セクションはServiceNow公式のコンプライアンスマッピングではありません。製品機能から実装方法を検討したものであり、BOD 26-04への準拠を保証するものではありません。実装は各組織の要件に基づいて設計・検証してください。

2-1. Risk Calculator は2層でできている

BOD 26-04をServiceNowで実装しようとすると、多くの方がまずRisk Calculatorの重み付けを調整しようとします。 その方向は行き止まりです。 ただし理由は「Risk Calculatorが使えないから」ではありません。Risk Calculatorは2つの層でできていて、 どちらの層を使うかで答えが正反対になります。

図3：Risk Calculator の2層構造 ― ルール層は決定リスト、値の層は加重加算

そもそも考え方が違う ― 加重加算は使いようがない

加重加算（Scoring Criteria）は、変数ごとに 固定の点数 を割り当てて合計するモデルです（Calculator._runRiskCalculation()）。「Total は25点」と決めたら、他に何が付いていようが常に25点を足します。

BOD 26-04はそういうモデルではありません。 同じ変数でも、他に何が揃っているかで効き方が変わります。 判定表から「Total を足す場合」と「曝露を足す場合」を、同じ土台の上で比べてみます。

土台	Total を足すと	曝露 を足すと
なし（KEV・曝露・自動化なし）	次回更新時（最下位）	60日（1つ上）
KEV ＋ 自動化	3日＋フォレンジック（最上位）	3日（1つ下）

同じ2変数の比較なのに、土台によって強弱が逆転しています。攻撃経路が何も無いときに効くのは「機会」（曝露）で、KEVと自動化がすでに揃っているときに効くのは「影響」（Total）だからです。 変数が互いに影響し合う ― SSVCが決定木を採用しているのは、この性質があるためです。

ルール層は「order 昇順・最初の一致で確定」する決定リスト

一方、ルール層の挙動は加重加算ではありません。Calculator._applyCalculators() は1つのCalculator group内で ルールを order 昇順に評価し、最初に条件が一致したルールを適用した時点で break します。 加算も上書きもしません。

Risk Calculator Rule は 順序付き決定リストです。 上から順に評価し、当たったところで止まる。これは決定木を平坦化したものと同じ構造であり、 BOD 26-04の判定表をそのまま書き下せます。

条件の指定方法も3通りあります。condition_type は Filter ／ Filter group ／ Script 。Script条件（advanced_condition）は GlideScopedEvaluator で評価され、current にFindingのGlideRecordが渡されます。

2-2. 設計方針 ― ServiceNow本来の流れに載せる

ServiceNowの思想は 「Risk Score を計算 → Severity（Risk Rating）を決定 → 修復ターゲットを決定」 です。そしてBOD 26-04の5階層は、Risk Ratingの5段階にちょうど対応します。

図4：4変数 → Risk Score → Risk Rating → 修復ターゲットの流れ

Risk Ratingの境界値は固定ではなく、テーブル sn_sec_calculator_risk_score_weight にFindingテーブルごとのレコードとして定義されています。CalculatorUtils.getRiskRatingFromRiskScore() が「risk_score以上の上限を持つ最初のRating」を返す仕組みです。

Risk Rating	risk_score 範囲（既定）	BOD 26-04 の是正期限
1 − Critical	90 – 100	3日 ＋ フォレンジック調査
2 − High	70 – 89	3日
3 − Medium	40 – 69	14日
4 − Low	1 – 39	60日
5 − None	0	次回システム更新時（ルールを当てない）

この設計を採るときのトレードオフ。 risk_score が「深刻度」ではなく「BOD Tier」を意味する値に変わります。①OOTBのRisk Calculatorルール（後述の「Technical Impact」、order 1000）には到達しなくなる ②risk_score が「深刻度」ではなくTierを表す値になる ③risk_rating を参照している既存のダッシュボード・SLA・アサインメントルールの棚卸しが要る ― の3点は事前に判断してください。②の副作用（Tier内の着手順にスコアを使えなくなる）への対処は 2-4 で扱います。

2-3. 4変数と標準項目の対応 ― 実機で確認した構成

4変数 × フィールド 確定表

先に結論を置きます。実装で参照するフィールドは以下の4つです。

#	BOD 26-04の変数	フィールド	テーブル	選択値
1	KEV Status	cisa_exists	sn_vul_entry	true / false
2	Automatable	automatable	sn_vul_entry	yes / no（小文字）
3	Technical Impact	technical_impact	sn_vul_entry	total / partial（小文字）
4	Asset Exposure	internet_facing	cmdb_ci_hardware	true / false

1〜3はVulnerability Entry側の値、4だけは資産側の値 です。この非対称性が実装設計を決めます。

実装前に確認すべき3点。

1. 列が存在しない環境がある。 これらの列を追加しているのはNVD連携アプリではなく Central Vulnerability Database（sn_sec_cvd） です。CVDはUSEM前提のアプリなので、USEMへ移行していない環境では列そのものが無い可能性があります
2. 紛らわしい同名フィールドがある。 CVSS v4のSupplemental Metricsが v4_ 接頭辞で6項目実装されています（v4_automatable ほか）。選択値も大文字の YES / NO / NOT_DEFINED で体系が違います。 接頭辞なしの automatable がSSVC判断点です
3. 連携を回すまで値は入らない。 Automatable と Technical Impact はCISAがVulnrichmentで付与し、NVD 2.0 API経由で取り込まれます。 アプリのバージョンを上げただけでは0件のまま で、NVD連携を有効化して同期を回して初めて値が入ります（実測では全CVEの約47%、KEV収載済みは100%）

Asset Exposure

4変数のうち、CISA側がデータを提供していないのはこれだけです。CMDB CI の internet_facing 属性が該当します。

internet_facing 属性は cmdb_ci_hardware 配下のクラスにしか定義されていません。cmdb_ci など、それ以外のクラスのCIでは internet_facing 自体が存在せず、値は常にNullになります。この場合はBOD 26-04の 「判定できない資産は公開曝露ありとみなす」 という原則に従い、 値が空のときも true として扱う処理を明示的に実装してください。 2-4のScriptではこの処理を行っています。

2-4. 実装 ― Risk Calculator 5本 ＋ Remediation Target Rule 4本

ここが実装の中核です。決定木はRisk Calculator側に置き、Remediation Target Ruleは Risk Ratingだけを見る4本に単純化します。

Risk Calculator ― 5本のルールで16通りを表現する

16通りの組み合わせを見て「ルールを16本作るのか」と考えてしまいますが、その必要はありません。 上から順に評価して最初に当たったところで止まる という性質のおかげで、上位ほど狭い条件を置くだけで済みます。

k = KEV収載 e = 公開曝露 a = Automatable t = Technical Impact が Total

order 100 k && t && (e || a) → risk_score 100 → Critical → 3日＋フォレンジック
order 200 (e && a) && (k || t) → risk_score 80 → High → 3日
order 300 k || (e && (a || t)) → risk_score 50 → Medium → 14日
order 400 e || a → risk_score 20 → Low → 60日
order 500 true → risk_score 0 → None → ルールを当てない

各ルールは Condition type = Script／Value type = Script で作ります。条件スクリプトの中身は4変数の読み取りだけです。

var v = current.vulnerability;
var k = (v.cisa_exists == true || v.cisa_exists == '1');
var a = (v.automatable + '' == 'yes');
var t = (v.technical_impact + '' == 'total');

var ci = current.cmdb_ci;
var iface = (ci && !ci.nil()) ? (ci.internet_facing + '') : '';
var e = !(iface == 'false' || iface == '0'); // 空も true ＝ BODのfail-safe

return k && t && (e || a); // ← ルールごとにここだけ差し替える

SSVCが空のときの扱いを、このスクリプトで明示的に決めてください。 上の書き方は automatable が空なら no、technical_impact が空なら partial として扱います。 黙って安全側でない方に倒れる ので、意図した挙動かを確認する必要があります。実機ではSSVCが入っているCVEは半数弱でした（ただしKEV収載済みは100%入っているため、最上位Tierの判定は穴に落ちません）。

値が空のときにCVSSから近似するなら、technical_impact は v3のCとIがともに HIGH なら total （ServiceNow標準のRisk Calculatorルールと同じ判定式）、automatable は AV:N + AC:L + PR:N + UI:N （＝ネットワーク到達可能なRCE）で導出できます。EPSSは連続値で二値化の閾値に根拠が置けないため、この用途には使いません。

推定値を使った場合は、その旨をVulnerable Item側に記録してください。 BOD 26-04が決定木を採用した理由は説明可能性です。監査で「なぜ14日なのか」と問われたときに「Technical Impactが推定値だから」と答えられなければ、決定木の利点が失われます。導出元を示すフィールドを1つ持つか、work notesに残す形で足ります。

自作ルールは order 1000 より前に置いてください。 OOTBの「Technical Impact」ルールが order 1000 にあり、条件が active=true なので必ず一致します。後ろに置くと自作ルールには到達しません。

逆に、上記の order 500（条件 true）を置いた時点で OOTBの「Technical Impact」ルールは二度と実行されません。 この環境の risk_score はBOD Tierを意味する値に変わります。意図した上書きであることを設計文書に明記してください。

Remediation Target Rule ― 4本。条件は Risk Rating だけ

ルール名	Target (days)	Condition	Target from
BOD 26-04 T1 Critical	3	risk_rating = 1	first_found
BOD 26-04 T2 High	3	risk_rating = 2	first_found
BOD 26-04 T3 Medium	14	risk_rating = 3	first_found
BOD 26-04 T4 Low	60	risk_rating = 4	first_found
Rating 5（None）にはルールを作らない ― ターゲット日なし＝「次回システム更新時」

4本の条件は互いに排他なので、複数一致は起きません。 Tierの判定ロジックはRisk Calculator側に集約され、こちらは対応表を書くだけになります。

同じ「3日」の中では Critical を先に着手する

T1（Critical）とT2（High）は、期限としてはどちらも3日です。しかし 同じ3日の中では Critical を先に処理します。 フォレンジック調査が必要な最上位階層だからです。

より細かい順序 ― 同じCriticalの中でどの案件から着手するかは、BOD 26-04が規定する領域ではありません。従来のCVSS順など、 各社の脆弱性対応準則に沿って判断してください。

「3日＋フォレンジック調査」をどう表現するか

T1とT2は期限が同じ3日なので、Remediation Target Rule上は同じ日数になります。 差分であるフォレンジック調査は、Risk Rating = Critical を条件にFlow側で表現します。

Flow Designer で Vulnerable Item の作成・更新をトリガーに risk_rating = 1 を評価し、一致したら ①フォレンジック・トリアージ用の Remediation Task を生成 ②Security Incident Response で Security Incident を起票 する構成が素直です。既存の Remediation Task Rule や Assignment Rule にも相乗りできます。

「次回システム更新時」をどう表現するか

Remediation Target Rule は日付を算出する仕組みで、「次回更新時」という無期限の概念を直接は持ちません。 Rating = None（risk_score 0）にルールを当てず、ターゲット日なしのまま運用してダッシュボードで別管理するのを推奨します。 無理に長い固定日数を割り当てるとBODの意図が歪み、将来のOOTB対応やBOD準拠レポートとの整合も取りにくくなります。

2-5. 期限を動的に再計算する

BOD 26-04の設計思想の核心は「期限は静的ではない」ことです。初回検出のあとにKEVへ収載されたら期限は縮み、資産をインターネットから切り離したら緩む。この往復をどう成立させるかが、実装の最後の論点です。

OOTBで再計算が走るのは KEV の変化だけ

変更を検知して再計算を起動する経路は、4変数で揃っていません。

変数	変更を拾う仕組み	再計算
KEV Status	BR「Set recalculate flag (CISA)」（filter cisa_existsVALCHANGES）→ recalculate_flag → ジョブ「Run severity calculator」	自動で走る
Automatable	監視しているBRが無い	走らない
Technical Impact	同上	走らない
Asset Exposure	CMDBの属性変更はVRに伝播しない	走らない

埋めるべき3つの穴

1. SSVC変更のトリガーを作る ― sn_vul_entry にBRを1本追加し、filter を automatableVALCHANGES NQ technical_impactVALCHANGES にして current.recalculate_flag = true を立てるだけです。CISA用のBRと同じ形で、以降はOOTBのジョブが拾います。 スコープは sn_vul で作る必要があります （globalスコープからはテーブルを更新できません）
2. 曝露変更のトリガーを作る ― cmdb_ci_hardware.internet_facing の変更を拾うBusiness Rule／Flowで、その CI に紐づく active な Vulnerable Item を touch して Risk Calculator を再実行させます。CVE側の recalculate_flag は資産単位の変更には使えないため、VIを直接叩く経路が要ります
3. 保険としての一括再計算を持つ ― Risk Calculator グループには OOTB で「Reapply」（背景ジョブ "Reapply Risk Calculators"）があります。日次で回すか、規模が許すなら active な VI 全件の再計算ジョブを持つ。①②を作っても取りこぼしは出るため、突き合わせの意味があります

再計算時の起点日 ― Recalculation method の選択

同じ「KEV収載でTierが上がる」でも、ルールの Recalculation method の選択で期限がまったく変わります（first_found = 2026-06-01、KEV収載の検知が2026-08-20のケース）。

Recalculation method	算出される期限	意味
Default calculation（既定）	2026-06-15	first_found + 14。 検知日起点。BODの「KEV収載時または資産上での検知時のいずれか早い方」に忠実。 ただし即座に期限超過になる
Recalculate from risk change date	2026-09-03	KEV収載を検知した日 + 14。運用しやすいが、BODの起点定義からは外れる

BOD準拠を優先するならDefault calculation（既定）です。 ただし「古い検出がKEV入りすると即座に期限超過になる」という運用上の帰結も込みで判断してください。

2-6. 実装ステップの推奨順序

NVD連携・CISA連携アプリを導入し、CMDBの internet_facing を整備します。Risk Calculator に5本、Remediation Target Rule に4本のルールを作成し（Rating = None にはルールを作らない）、再計算トリガーの穴を埋めます。Tier内の着手順（Criticalを優先）、フォレンジック起票、延期ワークフローもあわせて設計してください。

2-7. アンチパターン ― 作り込みすぎないために

よくある失敗は、 加重加算でTierを再現しようとする 、 ルールの評価順序を誤る 、 曝露のfalse落としを怠る 、 再計算トリガーをKEVだけで済ませる 、 Remediation Target Ruleを16本作る の5つです。SSVCの器と取込コードは既に標準で存在し、将来OOTB対応が進む可能性もあるため、 過度なカスタマイズは避け、移行しやすい最小構成に留めてください。

3. 日本企業への示唆 ― 金融庁・日銀要請との対比

BOD 26-04は米国連邦民間行政機関向けの指令であり、日本企業に法的拘束力はありません。それでも参照する価値があると考える理由は、 日本でも同じ方向の要請が、ほぼ同時期に出ているから です。

3-1. 2026年5月、日本でも同じ問題に答えが出た

2026年5月18日、国家サイバー統括室を中心に14の省庁・機関が参加する政府全体のパッケージ 「Project YATA-Shield」 が公表されました。フロンティアAIモデルによる脆弱性の発見・修正等の性能向上に備え、重要インフラ事業者等への対応と脆弱性の発見・修正等への対応の双方に取り組む必要があるとしています。

その金融分野における実装として、5月22日に金融庁と日本銀行が連名で、金融機関等に対し 「フロンティアAIによる脅威変化を踏まえた金融機関等の短期的な対応」 を要請しました。経営トップを含めた経営層の直接関与のもと、概ね1ヶ月程度を目途に9項目の対応を進めることが期待されています。

9項目のうち、本記事のテーマに直接関わるのが次の2つです。

• 項目②「優先的に対応すべきサービス／ITシステムを特定する」 ：リソースが有限であることを前提にリスクベースで重点配分し、インターネットバンキング等の外部公開ITシステムを最優先とする
• 項目⑥「パッチ適用プロセスをリスクベースにする」 ：CVSSスコアや攻撃コードの有無だけでなく、自組織への影響と攻撃成立の蓋然性を踏まえて優先順位を付ける

BOD 26-04を読んだ後にこれを読むと、同じことを言っているのが分かります。

3-2. 日米の対比

| 論点 | 金融庁・日銀要請

（2026年5月22日） | CISA BOD 26-04

（2026年6月10日） | 関係 |
| --- | --- | --- | --- |
| 法的性格 | 要請（拘束力なし） | Binding Operational Directive（FCEB機関に拘束力） | 相違 |
| 優先順位の考え方 | CVSSスコアだけに依存せず、自組織への影響と攻撃成立の蓋然性で判断 | CVSSを必須入力から外し、4変数で是正期限を決定 | 一致 |
| 期限の具体性 | 9項目全体で「概ね1ヶ月」。手法・数値は規定しない | 16通りの組み合わせで3日／14日／60日／延期を厳密規定 | 相違 |
| 外部公開資産 | インターネットバンキング等を最優先 | Asset Exposure を4変数の1つとして重視 | 一致 |
| 実際の悪用の重視 | CVSSが高くない脆弱性でも実際に悪用されている実態を考慮 | KEV収載を最重要トリガーとして扱う | 一致 |
| パッチ以外の対策 | 仮想パッチ・WAF・分離等と、リスク受容手続の整備 | 曝露除去等の緩和アクションを期限充足として受容 | 一致 |
| 動機 | フロンティアAIによる脆弱性の大量発見・悪用高速化 | AIによる開示から武器化までの時間圧縮 | 一致 |

動機も方向も同じです。 違いは、CISAが4変数16通りの決定表と数値期限で厳密に規定する拘束的指令である一方、金融庁要請は手法を規定しない原則ベースの要請だという点です。

3-3. だからBOD 26-04が実装の参考になる

日本のガイドライン・要請は「リスクベースでやりなさい」とは言うものの、 その具体的な判定ロジックは各組織に委ねられています。 デジタル庁「政府情報システムにおける脆弱性診断導入ガイドライン」（DS-221）も、CVSSの基本評価基準は脆弱性の技術的特性を示すものであり、それ単体で対応の優先度を決めるべきものではない、という趣旨を示していますが、代わりに何を使うかは示していません。

ここがBOD 26-04の使いどころです。 「リスクベースの優先順位付け」を、具体的な変数と期限の対応表まで落とし込んだ、最も詳細な公開仕様のひとつ として参照できます。社内の脆弱性管理規程を改定する際、「米国連邦政府はこの4変数でこの期限を設定している」という事実は有力な論拠になります。

前身のBOD 22-01（KEVカタログ）が米連邦向け指令から民間の事実上の標準へ広がった経緯を思い出せば、同じ経路をたどる可能性は十分にあります。

まとめ

BOD 26-04が示した新しい運用

「CVSS 7.0以上は30日以内」という運用の源流であるBOD 19-02は2026年6月に廃止され、後継のBOD 26-04が示したのは「もっと厳しくやれ」ではなく 「絞れ」 というメッセージでした。CVSS一律の期限設定をやめ、曝露・KEV・自動化可能性・技術的影響の4変数、16通りの組み合わせで優先順位を決めます。急ぐべきは全体の約1%、60%以上は正式に延期してよく、期限は状況に応じて動的に変わります。同じ方向の要請は、日本でも2026年5月に金融庁・日銀から出ています。

現行バージョンのServiceNowでの対応 ― 過剰なカスタマイズは不要

BOD 26-04の5階層は、Risk Ratingの5段階（Critical / High / Medium / Low / None）にちょうど対応します。そのため Risk Score を計算 → Severity を決定 → 修復ターゲットを決定 というServiceNow本来の流れに、思ったより作り込まずに載せられます。決定木はRisk Calculatorのルール層（5本）に、対応表はRemediation Target Rule（4本）に置くだけで16通りを再現でき、着手順（Criticalを先に処理する等）もRisk Ratingで自然に決まります。実データで16通りすべての判定と期限の一致も確認済みです。

ただしこの領域は 製品側でOOTB化が進行中 でもあります。将来的に4変数から期限を決める機能そのものが標準提供される可能性もあるため、 過剰なカスタマイズはせず、移行しやすい最小限の構成に留める のが賢明です。

自社の脆弱性管理規程に「CVSS 7.0以上は30日以内」と書かれているなら、その数字の出自と、それが撤回された理由を一度確認してみてはいかがでしょうか。

※1 PCI DSS 要件6.3.3の対象範囲はバージョンにより異なります。v4.0では Critical および High のパッチを1か月以内としていましたが、v4.0.1では対象が Critical 深刻度に限定されたとする解説があります。実際に参照する際はPCI SSCの原文で対象バージョンを確認してください。

※2 この数値には留保があります。2026年版DBIRから「pretexting」が新規の初期侵入ベクターとして追加され、従来「認証情報の悪用」に計上されていた一部が再分類されました。レポート自身が、この変更がなければ認証情報の悪用は13%ではなく16%だったと明示しています。同一基準で見ると、アイデンティティ関連の初期侵入（フィッシング16%＋認証情報の悪用16%）は32%となり、脆弱性悪用の31%とほぼ並びます。「脆弱性悪用が1位」は事実ですが、アイデンティティ関連の脅威が後退したという意味ではありません。

※3 「約1%」「60%超」という数値はCISAに帰属する試算として報じられているものですが、筆者が確認した範囲ではCISAの一次文書内での記載を確認できていません。第三者ベンダーの分析記事経由の情報である点にご留意ください。

参考情報

• CISA：BOD 26-04: Prioritizing Security Updates Based on Risk
  https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk
• CISA：BOD 26-04 Implementation Guidance
  https://www.cisa.gov/news-events/directives/bod-26-04-implementation-guidance-prioritizing-security-updates-based-risk
• CERT/CC：CISA BOD 26-04 Response Model（SSVC決定表）
  https://certcc.github.io/SSVC/howto/cisa_response/
• 金融庁・日本銀行：「フロンティアAIによる脅威変化を踏まえた金融機関等の短期的な対応」に係る要請（2026年5月22日）
  https://www.fsa.go.jp/news/r7/sonota/20260522-5/20260522.html
• 国家サイバー統括室：AI性能の高度化を踏まえたサイバーセキュリティ対策の強化について ～Project YATA-Shield～（2026年5月18日）
  https://www.cyber.go.jp/pdf/press/20260518_AI_CS_Package.pdf
• デジタル庁：政府情報システムにおける脆弱性診断導入ガイドライン（DS-221）
• Verizon：2026 Data Breach Investigations Report
• CISA：Unlocking Vulnrichment: Enriching CVE Data
  https://www.cisa.gov/news-events/news/unlocking-vulnrichment-enriching-cve-data
• GitHub：cisagov/vulnrichment（README にSSVCデータの格納仕様の記載あり）
  https://github.com/cisagov/vulnrichment
• ServiceNow Docs：Remediation target rules（Vulnerability Response > Administration）
• ServiceNow Store：Vulnerability Response Integration with NVD（v30.4.2 のリリースノートにSSVC取込の記載あり）
  https://store.servicenow.com/store/app/f55b276a1b246a50a85b16db234bcb32
• ServiceNow Store：Vulnerability Response Integration with CISA
  https://store.servicenow.com/store/app/02ea27e61b246a50a85b16db234bcb2e

本記事は個人の見解に基づくものであり、ServiceNowの公式見解ではありません。記載内容は執筆時点の情報です。