新たな脆弱性の状況

要約

この電子書籍では、ソフトウェアの脆弱性に関する新たな実情や、オープンソースソフトウェアを導入している組織が知っておくべき事項について考察し、3つの結論を導き出しています。

‍

まず、人工知能によって、脆弱性の発見をめぐる経済的状況は根本的に変化しました。最先端のAIモデルは、コードベースを読み取り、脆弱性の発生箇所を推測できるようになりました。脆弱性の発見はマシンの処理速度並みに加速しており、公開される修正プログラムのすべてが、エクスプロイト開発の出発点となっています。

‍

第二に、この加速化が最も深刻な被害をもたらすのは、サポート終了（EOL）となったオープンソースソフトウェアです。フレームワーク、ランタイム、またはライブラリがセキュリティ修正プログラムの提供を受けなくなると、その日から明らかになったすべての脆弱性は永久に修正されないままとなり、この電子書籍では、この種のリスクを「フォーエバー・デイ脆弱性」と呼んでいます。 この問題をさらに深刻にしているのは、ほとんどの脆弱性スキャナーが既知のCVEを追跡するのみでライフサイクルのステータスを追跡しないため、このリスクを検知できないこと、そしてほとんどのオープンソースパッケージが正式にサポート終了を発表しないことです。

‍

第三に、このリスクへの曝露は管理可能ですが、それは意図的な取り組みによる場合に限られます。組織は、ソフトウェアコンポーネントの棚卸しを行い、脆弱性のステータスとともにライフサイクルのステータスを表示した上で、4つの選択肢からなる意思決定フレームワークを適用すべきです。具体的には、長期的な目標として移行、その間のつなぎとして商用延長サポートまたは代償的統制措置、そして有効期限が定められた限定的な例外の場合にのみリスク受容という選択肢です。

‍

基本的な概念から脆弱性のライフサイクル、推奨事項に至るまで、この電子書籍ではオープンソースソフトウェアにおける脆弱性の最新状況について解説しています。

‍

はじめに

過去20年の大半において、脆弱性管理は安定した流れで進められてきました。研究者やベンダーが欠陥や脆弱性を発見し、CVE番号が割り当てられ、セキュリティスキャナーがそれを検知し、パッチがリリースされ、各組織は蓄積されたパッチの適用作業を進めていました。このプロセスは決して迅速なものではありませんでしたが、現在では、これまでにないほど多くの脆弱性が公表されています。

‍

その量の構成は、その規模と同じくらい重要です。CVE番号付与機関（CNA）のエコシステムは変化しました。サードパーティのエコシステムやオープンソースに特化したCNAが登場したことで、脆弱性の開示はもはや、成熟したセキュリティプログラムを持つ一握りの大手ベンダーによって独占されるものではなくなりました。現在では、AIを活用した検出に大きく支えられた、分散型で大量の情報を扱うパイプラインとなっています。

‍

CSAによると、脆弱性の開示から悪用が確認されるまでの期間の中央値は、わずか5日間に短縮された。『The State of Application Security 2026 』によると、ウェブサイトの脆弱性を標的とした攻撃は2025年に62億9000万件に達し、前年比で56％増加した。 一方、PCI DSS要件6.3.3に定められた30日間の是正期間など、多くの組織が遵守を求められるコンプライアンスのタイムラインは、攻撃者が開示された脆弱性を悪用するまでに数週間から数ヶ月を要していた時代に策定されたものである。現在、攻撃者は、義務付けられた最も迅速な是正期限よりも速いペースで行動するのが常となっている。 開発が中止されたり、サポートが終了したり、サポート終了（EOL）を迎えたオープンソースソフトウェアについては、パッチが存在しないため、パッチ適用期間も存在しません。実用上の観点から、本書では、このようなメンテナンスされていないソフトウェアをすべて「EOLソフトウェア」と呼びます。つまり、セキュリティ修正、新しいリリース、およびいかなる種類のパッチも提供されないソフトウェアを指します。

‍

この電子書籍は、この新たな現実の中で活動することについて解説しています。つまり、オープンソースソフトウェアを利用するあらゆる組織のために戦略を策定できるよう、脆弱性を十分に理解することです。

‍

脆弱性、弱点、およびエクスプロイト

効果的なリスク管理には、エンジニアリング、セキュリティ、ガバナンスの各チーム間で共通の分類体系が必要です。異なる用語は、データベースやシステムごとに異なる対象を指す場合があり、それらを混同すると、誤解やリソースの誤配分、誤った安心感につながり、最終的にはセキュリティリスクを招く恐れがあります。

‍

バグ、弱点、脆弱性、およびエクスプロイト

バグとは、ソフトウェアの動作を不正にするあらゆる欠陥のことです。ほとんどのバグはセキュリティ上の影響を及ぼしません。弱点とは、入力の長さの検証が行われていないなど、セキュリティ上の問題につながる可能性のある欠陥の一種です。弱点は、MITREが管理する「Common Weakness Enumeration（CWE）」に分類されています。脆弱性とは、特定のソフトウェアおよびバージョンにおける弱点の具体的かつ具体的な事例であり、攻撃者が実際に悪用し得るものです。 脆弱性にはCVE識別子が割り当てられます。エクスプロイトとは、脆弱性を悪用してシステムを侵害する、実際に動作するコードや手法のことです。脆弱性は、公開されたエクスプロイトが存在しないまま何年も存在し続けることがありますが、エクスプロイトが公開されると、そのリスクプロファイル（深刻度）は一夜にして変化します。これらの異なる概念を理解することは、修正作業への投資の優先順位を決定する上で極めて重要です。

‍

セキュリティ関連の主な略語

CVE（Common Vulnerabilities and Exposures）は、公開された脆弱性を網羅した世界的なデータベースであり、米国政府の支援のもと、MITREによって運営されています（cve.org）。 CVEレコードは一意性を確立します。つまり、1つのIDが1つの脆弱性を表すため、あらゆるツール、アドバイザリ、および議論において、同じ欠陥を指すことができます。CVE IDは、CVE番号付与機関（CNA）によって割り当てられます。CNAとは、ベンダー、オープンソースプロジェクト、セキュリティ企業、およびコーディネーターからなる連合体であり、それぞれの範囲内でIDを割り当てる権限を有しています。HeroDevsはCNAの一つです。

‍

NVD（National Vulnerability Database）は、CVE（nvd.nist.gov）の上に構築されたNISTによる情報充実化レイヤーです。NVDは、CVSSスコア、CWEマッピング、および影響を受ける製品（CPE）のデータを追加しています。NVDでは近年、情報充実化の処理が大幅に滞っており、これが多くのプログラムがもはやNVDを唯一の信頼できる情報源として扱わなくなった理由の一つとなっています。

‍

EUVD（欧州連合脆弱性データベース）は、欧州連合サイバーセキュリティ庁（ENISA）が管理する一元化されたプラットフォームであり、EUに関連するソフトウェアおよびハードウェアの脆弱性を追跡、分類、対応するために設けられています。 NIS2指令およびサイバーレジリエンス法を支援するために設立されたこのプラットフォームは、CVEやNVDなどのグローバルな情報源を統合するとともに、欧州各国のCSIRT（コンピュータセキュリティインシデント対応チーム）からの報告や、地域ごとのベンダーによる情報開示を直接取り込んでいます。 

‍

FIRSTが管理するCVSS（Common Vulnerability Scoring System）は、悪用可能性と影響度の指標に基づき、脆弱性の技術的な深刻度を0から10のスケールで評価するものです（first.org/cvss）。CVSS v3.1とv4.0では評価方法が異なります。この評価は、実際にその脆弱性が悪用されているかどうか、あるいは導入環境が攻撃対象となっているかどうかについては何も示していません。

‍

同じくFIRSTが開発したEPSS（Exploit Prediction Scoring System）は、脆弱性が今後30日以内に実環境で悪用される確率を推定するものです（first.org/epss）。EPSSは確率を示すものであり、深刻度を示すものではありません。深刻度の低い脆弱性でもEPSSスコアが高くなる場合があり、その逆も同様です。

‍

KEV（既知の悪用済み脆弱性カタログ）は、CISAが作成した、実環境で悪用が確認されている脆弱性の公式リストであり、各脆弱性には米国連邦機関向けの必須是正期限が設定されています（cisa.gov KEVカタログ）。KEVはあらゆる優先順位付けスキームにおける最低基準となります。つまり、ある脆弱性がKEVに掲載されており、かつ自組織の環境に存在する場合、その脆弱性の対応は最優先事項として扱う必要があります。

‍

SBOM（Software Bill of Materials）とは、ソフトウェアに含まれるコンポーネントを一覧化した、機械可読形式のリストであり、通常はSPDXまたはCycloneDX形式で提供されます。CISAは、SBOMに関するガイダンスやコミュニティリソースを一元的に収集・管理しています（cisa.gov/sbom）。

‍

VEX（Vulnerability Exploitability eXchange）は、サプライヤーが、製品のコンポーネントにおいて特定のCVEの影響を実際に受けているかどうかを明示するための補足フォーマットです。SBOMでは膨大な数の理論上の一致が生成されるため、どの項目が重要であるかを誰かが伝達する必要があることから、VEXが導入されました。

‍

アドバイザリー業界の動向

CVEレコードやNVDのエントリは、全体像の一部に過ぎません。ベンダーのアドバイザリには、多くの場合、影響を受けるバージョンに関する最も早期かつ正確な情報が記載されています。オープンソースのエコシステムでは、GitHub Advisory DatabaseやOSV.devの集約レイヤーなど、独自のアドバイザリデータベースが維持されており、これらのデータベースは、バージョン範囲や深刻度に関してNVDと異なる場合が頻繁にあります。

‍

ゼロデイ脆弱性とフォーエバーデイ脆弱性

ゼロデイとは、ベンダーやメンテナンス担当者がその存在を把握する前、あるいは修正プログラムを公開する前に、すでに悪用手法が存在する脆弱性を指します。一部の脆弱性は影響が極めて大きかったため、「Spring4Shell」、「Dirty Pipe」、「Log4Shell」、「Shellshock」、「Heartbleed」といった独自の名称が付けられましたが、その多くは公開から数日以内に修正プログラムが提供されました。

‍

「フォーエバー・デイ」とは、サポート終了（EOL）を迎えたソフトウェアに存在する脆弱性を指します。放棄されたソフトウェアやサポート対象外となったソフトウェア、サポート終了（EOL）となったソフトウェアには、セキュリティ修正や新たなリリース、パッチが提供されないため、「フォーエバー・デイ」は悪用されるリスクが高くなります。運用者がパッチを待つ以外の対策を講じない限り、この脆弱性はすべての導入環境において、無期限に悪用され続けることになります。 インベントリ内のどのコンポーネントが実際にそのラインを越えてしまったかを特定すること自体が容易ではありません。なぜなら、ほとんどのオープンソースパッケージは、正式にEOLを発表することはないからです。

‍

根本原因：脆弱性がコードに混入する仕組み

脆弱性が悪意によってコードに混入することはめったにありません。ソフトウェアの複雑さ、レガシーな依存関係、そして現代の迅速なリリースサイクルが、必然的にシステム的なリスクをもたらすのです。脆弱性の圧倒的多数は、長年にわたり理解され、文書化され、教育されてきた、ごく少数の根強い分類に当てはまります。

‍

メモリ破損。バッファオーバーフロー、use-after-free、ダブルフリー、および境界外読み取り・書き込みは、CおよびC++のコードベースに集中している。これらは依然としてオペレーティングシステム、ブラウザ、ネイティブライブラリにおいて主要な問題であり、CISAやNSAなどが主導する、Rustのような言語に向けた業界のメモリ安全性強化の動きの主な対象となっている。

‍

インジェクション。SQLインジェクション、コマンドインジェクション、LDAPインジェクション、XMLインジェクションには、すべて共通の根本原因があります。それは、データとコードの適切な分離が行われていないために、攻撃者が制御するデータがインタプリタに侵入してしまうことです。インジェクションは、20年以上前にリストが作成されて以来、OWASP Top 10のすべての版にランクインしています。

‍

クロスサイトスクリプティング（XSS）。XSSは、 2025年だけで8,000件以上のCVEを占めた。発見から30年が経過した今もXSSが根強く残っているのは、Webアプリケーションがユーザーデータをページに書き込む何千もの箇所のいずれにおいても、出力のエンコード処理を誤りやすいこと、そして参入障壁の低いエコシステムにおいて、過去の過ちを繰り返す新しいコードが絶えず生み出され続けているためである。

‍

デシリアライゼーション。攻撃者が提供したデータを不適切にデシリアライズすると、これまでに記録された中でも最も深刻なリモートコード実行の脆弱性につながる。特に、豊富なオブジェクトグラフがガジェットチェーンに変換され得るJavaや.NET のエコシステムにおいて、その傾向が顕著である。

‍

認証およびアクセス制御の不具合。アクセス制御の欠陥は、現在のOWASP Top 10において最も多いカテゴリとなっています。信頼境界の欠如、不十分な認可設計、安全でないデフォルト設定、および安全でないAPIの使用は、設計上の欠陥であり実装上の欠陥ではないため、メモリセーフな言語であっても決して防ぐことのできない脆弱性をもたらします。

‍

暗号技術の誤用。アルゴリズムそのものが欠陥であることはめったにない。ほとんどの場合、正しいアルゴリズムが誤って使用されているのだ。具体的には、キーのハードコーディング、証明書検証の無効化、独自に構築した仕組み、脆弱な乱数生成などが挙げられる。

‍

言語およびエコシステムのリスクプロファイル

主要なエコシステムはどれも、それぞれ特徴的な形で機能不全に陥ります。CおよびC++のコードベースでは、バッファオーバーフローや範囲外アクセスといったメモリ破損を引き起こすことが知られています。

Javaの脆弱性の特徴は、安全でない逆シリアル化や複雑なフレームワークレベルの欠陥にあり、Spring のエコシステムがその規模を如実に示しています。2026年6月だけで、 Spring のCVEが67件報告され、そのうち27件は深刻度「高」でした。

‍

JavaScript や npm エコシステムにおける脆弱性の多くは、サプライチェーンの脆弱性やプロトタイプの汚染によって引き起こされ、極端に深い依存関係によってその影響が拡大しています。2026年5月の 「Mini Shai-Hulud」キャンペーンは、その代表的な最近の事例です。攻撃者は GitHub Actions のキャッシュを悪用し、わずか6分間の間に42の TanStack パッケージにわたって84の悪意のあるバージョンを公開しました。

‍

PHPコードは、インジェクションやファイルインクルージョンの脆弱性を生じやすい傾向があり、特にWordPressやDrupal のプラグインエコシステムに集中しています。Pythonでは、デシリアライゼーション（pickle）、依存関係の混同、そして近年ではAIやMLツールにおける脆弱性がますます増加しています。

‍

スタック特有の脆弱性を把握しておけば、エコシステムで不具合が発生しやすい箇所にレビューの重点を置くことができます。とはいえ、どのような種類の脆弱性であっても、どの言語やフレームワークにおいても、いつでも発見される可能性があります。

‍

さらに詳しく知りたい方へ

この章で取り上げている予防策については、電子書籍よりもはるかに詳しく解説している参考資料が2つあります。OWASPアプリケーションセキュリティ検証基準（ASVS）は、アプリケーションレベルの制御を検証するための実用的なチェックリストです。また、NISTのセキュアソフトウェア開発フレームワーク（SP 800-218）は、規制当局がますます具体的に言及するようになっている開発ライフサイクルの実践手法を定義しています。 

‍

脆弱性のエンドツーエンドのライフサイクル

すべての脆弱性は、発生や発見から開示、そして理想的には修正に至るまで、あるライフサイクルをたどります。この流れ、特にどこで停滞したり破綻したりする可能性があるかを理解することは、アプリケーションセキュリティに関する知識の根本的な要素です。

発見の道

脆弱性は主に4つの経路を通じて表面化しますが、それぞれに異なる特徴があります。

‍

社内調査。ベンダーやオープンソースプロジェクトのセキュリティチームが自社のコードを検証し、静的解析を実行し、自社の対象に対してファジングテストを実施する。ライフサイクルの最も早い段階で、最も確度の高い兆候が得られる。

‍

バグ報奨金制度と外部の研究者。HackerOneなどのプラットフォーム上のプログラムを通じて、あるいはメンテナに直接報告を行う独立系研究者たちです。その質には大きなばらつきがあります。例えば、AIによって生成された質の低い報告が、最近ではNode.jsを含む一部のオープンソースプロジェクトにおいて、この報告チャネルを限界まで逼迫させています。この件については、先日のHeroDevsのウェビナーで議論されました。

‍

大規模なファジング。GoogleのOSS-Fuzzのようなカバレッジ主導型ファジングインフラは、数百もの重要なオープンソースプロジェクトに対して継続的にテストを実施しており、運用開始以来、数万件もの不具合を発見してきました。

‍

AIを活用した分析。最も新しい分野であり、最も急速に成長している分野です。最先端の言語モデルは、コードベースを読み取り、どこで不具合が発生する可能性があるかを推測し、実行中のソフトウェアを用いてその仮説を実験的に検証し、確認済みで再現可能な知見を導き出すことができるようになりました。Anthropic社の「Mythos Preview」評価では、こうしたLLMのうちの1つを用いた詳細な検証結果が示されています。

‍

検証と報告

発見事項は、検証されるまでは脆弱性とはみなされません。つまり、実際のソフトウェアで再現され、その影響と対象バージョンが明確に示されて初めて、脆弱性として認められるのです。「私のツールがこれを検出した」という段階と、「再現可能で、影響が実証されたセキュリティ上の問題です」という段階との間には大きな隔たりがあり、質の低い報告の多くはここで却下され、報告者の信頼性はここで築かれるのです。 

‍

優れた報告書には、影響を受けるコンポーネントとバージョンの範囲、再現手順または概念実証、影響評価、および根拠を伴った深刻度の提案が含まれます。Anthropic社が公表している、AIによって発見された脆弱性に関する運用原則は、現代的な有用なテンプレートとなっています。そこでは、すべての報告書が人間によるレビューと確認を経ていること、AIによって発見された事象にはその旨が明記されていること、そして可能な限りパッチ候補が記載されていることが定められています（Anthropic, 「Coordinated Vulnerability Disclosure」）。

‍

統一開示、報道規制、およびスケジュール

「調整された脆弱性開示（CVD）」とは、報告者が、詳細が公表される前に、ベンダーやメンテナンス担当者が修正プログラムを開発・提供するための時間を確保できるよう、協議を経て進められるプロセスのことです。このプロセスの正式な指針は『CERT/CC調整された脆弱性開示ガイド』であり、その基礎となる規格は ISO/IEC 29147（開示）および ISO/IEC 30111（対応プロセス）です。

‍

業界の事実上の慣例として、情報開示の期限は90日間とされており、報道機関は90日経過後、あるいはパッチがリリースされた後のいずれか早い時点で情報を公開することになっています。ただし、期限の延長や前倒しについては、ケースバイケースで協議されます。エンバーゴ期間が設けられているのは、特に共有コンポーネントの脆弱性など、数十もの下流製品で同時にパッチを適用する必要がある場合において、複数のベンダーによる修正を調整するためです。

‍

情報開示の規範は、修正プログラムを作成できる能力を持つ担当者が相手側にいることを前提としています。健全で活発なプロジェクトの場合、ライフサイクルは「報告、公開保留、パッチ、アドバイザリ、適用」という流れで完結します。一方、サポート終了となったオープンソースプロジェクトの場合、このライフサイクルは途中で途絶えてしまいます。 報告先が存在しないか、あるいは報告を受けたメンテナーが、そのリリースラインはサポート対象外であると正確に伝えることになる。情報開示は完了するが、修正作業は決して始まらない。これが、サポート対象外やサポート終了となったソフトウェアに、パッチが適用されず、公に記録された脆弱性が恒久的に蓄積されるという、構造的な理由である。情報開示は続いているが、修正は止まってしまっているのだ。 

‍

長期的なサポート状況やサポート終了（EOL）日を明確に示すことは、ソフトウェア開発者に可視性を提供するための推奨されるベストプラクティスです。HeroDevsが「オープンソース・サステナビリティ・ファンド」を通じてオープンソースプロジェクト向けに公開しているフレームワークは、メンテナーの立場からこの課題に取り組んでいます。具体的には、公式チャネルを通じてサポート終了の情報を周知し、サポート対象のバージョンとサポート対象外のバージョンを文書化し、サポート終了日が到来する前にユーザーに対して移行やサポートソリューションを案内することです。

‍

パッチのリリースと公表

ライフサイクルが適切に機能している場合、最終段階では、セキュリティアドバイザリを伴うパッチがリリースされます。そこには、修正内容、影響を受けるバージョン、深刻度、および報告者への謝辞が記載されます。残念ながら、この開示情報をもとに、攻撃者はパッチが適用されていない環境を標的にし、悪用することが可能になります。 CSAによると、開示から悪用までの期間は中央値で5日間であり、この期間中は、まだ更新されていないすべての導入環境に対して攻撃の機会が生まれます。また、EOL（サポート終了）となったオープンソースソフトウェアの場合、商用延長サポートオプションを選択しない限り、パッチが提供されることはありません。

‍

サポート終了（EOL）となったオープンソースソフトウェアの脆弱性

実際に実施され、規制の対象となっている脆弱性管理は、ある暗黙の前提に基づいています。それは、どのような脆弱性であっても、修正プログラムが存在するか、あるいは間もなく存在することになり、運用担当者の役割はそれを迅速に適用することである、という前提です。EOL（サポート終了）ソフトウェアは、この前提を完全に覆してしまいます。

‍

「放棄された」「サポート対象外」「EOL（サポート終了）」のオープンソースソフトウェアとは、元の開発者やコミュニティによって、もはや積極的にメンテナンスやサポートが行われていないプロジェクトを指します。これらのプロジェクトには、セキュリティパッチ、バグ修正、互換性アップデートなどが提供されなくなったため、組織は既知の脆弱性にさらされ、セキュリティや運用上の問題が発生するリスクが高まります。当該ソフトウェアに対して公開されたCVEは、通常のルートでは永久に修正されないままとなります。 

‍

自社の在庫からEOL部品を見つける

このリスククラスを管理するには、それがどこにあるかを把握しなければなりません。しかし、ほとんどの脆弱性スキャナは、ライフサイクルのステータスではなくCVEデータに基づいて動作するため、この疑問に答えることはできません。既知のCVEがゼロで、残りのメンテナーもいないコンポーネントは、セキュリティスキャナからは問題がないように見えますが、実際には時限爆弾のようなものです。

‍

このギャップを埋めるために、ライフサイクルを意識したツールが存在します。HeroDevsのEOLデータセットは、あらゆる主要なエコシステム（npm、Mavenなど）にわたる1,900万以上のパッケージバージョンを追跡するデータセットと照合し、コンポーネントごとのEOL判定結果を返します。また、プラットフォーム機能を完全に活用するために、HeroDevs Evergreenは、アプリケーション内のすべてのEOL依存関係を、エンジニアが構築した安全な代替品で自動的にカバーします。代替品はプルリクエストとして提供され、レビューとマージが行われます。サポートが終了した依存関係が後から検出されるにつれて、カバー範囲はさらに拡大し続けます。

‍

意思決定ツリー：移行、リスク軽減、受容、または延長サポートの購入

EOLコンポーネントが特定されると、選択肢は正確に4つあります。

‍

• 移行する。サポート対象のバージョンまたは代替技術へ移行する。これが恒久的な解決策であり、長期的な観点から見て正しい対応策ではあるが、フレームワークレベルの依存関係の実際の移行にはエンジニアのスプリント単位の時間が費やされるものであり、重大なCVEが発生した後に緊急のスケジュールで移行を強行することは、最もコストのかかる方法である。また、強制的な移行は組織やビジネスの運営にも影響を及ぼす。

‍

• リスクを軽減する。相殺的な対策（WAFルール、ネットワークのセグメンテーション、機能の無効化、さらには環境の隔離など）を適用する。これらは「つなぎ」としては有効だが、「最終的な解決策」としてはリスクが高い。なぜなら、各対策は既知のCVEの既知の悪用経路に対処するものではあるが、根本的な欠陥や未発見の欠陥は依然として残っているからである。

‍

• 受け入れる。リスクを文書化し、意識的にそのリスクを負う。真に孤立した、価値の低いシステムであれば、時としてこの対応が正当化されることもある。しかし、インターネットに接続されているシステムや規制対象の業界においては、この対応が正当化されることはめったにない。いくつかの規制制度では、事実上この選択肢が排除されている。

‍

• サードパーティによる拡張サポート。専任のセキュリティエンジニアリングチームにより、EOL（サポート終了）となったオープンソースソフトウェアの商用メンテナンスを行います。HeroDevsでは、オープンソースの専門家やコアコントリビューターを擁しており、アップストリームのアドバイザリを継続的に監視し、顧客が利用しているEOLバージョンに対してCVEを評価しています。彼らは、アプリケーションコードの変更を必要とせずに、バックポートされた修正プログラムを開発・テストし、ドロップイン置換として提供します。 この専門知識は、注目を集めるCVEがEOLソフトウェアには該当しない場合にも威力を発揮します。2026年にDrupal のコアで極めて重大なSQLインジェクションが公表された際、アップストリームのアドバイザリではDrupal 7の評価が全く行われていませんでした。そこで、HeroDevsの専門家がコアおよびコントリビュートされたモジュールを監査した結果、Drupal 7の導入環境が影響を受けていないことが確認されました（HeroDevsブログ「Drupal 7はCVE-2026-9082の影響を受けるか？」）。

‍

これら4つの選択肢は互いに排他的ではありません。一般的な成熟したパターンとしては、移行までのつなぎとしてサポートの延長や影響緩和を行い、移行先として移行を進め、有効期限が明示的に定められた例外的なケースに限り受け入れを行うというものです。

‍

コンプライアンス上のリスク

コンプライアンスに関する詳細な分析を行う必要があります。HeroDevsのホワイトペーパー、 『セキュリティコンプライアンス開発者ガイド』では、世界各国の標準、フレームワーク、規制を検証し、EOLソフトウェアは本質的に以下の3つの主要な点において、それらの中核的な要件を満たしていないと結論づけています：

• 修正のタイムライン：標準的な対応期間（重大な脆弱性に対する30日以内の修正義務など）は、パッチが存在することを前提としています。
• 在庫および資産の可視化：ソフトウェア部品表（SBOM）を作成することで、使用中のサポート対象外コンポーネントが直ちに規制当局の精査の対象となります。
• 文書化されたガバナンス：是正措置の道筋が定義されていない脆弱性については、必須のリスク管理プロセスを満たすことができません。

したがって、監査人が対象範囲内で、パッチが適用されていない重大なCVEを抱えるEOLコンポーネントを発見した場合、非準拠事項として記録される可能性が高い。

‍

AIを活用した脆弱性の発見と悪用

最も有力な公開証拠は、Anthropic社のセキュリティ研究チームによるものです。同チームは、約1か月にわたる社内テストを経て、2026年4月に「Claude Mythos Preview」モデルに関する技術評価報告書を公表しました。 このモデルは、コードを読み取って仮説を立て、ソフトウェアを実行してその仮説を検証または否定し、必要に応じてデバッガーを使用し、検証済みの結果を算出する。このアプローチを用いて、モデルは広く使用されているオープンソースソフトウェア全体で、主にメモリ安全性の欠陥である本物のゼロデイ脆弱性を発見し、複数のブラウザの脆弱性を連鎖させるなど、実際に機能するエクスプロイトを構築する能力を実証した（Anthropic, 『Claude Mythos Previewのサイバーセキュリティ能力の評価』）。

‍

その鍵となるのは規模です。Claude Mythosや、OpenAI、Googleなどが開発した同種のLLMは、コードベースを迅速にスキャンして脆弱性を特定することができます。一方、AIを活用したツールは、研究者が修正作業を加速させるのに役立ちますが、同じペースでは進みません。しかも、これはプロセスにおけるコーディングの部分に過ぎません。修正内容は、依然として優先順位の付け、パッケージ化、文書化、テストを経て、最終的にリリースされる必要があります。

‍

脆弱性の悪用

WizによるMythosの分析結果によると、このモデルはCVE識別子とコミットハッシュを入力として受け取り、低コストで数時間以内に動作するエクスプロイトを自律的に生成できる。これに対し、従来は熟練した研究者が同じ作業を行うのに数日から数週間を要していた。このことによる実用上の影響は、より多くのCVEがより迅速に公開され、悪用されるようになるということだ。AIの支援があれば、公開された脆弱性の修正策のすべてが、エクスプロイト開発の出発点となり得る。

‍

これを、開発が中止されたソフトウェア、サポート対象外となったソフトウェア、あるいはサポート終了（EOL）となったソフトウェアに当てはめてみると、その不均衡が際立ってきます。サポート対象のソフトウェアの場合、脆弱性の悪用が早まれば、それに対応するパッチも早く提供されます。防御側の猶予期間は短くなりますが、それでもまだ存在します。一方、開発が中止されたソフトウェア、サポート対象外となったソフトウェア、およびサポート終了（EOL）となったソフトウェアの場合、適用すべきパッチが存在しないため、防御側の猶予期間はまったくありません。 

‍

AIは、防御側の優位性を根本から覆してしまった。最先端のモデルは今や、機械並みの速度と限界費用で、自律的に脆弱性の調査やエクスプロイトの生成を行っている。稼働中のソフトウェアにとっては、これによりパッチ適用期間が短縮される。一方、サポート終了（EOL）やメンテナンスされていないソフトウェアにとっては、防御手段が完全に失われ、レガシーな技術的負債が、実際に侵害される可能性へと変わる。

‍

もし業界全体の発見率が機械規模の分析によって飛躍的に向上しようとしているとすれば、構造上修正が不可能なソフトウェア群こそが、その飛躍的な向上による被害を最も大きく受けることになる。これこそが、EOL在庫を単なる技術的負債として後回しにするのではなく、取締役会レベルで緊急に扱うべき課題として位置づけるべきであるという、最も強力な根拠である。

‍

最終的な感想

従来の脆弱性対策の手引書は、3つの前提に基づいていました。すなわち、脆弱性の開示は管理可能なペースで発生すること、パッチが存在するか、あるいは間もなく提供されること、そして防御側がパッチを適用する時間的余裕があることです。しかし、これら3つの前提はすべて、もはや当てはまりません。新たな脆弱性の状況下では、FIRSTの中間予測によると、開示件数は年間約66,000件を超える勢いで増加しており、AIを活用した発見によりコードベースが機械的なスピードで脆弱性として特定され、悪用可能な期間の中央値は、あらゆるコンプライアンスのタイムリミットを下回るほど短縮されています。

‍

サポート対象のソフトウェアにとって、これは深刻な運用上の問題です。一方、サポート終了（EOL）となったソフトウェアにとっては、事態はさらに深刻です。つまり、公に記録され、恒久的に修正されないまま放置され、AIによって次々と発見される脆弱性の種類が増え続けているのです。この電子書籍で説明されているあらゆる加速化――CNAの増加、発見件数の増加、エクスプロイトの高速化――は、構造的に修正を受けられないソフトウェアに最も深刻な打撃を与えます。

‍

対応すべきはパニックではなく、資産の把握と優先順位の決定です。自社のスタックの中で、どのコンポーネントがEOL（生産終了）の期限を過ぎているかを把握してください（多くの場合、その旨は公表されません）。同じ画面上で、脆弱性のステータスの横にライフサイクルのステータスを表示させます。そして、慎重に意思決定ツリーを適用します。移行を最終目標とし、延長サポートや緩和策を過渡的な措置とし、期限が定められた限定的な例外の場合にのみ、現状維持を受け入れるようにします。

‍

AIによって発見される脆弱性の頻度は、サポート終了（EOL）ソフトウェアのリスクを倍増させています。「フォーエバー・デイ」と呼ばれる脆弱性が「永遠」に存在し続けるのは、誰も修正プログラムをリリースしない場合に限られます。HeroDevsの「Never-Ending Support」は、40以上のサポート終了済みオープンソースフレームワーク、ランタイム、ライブラリに対してセキュリティパッチの提供を復活させ、SLAに基づきドロップイン置換として提供されます。御社の環境にあるコンポーネントでサポート終了を迎えたものがあれば、次の脆弱性公開サイクルでそれが発見される前に、ぜひ弊社チームにご相談ください。

‍