- share :
WEBシステムに関するセキュリティの脆弱性情報が毎日のように流れてくる一方で、担当者は1人か兼任、月に一度のメンテナンス日にまとめて更新する、そんな運用を続けている中小企業は多いのではないでしょうか。こうした「月例パッチ運用」が悪いわけではありませんが、それだけでは守り切れる時代ではなくなってきたことも、現場の実感としてあるはずです。
2026年6月、米CISA（サイバーセキュリティ・インフラセキュリティ庁）が発出した拘束的運用指令「BOD 26-04」は、この「月に一度、全部当てる」という発想を国家として見直す号砲でした。攻撃者は脆弱性の公表から数時間で自動探索を始めます。次回の定例日を待つ間に侵入されれば、事業停止や取引先への説明にまで波及してしまうのです。
本記事では、なぜ米政府が月例パッチ運用を「もう遅い」と判断したのか、その考え方を日本の中小企業がどう現場に落とし込めるかを、資産棚卸し・KEV照合・例外ルール整備という具体的な行動レベルで整理します。
【本記事の要点】
- 米CISAは2026年6月、脆弱性を一律の期限で直す運用から、リスクシグナルの組み合わせで期限を可変にする「BOD 26-04」へ移行した
- 攻撃者の自動化速度に対して、月例パッチ運用や年次サイクルだけでは間に合わない場面が増えている
- 中小企業でも、公開資産の棚卸しとKEVカタログ照合だけで、優先順位の判断はかなり進む
- 脆弱性対応は技術部門だけの問題ではなく、業務停止や取引継続を左右する経営判断である
米CISAが打ち出した『BOD 26-04』：脆弱性対応の何が変わったのか
『BOD 26-04』は、米国の連邦民生機関に対して2026年6月10日に発出された拘束的運用指令です。正式名称は「Prioritizing Security Updates Based on Risk」、日本語で「リスクに基づくセキュリティ更新の優先順位付け」となります。
これまで連邦機関はKEVカタログ掲載脆弱性を一律の期限で修復する運用でしたが、この指令によって「同じ深刻度スコアでも、条件次第で対応期限を変える」という発想へ切り替わりました。米連邦向けとはいえ、その考え方は世界のセキュリティ運用のスタンダードに影響します。この章では、指令の骨子と従来との違いをまず整理していきましょう。
『BOD 26-04』の骨子：一律の期限から「リスクシグナル可変期限」へ
『BOD 26-04』の中心にあるのは、セキュリティ上の脆弱性を次の4つのリスクシグナルで評価し、その組み合わせによって修復期限を動的に変える考え方です。
- インターネット公開の有無
- KEVカタログ掲載の有無
- 攻撃の自動化可能性
- 成功時の技術的影響
さらに、従来のように「全部一律30日以内」ではなく、シグナルが最悪の組み合わせなら3日以内、リスクが低ければ次回のシステム更新までで良い、という濃淡を付けるようにと警鐘を発しています。
CISAは実装ガイダンスの中で、CVSS(Common Vulnerability Scoring System、共通脆弱性評価システム)の「Critical」「High」といったスコアは「具体的なアクションを指示していない」と明言しました。
ただし、深刻度スコアはあくまで技術的な特性の指標であり、自社の環境でどれほど危険かは別問題という考え方です。『BOD 26-04』は、この曖昧さをSSVC(Stakeholder-Specific Vulnerability Categorization、利害関係者固有の脆弱性分類)というフレームワークに置き換えることで整理しました。
従来のBOD 22-01との違い：KEVは残るが「期限」が可変になった
2021年に発出された『BOD 22-01』は、KEV(Known Exploited Vulnerabilities、既知悪用脆弱性)カタログに載った脆弱性を期限内に修復することを義務付けたものでした。この仕組みは今も生きていますが、期限が一律であったために、リスクの高低に関わらず同じスピードで走ることになり、現場が疲弊する副作用を抱えていました。
『BOD 26-04』は『BOD 22-01』を置き換えるのではなく、進化させた位置付けです。KEV掲載という事実に加えて、他のシグナルの組み合わせで期限を分けることで、「本当に危険なものにリソースを集中させる」設計に変わりました。
3日以内、14日以内、次回更新まで：具体的な期限のイメージ
CISAが示す例では、最悪の組み合わせ、つまり「KEVに掲載されており、インターネットから直接到達可能で、攻撃が自動化されており、成功すれば完全制御を奪われる」脆弱性については、3日以内の修復と、既に侵入されていないかを確かめる「フォレンジック・トリアージ＊」の実施が求められます。
一方で、内部限定のシステムに存在し、KEVにも載っておらず、攻撃の自動化も難しい脆弱性は、次回のシステム更新やライフサイクル交換のタイミングでの対応で良いとされます。
CISAが行った初期分析でも、ある大規模民生機関の脆弱性のうち3日対応が必要なものは約1パーセント、逆に60パーセント超は次回更新まで先送り可能という結果が示されました。連邦機関は指令発出後180日以内に、この新しい優先順位付けと修復タイムラインを実装することが求められています。
＊フォレンジック・トリアージ：サイバー攻撃や情報漏洩などのインシデント発生時、すべてのデジタル機器を詳細に調査する前に、限られたデータ（揮発性メモリや重要ログなど）を迅速に収集・分析し、被害の緊急度や調査の優先順位を判断する初動プロセス。
出典・参照：
なぜ月例パッチ運用だけでは追いつかなくなったのか
読者の多くは、Microsoft社のPatch Tuesdayを起点に、月例メンテナンスでまとめてパッチを適用する運用に慣れているはずです。この運用自体を否定するつもりはなく、ベースとしては今も有効です。しかし「それだけで守り切る」ことは年々難しくなっています。この章では、その理由を数字と現場感の両面から見ていきます。
脆弱性の公開から悪用までの時間差が縮んでいる
かつては、システムの脆弱性が公開されてから実際の攻撃コードが出回るまでに数週間から数ヶ月の余裕がありました。しかし、現在は攻撃者側も高性能なAIを活用するなどして攻撃自体が高度化し、公開当日から自動スキャンが世界規模で始まり、数時間で悪用の試みが観測される例も報告されています。攻撃者は攻撃コードを共有し、探索を自動化し、脆弱な資産を数珠つなぎに侵害していくのです。
このスピードに対して、月例メンテナンス日まで待つ運用だと、それだけで最大30日弱の空白を作ってしまいます。すべての脆弱性でこの空白が命取りになるわけではありませんが、悪用が始まっている脆弱性については、この空白はそのまま被害の入口になってしまうでしょう。
KEV掲載脆弱性の完全修復率は26パーセント：修復まで中央値43日
Verizon社の『2026 Data Breach Investigations Report(DBIR)』の分析をCISAが引用した資料によれば、KEVカタログ掲載の脆弱性のうち、2025年に完全修復できたのは全体の26パーセントにとどまり、前年の38パーセントから低下しました。さらに完全解決までにかかった日数の中央値は43日という水準です。
つまり、既に世界のどこかで悪用が確認されている脆弱性であっても、企業側は半月から1ヶ月半かけて修復している、あるいは修復し切れていない実態が浮かび上がります。この数字は米国主体の統計ですが、日本の現場実感とかけ離れているとは言えません。
「全部当てる」運用が現場を疲弊させ、本当のリスクを見落とす
もう1つ見落とせないのが、現場担当者の疲弊です。月例で数十本、時には百本を超える更新プログラムを検証し、業務システムへの影響を確かめ、順次適用していく作業は、片手間で回せる規模ではなくなっています。すべてを平等に扱うほど、本当に危険な脆弱性を見極める余力が削られていきます。
『BOD 26-04』の背景には、この「パッチ・エブリシング」からの脱却という発想があります。CISAが指令と併せて発表したブログ「Patch Smarter, Not Harder(もっと賢く、もっと少なく直す)」は、この方針転換を象徴しています。
出典・参照：
CVSSからSSVCへ：優先順位を決める4つの判断軸
『BOD 26-04』では、CVSSの数値だけに頼らず、SSVCと呼ばれるフレームワークで先に紹介した4つの判断軸を組み合わせて評価します。名前は難しく聞こえますが、中小企業でも紙一枚のチェックリストに落とし込める発想です。4つの判断軸を詳しく解説します。
判断軸1：インターネットに公開されているか
まず問われるのは、その脆弱性を抱える機器やソフトが、インターネットから直接到達できるかどうかです。
- VPN機器
- 公開WEBサーバ
- 外部連携API
- リモートアクセス経路
などが該当します。外部から直接叩ける資産は、脆弱性が悪用される確率が跳ね上がるため、優先度が最も高くなります。
逆に、社内ネットワーク内部にしか存在せず、しかもセグメント分離されている場合は、同じ脆弱性でも優先度は下がります。ここで気を付けたいのは「社内にしかないつもり」が実際には認証迂回で外部から到達可能というケースがあることです。棚卸しの段階で、通信ログや外部からのポートスキャン結果と突き合わせておくと精度が上がります。
判断軸2：KEVカタログに掲載されているか
CISAが公開しているKEVカタログは、実際に攻撃で悪用されたことが確認された脆弱性のリストです。世界のどこかで既に悪用されているという意味なので、これに載っている脆弱性は理屈上、明日にでも自社に飛んでくる可能性があります。
日本の中小企業でも、KEVカタログを週次でチェックするだけで、「対応を急ぐべき脆弱性」を無料で識別できます。JPCERT/CCやIPAのJVN(Japan Vulnerability Notes)注意喚起と併せて見れば、国内利用の多い製品との照合も進みます。
判断軸3：攻撃の自動化が可能か
3つ目は、脆弱性の悪用が自動化されているかどうかです。攻撃コードが公開ツールに組み込まれていたり、認証なしでリモートから実行できたりする場合、攻撃はスクリプトによって世界規模で無差別に走ります。この場合、標的にされるのは「有名企業」ではなく「開いたままにしていた企業」です。
自動化された攻撃の前では、企業規模は関係ありません。中小企業だから狙われないという想定はもう機能しない、と考えるべき局面に入っています。
判断軸4：成功時の技術的影響(完全制御か、限定的か)
4つ目は、悪用に成功したときの技術的な影響範囲です。管理者権限の完全奪取につながる脆弱性と、情報の一部読み取りに限られる脆弱性では、対応の急ぎ方が当然変わります。この観点は、CVSSの「機密性・完全性・可用性」への影響と近い部分もありますが、SSVCではより「攻撃者に何ができるか」に踏み込んで整理しなければなりません。
4軸の組み合わせで期限が変わる：中小企業向けの読み替え
この4つを組み合わせると、期限のイメージは次のように整理できます。
| リスクシグナルの組み合わせ | 目安の対応期限 | 中小企業向けの読み替え |
|---|---|---|
| 公開×KEV掲載×自動化×完全制御 | 3日以内＋侵害有無の確認 | 定例日を待たず即時対応の対象 |
| 公開あり×KEV掲載あり(他は中程度) | おおむね14日以内 | 次の週末までに検証と適用 |
| 公開あり×KEV未掲載(将来悪用の可能性) | 数週間以内 | 直近の月例メンテナンスで対応 |
| 内部限定×KEV未掲載×影響限定 | 次回定例更新まで可 | ライフサイクル交換に合わせる |
この表からも分かる通り、貴社が直面する脆弱性の多くは「即時対応」ではなく「順序を付けて計画的に処理する」対象です。逆に、公開資産に紐づくKEV掲載脆弱性が見つかった瞬間だけは、月例パッチを待たない判断が求められます。すべて同じ扱いにするより、はるかに現実的な運用でしょう。
出典・参照：
執筆者
DXportal®運営チーム
DXportal®編集部
DXportal®の企画・運営を担当。デジタルトランスフォーメーション（DX）について企業経営者・DX推進担当の方々が読みたくなるような記事を日々更新中です。掲載希望の方は遠慮なくお問い合わせください。掲載希望・その他お問い合わせも随時受付中。