CVEフィードのEOL盲点：SCAツールの見落とし

HeroDevsのプリンシパル・プロダクト・マネージャー、アイザック・ウエストが書いた。

セキュリティ・チームがエンド・オブ・ライフ（EOL）のオープンソース・ソフトウェアについて考えるとき、その会話はたいてい同じところで始まり、同じところで終わる。

それは事実だが、それは話の半分に過ぎない。ほとんどのチームが気づいていない複合的な問題が2つある。

問題1：CVEエコシステムはサポートしていないものを調査しない

オープンソース・プロジェクトで脆弱性が発見されると、メンテナはどのバージョンが影響を受けるかを決定し、影響を受ける範囲を定義してCVEを提出する。業界のあらゆる脆弱性スキャナー、SBOMツール、CVEフィードがその範囲を消費する。

もしあなたのバージョンがその範囲外であれば、警告は届かない。安全だからではなく、誰もチェックしなかったからだ。

EOLバージョンは、ほぼデフォルトでその範囲外になる。理由は簡単で、規模の問題だ。Sonatype社の「2026 State of the Software Supply Chain」レポートによると、わずか5年の間に、世界のCVE数は倍増し、スコアリングされていないCVE数は37倍に増加した。

CVE数とパッケージリリースの総数の両方が増加し続ける中、古いリリースラインをカバーするために必要な調査帯域幅は単純に存在しない。

メンテナは、自分たちのリリース履歴のどこまで遡ることが合理的なのか、現実的に考える必要があります。

Sonatype社の調査では、「アドバイザリから漏れているEOLバージョン」が誤ったセキュリティの信頼性を高める要因であることを明示しており、2025年だけで167,286件の偽陰性（悪用可能なコンポーネントでありながら、まったくフラグが立っていないもの）が確認されています。

a.fl_button { background-color：#border：1px solid #3b59aa; color：#text-align: center; text-decoration: none; border-radius: 8px; display: inline-block; font-size: 16px; font-weight: bold; margin：4px 2px; cursor: pointer; padding：12px 28px; } .fl_ad { background-color：#width: 95%; margin: 15px auto 15px auto; border-radius: 8px; border：1px solid #d6ddee; box-shadow: 2px 2px #728cb8; min-height: 200px; display: flex; align-items: center; } .fl_lef>a>img { margin-top: 0px !important; } .fl_rig>p { font-size: 16px; } .grad-text { background-image: linear-gradient(45deg, var(–dawn-red), var(–iris)54%, var(–aqua)); -webkit-text-fill-color: transparent; -webkit-background-clip: text; background-clip: text; } .fl_rig h2 { font-size: 18px!important; font-weight: 700; color：color: #333; line-height: 24px; font-family：font-family: Georgia, times new roman, Times, serif; display: block; text-align: left; margin-top: 0; } .fl_lef { display: inline-block; min-height: 150px; width: 25%; padding：10px 0 10px 10px; } .fl_rig { padding：10px; display: inline-block; min-height: 150px; width: 100%; vertical-align: top; } .fl_lef>a>img { border-radius: 8px; } .cz-news-title-right-area ul { padding-left: 0px; } @media screen and (max-width: 1200px) { .fl_ad { min-height: 184px; } .fl_rig>p { margin: 10p10px; } .fl_rig { padding：0 10px 10px 10px; width: 100%; } } @media screen and (max-width: 400px) { .cz-story-navigation ul li:first-child { padding-left: 6px; } .cz-story-navigation ul li:last-child { padding-right: 6px; } } }.

実際のところ

Springエコシステムにおける最近の2つの重大な脆弱性が、これを具体的に示しています。

CVE-2026-22732 – Spring Security (クリティカル、2026年3月、CVSS 9.1)

この脆弱性は、特定のサーブレットアプリケーション構成において、Cache-Control、X-Frame-Options、Strict-Transport-Security、Content-Security-Policy を含むセキュリティ応答ヘッダがサイレントドロップされる原因となります。公式に影響を受ける範囲はSpring Security 5.7.xから7.0.xまでです。

Spring Security 6.2.xはリストにない。それは2025年12月にEOLに達した。Spring Boot 3.2にはSpring Security 6.2が同梱されています。Boot 3.2を実行している組織は、記載されている範囲のマイナーバージョンから1つ遅れているが、スキャナシグナルを受け取らない。

HeroDevsはSpring Security 6.2.xが影響を受けることを確認し、NESの顧客のために修正をバックポートした。アップストリームのCVEレコードには反映されていません。

どのくらいの頻度で起こるのか？

上記のSpringの例は異常値ではありません。HeroDevsがNever-Ending-Supportを実践する中で一貫して遭遇するパターンを反映しています。

新しいCVEがサポートされているパッケージで公開されたとき、HeroDevsは、公式のCVEレコードが影響を受けるものとしてリストしていないEOLバージョンにパッチを当てる必要があることを約80％の頻度で発見します。どのような脆弱性であっても、その影響範囲は記録で示されている範囲よりも体系的に広い。

わかりやすく言えば、サポートされているバージョンで公開されている5つのCVEのうち4つは、あなたが使用しているEOLバージョンも影響を受けている可能性があります。

問題2：業界は誤ったEOLソフトウェアをカウントしている

上記のCVE調査のギャップは、コミュニティが実際にEOLであることを知っているEOLソフトウェアに適用される。これは、本当の問題のごく一部であることがわかります。

EOLデータの最も広く引用されている情報源は、endoflife.dateである。このendoflife.dateは、保守者がEOLの日付を明確に公表している主要なフレームワークやランタイムなど、アクティブに保守されている約350のプロジェクトを追跡している。

これらの350のプロジェクト全体で、およそ7,000の特定のパッケージのバージョンがEOLとして特定されている。これは、ほとんどのスキャナーとセキュリティ・チームが作業している範囲である。

これが問題の実際の規模である。

HeroDevs社との提携で作成されたSonatype社の2026年ソフトウェアサプライチェーンレポートでは、データは異なるストーリーを語っている。npm、PyPI、Maven、NuGet、RubyGems、Go、Packagist、crates.ioにまたがる1,200万バージョンのパッケージのライフサイクル状況を分析したところ、HeroDevsはこれらのバージョンのうち540万バージョンが使用済みであることを発見した。

しかし、業界で最も完全な公開ソース（endoflife.date）は、そのうちの〜7,000を占めるに過ぎない。

エコシステム別の内訳は注目に値する。npmパッケージバージョンの約25%がEOLである。NuGetは約18％、Cargoは13％、PyPIは11％、Maven Centralは10％だ。これらは現在、企業のSBOMに積極的に登場しているバージョンであり、CVE調査カバレッジも修正パスもない。

Sonatypeのレポートによると、企業の依存関係グラフにあるコンポーネントの5～15%はEOLであり、チームがサポートされているトップレベルのライブラリしか使用していないと思っていても、EOLにさらされていることがわかります。あなたのパッケージが依存しているパッケージである移行依存関係は、この隠れたエクスポージャーの大部分を担っています。

ほとんどの組織では、EOLへの暴露を大幅に過小評価しています。彼らのツールは、大規模な放棄を検出するようには作られていない。

HeroDevsは、既知のCVEがあり、利用可能な修正パスがない81,000以上のEOLパッケージバージョンを確認しました。

サポートされているバージョンに存在するCVEのおよそ80%は、公式には調査されていないEOLバージョンにも影響を及ぼしていることを考えると、本当の数ははるかに大きい可能性が高い。HeroDevsは、実際の数字はすべてのレジストリで40万件以上に近いと推定している。

なぜ悪化しているのか

この動きは新しいものではない。新しいのは、それが複合化している速度である。

OSSのエコシステムは、それを監視するために構築されたセキュリティインフラを上回るスピードで拡大している。npmだけで、2025年に重大なCVSS 9.0+スコアに関連するリリースが83万8000件以上記録された。PyPIのダウンロード量は前年比で50%以上増加した。

レジストリに登録されるすべての新しいパッケージのバージョンは、将来のEOLバージョンであり、EOLの人口は継続的に増加するが、それをカバーする調査能力は増加しない。

しかし、より重要な強制機能はAIかもしれない。

2026年4月、Anthropicはクロード・ミトス・プレビューとともにプロジェクト・グラスウイングを発表し、主要なOSやブラウザのゼロデイ脆弱性を特定し、悪用する能力を文書化した。

このイニシアチブは、攻撃者に悪用される前に重要な脆弱性を発見し、修正することを目的とした防御的なものである。

積極的なサポートを受けるソフトウェアにとって、これは本当に良いニュースだ。AIスケールで発見された脆弱性は、それに対処できるエンジニアにルーティングすることができる。

製造中止のソフトウェアについては、計算が異なる。コードベース全体にわたって脆弱性を発見するAIは、メンテナが見ていないバージョンの発見を表面化させるだろう。これらの発見は、EOLの影響を受ける範囲に対して公式に調査されることはない。

EOLユーザーのためにスキャナーの警告が発せられることもない。アップストリームパッチで対処されることもない。サポートされているソフトウェアの防御を加速させる同じ機能が、すでに取り残されたすべてのものに対する暴露のギャップを広げている。

このシフトの初期のシグナルはすでに目に見えている。完全な影響はまだ届いていない。

あなたのスタックのどれだけがすでにEOLなのか？

あなたは知らない。スキャナーも知らない。CVEフィードも知らない。

Sonatypeのデータによると、一般的なエンタープライズ・スタックに含まれるコンポーネントの5～15％がEOLである。npmだけで、全パッケージバージョンの25%にあたります。Spring Boot 3.2は、Spring Security 6.2を出荷しました。

あなたの数字は？

HeroDevs EOL Datasetが5分以内に教えてくれる。SBOMをアップロードするかCLIを実行してください。npm、PyPI、Maven、NuGet、その他すべての主要なレジストリにまたがる1,200万以上のパッケージバージョンと照合します。あなたのスタックにあるすべてのEOLパッケージの一覧をレポートします。セールスの電話なし。クレジットカードも不要だ。

AIによる脆弱性調査の規模が拡大するにつれ、調査されていないEOLパッケージの未公開脆弱性の数は増える一方です。

[私の無料EOLスキャンを実行する→].

HeroDevsがスポンサーとなり、執筆しました。