[RHEL運用の実態] CVEは6年で4.3倍。それでも「緊急対応」は増えていない

増えているのはCVEトリアージの工数 ― 数字で見るRHELを採用する価値

「AIが脆弱性を見つけるようになり、CVEが爆発的に増えている」という話を耳にする機会が増えました。実際、数字はその通りで、2026年7月は単月で月間1万件に迫る水準に達しています。しかし現場の運用負荷が同じ倍率で増えているかというと、答えは違います。

今回、CVE Program公式のCVE List v5から公開済みレコード354,380件を取得し、公開日ベースで月次集計しました。あわせてRed Hatが公開している「Product Security Risk Report 2025」の実績値と突き合わせ、RHEL運用における負荷の実像を整理しています。

結論を先に述べます。増えているのは「危険な脆弱性」ではなく「危険でないと証明する作業」、すなわちCVEトリアージの工数です。 そしてその作業量は、予測可能な比率で推移しています。

1. CVE増加は事実。しかし緊急対応の頻度は増えていない

まず全体像です。全世界で公開されたCVEの年次推移は以下のとおりでした。

2020年から2026年で約4.3倍。2026年7月単月では9,618件が公開されており（2026年7月31日時点のスナップショット値。後述する公開遅延により今後さらに増加する見込みです）、月次件数は2020年初頭の約1,500件から6倍以上になっています。FIRST（Forum of Incident Response and Security Teams）は2026年の総数を約66,000件と予測していますが、実績はそれを上回るペースで進んでいます。

ここまでは、よく語られる「爆発」の話と一致します。問題は次です。

Red Hatが2025年に評価したCVEは5,478件でした。その内訳を見ると景色が変わります。

※ Red Hatのレポート原文では合計5,478件と記載されていますが、深刻度別の内訳を合算すると5,477件となり、1件の差があります。本記事では一次資料の記載を優先し、原文の数値をそのまま掲載しています。2024年実績の4,272件に増加分+1,206件を加えると5,478件となるため、合計値としての整合性は取れています。

Criticalは年間わずか3件で、2年連続の減少です。そして実際に「野生での悪用」が確認されたのは9件。5,478件の0.16%に過ぎません。

さらに注目すべきは増加分の内訳です。前年から増えた1,206件のうち、84%はModerate/Lowでした。Criticalは減っています。

つまり件数の爆発は、緊急対応キューではなく、その手前の評価待ちキューで起きています。

背景の大きな要因はLinux kernel CVE Numbering Authority（CNA）の稼働です。2024年2月の開始以降、kernel由来のCVEは2024年に4,321件、2025年に5,679件と、全世界CVEの1割超を占める規模になりました。Red Hatはこの追加負荷について、標準的なRHEL利用ケースにとって重大なリスクとは判断していないものが大半であると明言しています。2025年にKEV（既知の悪用脆弱性カタログ）へ登録されたkernel CVEは6件で、うち5件は過去年の開示分、多くはAndroid向けかつ物理アクセスを要するものでした。

2. 増えるのはトリアージ工数。しかも比率11%で予測できる

では、RHEL側の負担はどう増えるのか。ここに実務上きわめて有用な性質があります。

Red Hatが評価するCVEが全世界CVEに占める比率は、ほぼ一定です。

成長倍率で見ても、2020年から2025年で全世界が2.62倍、Red Hat評価CVEが2.77倍。ほぼ同じです。

つまりAIによるCVE増加はRHEL固有の負担を生んでいるのではなく、全体と同じ比率で押し上げているだけです。逆に言えば、全世界CVEの見通しが立てば、RHEL側の工数は11%前後という係数で機械的に予測できます。

これを1営業日あたりに換算すると、負荷の実感に近づきます（年250営業日換算）。

2025年のRHSA発行数は3,781件（前年比+27.1%）で、うちRHEL製品ファミリー向けが2,671件。この2,671件が、変更管理とパッチ適用の実際の主戦場です。

読み取るべきポイントは2つあります。

第一に、2026年に日次36件の評価を人手で追うのは現実的ではありません。第二に、そのうち即応が必要なものは月1件未満です。Red Hatの2025年の平均初回修正リリース時間は、Importantが24日、Moderateが79日でした。この差が示すのは、すべてを同じ速度で処理する必要はないということです。

必要なのは処理能力の増強ではなく、優先度による分離です。

3. Lightspeedはトリアージの「母数」を切る仕組み

ここで、今回の調査で最も実務的な示唆を得た点に触れます。

私たちはCVE List v5の全レコードから、参照URL（access.redhat.com、bugzilla.redhat.com）、affected製品名、Red Hat採番のいずれかに該当するCVEを機械的に抽出しました。2025年の該当件数は**353件、全体の0.7%**でした。

一方、Red Hatが実際に評価したCVEは5,478件。約16倍の乖離です。

理由は単純です。Red HatはRHELが同梱する全パッケージについてCVEを網羅的に評価しますが、その事実はCVEレコード側には一切記録されません。生のCVEフィードを眺めていても、自環境が影響を受けるかは分からないのです。

この非対称性を埋めるのがRed Hat Lightspeedです。従来のRed Hat Insightsが、2025年11月にRed Hat Lightspeedブランドへ統合・再編されたものにあたります。名称は変わりましたが、advisor・vulnerability・complianceといった既存サービスの機能はそのまま継承されており、エージェントのコマンド名も従来どおり insights-client が維持されています。既存のInsights利用環境から移行作業は発生せず、Red Hat Satellite のUI上でも段階的に表記が置き換わる形で進んでいます。

Lightspeedのvulnerability serviceは、insights-client が各RHELシステムから収集した情報を、Red HatのCVEデータベースとセキュリティデータに突き合わせて評価します。これにより、管理対象が「世の中のCVE件数」から「自環境で実際に該当する件数」に切り替わります。Satelliteのホストグループ、SAPなどのワークロード、カスタムタグでの絞り込みにも対応しており、システム群ごとの分割管理が可能です。

運用設計上、重要な点を3つ挙げます。

1. RHELサブスクリプションに含まれています。 追加費用なしで利用できます。前述のトリアージ工数の問題は、新規購買を伴わずに着手可能です。

2. 修復までつながります。 2026年4月に新しいremediation workflowが追加され、検出した問題に対するAnsible Playbookの生成とRed Hat Ansible Automation Platformでの実行という経路が標準化されました。ServiceNowやSplunkなど既存ツールとの連携も維持されています。

3. 閉域環境でも利用できます。 日本国内では「ホスト情報を社外SaaSに送信できない」という制約が頻繁に論点になりますが、Red Hat Lightspeed on premiseではホストテレメトリはすべてローカルに留まり、ファクト・パッケージリスト・脆弱性評価・advisor推奨はSatelliteのPostgreSQLデータベースで処理・保存されます。外部への送信はありません。脆弱性サービスは静的なcvemap.xmlファイルを参照する構成のため、完全分離環境では自組織のスケジュールでファイルを持ち込めます。外向きのネットワーク要件はありません。

金融・公共・製造業の閉域系システムにおいて、これは実装可否を左右する条件です。

まとめ

今回の分析から言えることを3点に整理します。

1. CVEの増加は事実である。全世界で2020年比4.3倍、2026年は年間78,000件ペース。
2. しかし緊急対応の頻度は増えていない。 Red Hat製品に影響したCriticalは2025年に3件、悪用確認は9件。増加分の84%はModerate/Low。増えているのはトリアージ工数であり、その量は全世界CVEの11%前後という安定した比率で予測できる。
3. 対処の第一歩はトリアージの母数を切ること。 CVEレコードには自環境への該当性が書かれていないため、Lightspeedのような突合の仕組みが必要になる。これはRHELサブスクリプションに含まれ、閉域環境にも対応する。

「AIで脆弱性が爆発する」という危機感の共有は、それ自体は正しい認識です。しかし対策の設計は、量が増えても構造は予測可能であり、優先度による分離で吸収できるという理解の上に立つべきです。全件を同じ速度で処理しようとする限り、どれだけ人員を増やしても追いつきません。

そして、分離したあとの「適用」を支える仕組みも揃いつつあります。RHEL 10のImage Mode（bootc）とSatelliteの組み合わせにより、更新のダウンロードと適用を分離し、段階的な展開と数秒での切り戻しが可能になっています。「全部凍結」でも「全部即適用」でもない運用モデルが、すでに機能として成立しています。

出典・調査方法

• 全世界CVE件数：CVE Program公式 CVE List v5（cvelistV5）の2026年7月31日時点スナップショットより、state=PUBLISHED のレコードを datePublished ベースで集計。対象354,380件。REJECTEDレコードは除外。
• Red Hatの評価CVE数、RHSA件数、深刻度別内訳、悪用実績、平均応答時間：Red Hat「Product Security Risk Report 2025」（2026年4月10日公開）および「2024 Red Hat Product Security Risk Report」
• 2026年予測：FIRSTによる2026年CVE予測、および本集計の実績ペースによる年率換算。※年率換算は経過日数ベース（1〜7月＝212日、45,480件 ÷ 212日 × 365日 ≒ 78,300件）で算出しています。単純な月割り（÷7×12）では約78,000件となります。
• 深刻度別内訳の合計：一次資料の記載に合計値と内訳合算の1件差があります（本文の※注参照）。本記事は原文の数値をそのまま採用しています。
• 営業日換算：年250営業日として算出
• Red Hat Lightspeed、Satellite、bootcの機能：Red Hat公式ドキュメントおよびRed Hatブログ（2025年11月〜2026年6月）

なお、CVEの公開日は発見日や開示日ではありません。2026年公開分のうち約4,900件は2025年採番のIDであり、数ヶ月から数年の公開遅延が常態的に存在します。直近月の数値は今後さらに増加する可能性があります。