セキュリティチームがEOL（End-of-Life）オープンソースソフトウェアについて考えるとき、会話は通常同じ場所で始まり、終わります。それは「もうパッチは提供されない」ということです。 それは事実ですが、それは物語の半分に過ぎず、おそらく危険性の低い半分です。ほとんどのチームが認識していない、2つの複合的な問題があります。 ## 問題1：CVEエコシステムはサポートしないものを調査しない オープンソースプロジェクトで脆弱性が発見されると、メンテナーはどのバージョンが影響を受けるかを判断し、定義された影響範囲を持つ**CVE**を登録します。業界のすべての脆弱性スキャナー、SBOMツール、CVEフィードは、その範囲を消費します。 あなたのバージョンがその範囲外であれば、アラートは届きません。安全だからではなく、誰もチェックしていないからです。 EOLバージョンは、ほぼデフォルトでその範囲外になります。理由は単純です。これは規模の問題です。**Sonatype**の2026年ソフトウェアサプライチェーンの状態レポートによると、わずか5年間で、グローバルなCVE数は倍増し、スコアリングされていないCVEの数は37倍に増加しました。 メンテナーは、積極的にサポートしているバージョンの調査とパッチ適用で既に手一杯であり、CVEの量とパッケージリリースの総数の両方が増加し続けるにつれて、古いリリースラインをカバーするために必要な調査帯域幅は単純に存在しません。 メンテナーは、自身のリリース履歴のどこまで合理的に遡れるかについて現実的でなければなりません。 Sonatypeの調査では、「アドバイザリから除外されたEOLバージョン」が偽のセキュリティ信頼感の要因として明示的に挙げられており、2025年だけで特定された167,286件の偽陰性（完全にフラグが立てられなかった悪用可能なコンポーネント）に寄与しています。 ### 実際にはどのような状況か 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](http://endoflife.date/)で、約350の積極的にメンテナンスされているプロジェクト（メンテナーがEOL日付を明示的に公開している主要なフレームワークとランタイム）を追跡しています。 これらの350プロジェクト全体で、約7,000の特定のパッケージバージョンがEOLとして特定されています。これが、ほとんどのスキャナーとセキュリティチームが作業している範囲です。 ここに問題の実際の規模があります。 HeroDevsと提携して作成されたSonatypeの2026年ソフトウェアサプライチェーンの状態レポートでは、データは異なるストーリーを語っています。npm、PyPI、Maven、NuGet、RubyGems、Go、Packagist、crates.ioにまたがる1200万パッケージバージョンのライフサイクルステータスを分析した結果、HeroDevsは、**そのうち540万バージョンがEOLである**ことを見出しました。 しかし、業界で最も包括的な公開ソース（endoflife.date）は、そのうち約7,000しか説明していません。 エコシステムごとの内訳は顕著です。npmパッケージバージョンの約25%がEOLです。NuGetは約18%、Cargoは13%、PyPIは11%、Maven Centralは10%です。これらは、CVE調査カバレッジも修正パスもない、エンタープライズSBOMに現在登場しているバージョンです。 Sonatypeレポートでは、エンタープライズ依存関係グラフのコンポーネントの5〜15%がEOLであり、チームがサポートされているトップレベルライブラリのみを使用していると考えている場合でも、EOLへの露出があることを示しています。推移的依存関係（パッケージが依存するパッケージ）が、この隠れた露出の大部分を占めています。 ほとんどの組織は、EOLへの露出を深刻に過少報告しており、それは彼らのせいではありません。彼らのツールは、規模での放棄を検出するように構築されていませんでした。 HeroDevsは、既知のCVEがあり、修正パスがないEOLパッケージバージョンが81,000件以上あることを確認しています。これは、積極的に調査され、確認されたCVEであることを意味します。 サポートされているバージョンでのCVEの約80%が、公式に調査されていないEOLバージョンにも影響することを考えると、実際の数ははるかに大きい可能性があります。HeroDevsは、すべてのレジストリ全体で実際の数値は**400,000以上**に近い可能性があると推定しています。 ## なぜこれが悪化しているのか このダイナミクスは新しいものではありません。新しいのは、それが複合化する速度です。 OSSエコシステムは、それを監視するために構築されたセキュリティインフラストラクチャよりも速くスケールしています。npmだけでも、2025年に重大なCVSS 9.0以上のスコアに関連する838,000以上のリリースを記録しました。PyPIのダウンロード量は前年比50%以上増加しました。 レジストリに入る新しいパッケージバージョンはすべて将来のEOLバージョンであり、EOL人口は継続的に増加していますが、それをカバーする調査能力は増加していません。 しかし、より重要な強制要因は、**AI**かもしれません。 2026年4月、**Anthropic**はClaude Mythos PreviewとともにProject Glasswingを発表し、数十年間検出されなかった脆弱性を含む、すべての主要なオペレーティングシステムおよびブラウザにわたるゼロデイ脆弱性を特定および悪用する能力を文書化しました。 この取り組みは、攻撃者が悪用する前に重大な脆弱性を発見して修正することを目指した、明確に防御的なものです。 アクティブサポートのあるソフトウェアにとっては、これは本当に良いニュースです。AIスケールで発見された脆弱性は、それに対処できるエンジニアにルーティングできます。 EOLソフトウェアの場合、計算は異なります。コードベース全体で脆弱性を発見するAIは、メンテナーが監視していないバージョンで発見を表面化させます。これらの発見は、EOLユーザーに対して公式に調査されることはありません。 これらは、EOLユーザーにスキャナーアラートをトリガーしません。アップストリームパッチがそれらを対処することはありません。サポートされているソフトウェアの防御を加速するのと同じ機能が、既に置き去りにされたすべてのものの露出ギャップを広げます。 このシフトの初期の兆候は既に明らかです。完全な影響はまだ来ていません。 ## あなたのスタックのどのくらいが既にEOLか？ あなたは知りません。あなたのスキャナーは知りません。あなたのCVEフィードは知りません。 Sonatypeのデータによると、典型的なエンタープライズスタックのコンポーネントの5〜15%がEOLです。npmだけでも、全パッケージバージョンの25%がEOLです。Spring Boot 3.2はSpring Security 6.2（12月からEOL）を搭載して出荷されましたが、スキャナーアラートはありません。 **あなたの番号は？** HeroDevs EOL Datasetは、5分未満でそれを教えてくれます。SBOMをアップロードするか、CLIを実行してください。npm、PyPI、Maven、NuGet、およびその他のすべての主要レジストリにわたる1200万以上のパッケージバージョン（スキャナーがスキップした推移的依存関係を含む）に対してチェックします。スタック内のすべてのEOLパッケージをリストしたレポートが得られます。営業電話なし。クレジットカードなし。 AI支援の脆弱性研究がスケールするにつれて、調査されていないEOLパッケージにおける未開示の脆弱性の数は増加する一方です。 **[無料EOLスキャンを実行する →](http://www.herodevs.com/eol-dataset/eol-data?utm_source=sponsored-article&utm_medium=paid-sponsorship&utm_campaign=2026q2_eolds-ga-phase2_global&utm_content=bleeping-computer_20260505)**