Ciscoが脆弱性情報の出し方を大きく変えました。2026年7月から、原則として毎月第1・第3水曜日の16:00 UTCにセキュリティアドバイザリを定期公開し、その7日前に「どの製品が対象か」を予告する運用に移行しています。直近の予告では、2026年8月5日にCatalyst SD-WAN、IOS、IOS XEなど6製品のアドバイザリが公開される予定です。
Cisco機器を抱える情シスにとっては「公開日に慌てて調べる」運用からの切り替えを迫る変更ですが、実務へのインパクトはむしろ、同時に進むCVEの付け方の変更のほうが大きいかもしれません。
この記事でわかること
- Ciscoの新しい開示スケジュールの具体的なルール
- 2026年8月5日に公開予定の対象製品
- CVEが「CWE単位」で束ねられることの実務的な意味
- 7日間の予告期間を情シスがどう使うべきか
※本記事は2026年7月31日時点の公開情報に基づいています。
Ciscoは何を変えたのか
Ciscoが2026年7月から始めたのは、リスクベースの脆弱性開示モデルです。個々の脆弱性を見つけ次第バラバラに公開するのではなく、修正版（セキュリティ強化リリース）とセットで決まった日にまとめて出す、という考え方に変わりました。
| 項目 | 新しい運用 |
|---|---|
| 定期公開日 | 毎月第1・第3水曜日 16:00 UTC（対応する強化リリースが用意できた場合） |
| 事前予告 | 公開の7日前に、対象となる技術・プラットフォームを告知 |
| 主要NOSの更新頻度 | IOS XE / IOS XR / NX-OS / Secure Firewall・ASA / SD-WAN は四半期ごとを想定 |
| CVEの付け方 | 同じ弱点分類（CWE）の修正を1つの「傘（umbrella）」CVEに束ねる |
| CVSS | そのCWEグループ内で最も深刻なものに合わせて付与 |
| 例外 | 悪用確認・ゼロデイ・重大なOSS由来の問題などはサイクル外で随時公開 |
| 開始時期 | 2026年7月 |
月2回なのに「四半期ごと」とはどういうことか？
公開の「枠」が月2回あり、各プラットフォームの強化リリースがおおむね四半期に1回その枠に載る、という関係です。つまり毎回すべての製品が対象になるわけではありません。自社の主力機器がIOS XEなら、だいたい3か月に1度、大きめの更新イベントが来ると考えておけば見当が付きます。
2026年8月5日には何が公開されるのか
2026年7月29日16:00 GMTに公開された事前通知（cisco-sa-notice-L4XfJg8S）によると、8月5日にアドバイザリが公開される予定の製品は次の6つです。
- Catalyst SD-WAN
- Integrated Management Controller（IMC）
- IOS Software
- IOS XE Software
- RoomOS
- Terminal Services Agent
現時点で公開されているのは製品名だけで、脆弱性の件数・深刻度・悪用状況・影響を受けるバージョンは明かされていません。予告で分かるのは「対象製品」と「回避策は用意されない」の2点だけ、と割り切る必要があります。IOS／IOS XEやIMC（UCSサーバの管理コントローラ）は社内ネットワークの根幹に入っていることが多く、この段階で該当機器を洗い出せるかどうかが、8月5日以降の初動速度をそのまま決めます。
なぜ変えたのか──AIが脆弱性発見を加速させた
Ciscoは2026年6月2日のブログ（Russ Smoak氏／セキュリティ保証・対応担当VP）で理由をはっきり書いています。フロンティアAIモデルと自動解析が大規模コードベースからバグを見つける速度が、従来の「1件ずつCVEを起こして個別に公開する」モデルでは処理しきれない水準に達した、というものです。そのうえで最も有効な防御は「堅牢化された現行リリースを動かし続けること」だと主張しています。
AIによる脆弱性発見の加速が既存の枠組みを揺らしている点はMicrosoftの月例パッチが569件に達した件でも触れました。ベンダーを問わず起きている構造変化と見たほうがよさそうです。
実務に一番効くのは「CVEがCWE単位に束ねられる」こと
新モデルで最も影響が大きいのは、公開日程よりもこちらです。Ciscoは複数のバグをCVE（共通脆弱性識別子）で1件ずつ識別するのをやめ、弱点の分類（CWE）ごとにまとめて1つのCVEを割り当てる方式に切り替えました。
実例が2026年7月15日の「Cisco RoomOS Security Hardening Release: July 2026」です。社内テストで発見された複数の脆弱性（悪用は確認されていないとされています）が、次のようにCWE単位で整理されました。
| CVE | CWE分類 | CVSS |
|---|---|---|
| CVE-2026-20150 | CWE-284（不適切なアクセス制御） | 8.8 |
| CVE-2026-20156 | CWE-119（バッファ境界の不備） | 8.1 |
| CVE-2026-20153 | CWE-20（入力値検証の不備） | 7.5 |
| CVE-2026-20157 | CWE-311（暗号化の不備） | 7.5 |
| CVE-2026-20158 | CWE-664（リソース管理の不備） | 7.5 |
| CVE-2026-20187 | CWE-703（例外処理の不備） | 7.5 |
重要度はHigh（最大CVSS 8.8）、対象はRoomOS 11系と26系、回避策はなしで、修正版へのアップグレードだけが対処法です。
この方式の何が困るのか？
「CVE 1件＝バグ1件」という前提で組み上げてきた脆弱性管理の運用が、そのままでは成立しなくなる点です。具体的には次のような影響が出ます。
- 件数が実態を表さなくなる：1つのCVEの裏に何件の修正が入っているのか、外からは分かりません。「今月のCisco関連CVEは6件」と報告しても、修正されたバグの実数は不明です。CVE件数を脆弱性管理のKPIにしている組織は、数字の連続性が失われます。Dell PowerProtectの359件のように「件数の多さ」で危機感を伝えてきた説明の仕方も、Cisco製品では通用しにくくなります。
- CVSSが「グループ内の最大値」になる：CVSSスコアはそのCWEグループで最も深刻なものに合わせて付きます。同じCVEに含まれる軽微な修正まで高スコアで表現されるため、スコアだけを見た優先度付けは実態からずれます。
- 「自社は影響しない」という判断ができない：個別の技術詳細が公開されないので、「この機能を使っていないから対象外」といった緩和判断の材料がありません。
- 回避策で時間を稼ぐ選択肢が消える：新モデルの強化リリースは「回避策なし」が基本です。ACLや設定変更でしのぐ、という常套手段が使えず、アップグレード一本になります。
情シスはどうすべきか
7日間の予告をどう使うか
予告が価値を持つのは、リソースが増えるからではなく、社内調整を前倒しできるからです。実務的には次の順で使うのが現実的でしょう。
- 資産台帳で引き当てる：予告に出た製品名で、機種・OSバージョン・設置場所・保守契約の有無を確認する。ここで時間がかかるなら、そもそも台帳の精度が課題です。
- 変更窓を仮押さえする：ネットワーク機器は止められる時間が限られます。公開日を待たずに夜間・休日の枠だけ確保しておく。
- アップグレード手順を先に確認する：回避策がない前提なので、検証環境での手順確認・切り戻し手順の整備を先に済ませておく。
- 修正版が出ない機器を洗い出す：EoS/EoL機器や保守契約が切れている機器は、そもそもアップグレードできません。これが最も重い宿題で、予告期間に着手すべき本命です。
- 公開当日は差分だけ見る：予告になかった製品が追加されていないか、悪用確認の記載があるかを確認する。
対策の指針は公的資料へ
脆弱性管理・資産管理の体制づくりは、自前でチェックリストを作るより公的な指針をベースにしたほうが、経営層への説明も通りやすくなります。資産把握と更新管理の考え方は、IPAの中小企業の情報セキュリティ対策ガイドラインがまず参照しやすい資料です。利用部門への周知にはIPAの対策のしおりのような啓発資料を併用すると手間が減ります。地味ですが、この積み重ねが緊急アップグレードで業務を止めるときの合意形成を楽にします。
あわせて、Cisco Security AdvisoriesのRSS購読を担当者個人ではなくチームのメーリングリスト等で受ける形にしておくと、予告を取りこぼしません。
現場目線の所感
正直なところ、予告が7日前に出ても作業できる人員が増えるわけではありません。ネットワーク機器の更新は「止められる時間が月に数時間しかない」という制約のほうが支配的で、予告を見ても打てる手が変わらない現場は多いはずです。
それでも前向きに受け止められる点が一つあります。「いつ来るか分からない」から「いつ来るか分かる」に変わったことです。突発のゼロデイ対応で夜間作業を頼み込むのと、四半期に1度の定例作業として年間計画に組み込むのとでは、他部署との交渉のしやすさがまるで違います。変更管理の稟議を毎回ゼロから起こしている組織ほど恩恵は大きいでしょう。
逆に気が重いのは「回避策なし」が標準になることです。設定変更でしのいで次の定期メンテまで持ち越す、という現実的な逃げ道が塞がると、アップグレードできる体力があるか——保守契約が生きているか、検証環境があるか、切り戻せるか——が、そのまま組織のセキュリティ水準になります。台帳の隅にある「誰も触りたがらない古い機器」に、また向き合わされることになりそうです。
中長期の視点
この動きはCisco固有の事情ではありません。AIによる脆弱性発見の加速はどのベンダーにも同じ圧力をかけており、他社が似た方式を採る可能性は十分あります。CVEをCWE単位で束ねる方式が広がれば、脆弱性管理は「CVEを1件ずつ潰す」ゲームから「サポートされた最新版を動かし続ける」運用へ重心が移り、効いてくるのは検知や分析の精緻さより、保守契約の維持・EoL管理・アップグレードを回せる人員と検証環境という地味な体力になります。保守費やリプレース計画を議論する材料として、この変更は使えるはずです。
まとめ
- Ciscoは2026年7月から、脆弱性情報を毎月第1・第3水曜日16:00 UTCに定例公開し、7日前に対象製品を予告する運用へ移行した。8月5日はCatalyst SD-WAN、IOS、IOS XEなど6製品が対象。
- より影響が大きいのはCVEの付け方の変更で、同じCWEの修正が1つのCVEに束ねられ、CVSSはグループ内の最大値が付く。CVE件数やスコアだけで優先度を判断する運用は見直しが必要。
- 回避策なしが基本になるため、予告期間の7日間は「資産の引き当て」と「修正版が出ない機器の洗い出し」に使うのが最も効果的。
出典
- Cisco’s Transition to a Risk-Based Vulnerability Disclosure（Cisco）
- Cisco Advance Notification for Publication of August 5, 2026, Security Advisories（Cisco、2026年7月29日）
- Cisco RoomOS Security Hardening Release: July 2026（Cisco、2026年7月15日）
- Strengthening the Foundation: A Predictable, Customer-Focused Response to AI-Accelerated Vulnerability Discovery（Cisco Blogs、2026年6月2日）
- Cisco、8月5日に複数製品の脆弱性情報を公開予定（Security NEXT）
- 中小企業の情報セキュリティ対策ガイドライン（IPA）
