＼　FutureVulsで多くの企業が、プロアクティブなEOLライブラリの管理を実現　／

ビジネス基盤であるOSSの現状とリスク

PROBLEM
 

OSSが利用されている半数が
「ゾンビ化状態」である

FutureVulsで国内企業の実稼働にあるOSSの約16,000種類を分析した結果、48.5%が公式EOLを迎えていたり、開発停滞によるリスクが放置されている「ゾンビ化状態」であることが明らかになりました。
※独自レポートの内容がVulnCon 2026登壇に採択

OSS_EOLの実態
 

組織利用のソースコードは
77%がOSS由来

Synopsys社 の「Open Source Security and Risk Analysis (OSSRA) 2024」レポート によれば、商用コードベースの 77%がオープンソース由来であることが明らかになっています。企業が自社で書いているコードは、システム全体のごく一部であり、国内企業のビジネスを支えているのはOSSと言っても過言ではありません。

OSS_利用実態

🔍FutureVuls独自調査で判明🔍

「公式情報」だけを信じてはいけない。公式EOLは氷山の一角

RESULT

提供元から公式にEOLが宣言された「公式EOL」は9.4%のみであり、OSSが抱えるリスクの全体像から見れば、水面に現れた氷山の一角に過ぎません。今まで可視化されてこなかった「実質的 EOL」と「開発停滞」という2つの巨大なリスクを明らかにしています。

公式EOLは氷山の一角-1

「実質的EOL」という静かな死

客観的なデータに基づき、「2年以上アクティブな開発が行われておらず、かつ、修正されていない脆弱性が3件以上存在する」という2つの条件を同時に満たすものを「実質的EOL」と定義しました。

 

実質的EOLは時間経過とともに、「見えないリスク」が蓄積し、公式EOLを待たずに危機的状況に陥る可能性があります。

OSS_実質的EOL

開発が止まった瞬間から、OSSはリスク資産に変わる

最も大きな割合を占めるのが、全体の 34.6% に達する「開発停滞」状態のOSSです。

 

現時点では「実質的EOL」の定義には当てはまらないものの、開発活動が著しく鈍化しており、将来的にEOL状態に陥る可能性が高い、巨大なリスクの予備軍と言えます。

OSS_開発停滞

＼50ページ以上の大ボリューム／

技術的負債から「法的負債」へ―
放置は企業の生存を左右する

ISSUE

EOLライブラリの脆弱性から攻撃を受け、インシデントが発生し、ブランドイメージの損失、事業の継続が困難になる危険があります。また、法規制の対応が遅れ、製品販売の遅延や販売がそのものが不可能となり、高額な罰金が課せられるリスクを考慮しなければなりません。

貴社のOSS・セキュリティ方針のチェックリスト

  • 自社のシステムに「実質的に開発が止まっているOSS」がどれだけあるか把握できていない
  • 脆弱性管理を手動（Excel等）で行っており、現場の工数が限界に達している
  • 脆弱性を発見しても対応業務が遅れていて、放置されがち
  • 欧州サイバーレジリエンス法（CRA）など、今後の法規制強化に向けた対応方針が決まっていない
  • 経営層に対し、セキュリティ予算確保のための「客観的なデータ」を求めている

⚠️手動によるEOL管理の限界⚠️

EOL管理は複雑・手間で多くの組織で放置されている

EOL管理を以下、STEP1~5を手動で行う場合、信じられないほど複雑かつ手間が発生します。ヒューマンエラーも起こりやすく、そして何よりも現代の企業環境では全くスケールしません。

この圧倒的な複雑さとコストこそが、多くの組織でEOLリスクが放置される根本的な原因です。日々の緊急対応や開発要求に追われる中で、多大な労力がかかるEOL調査は、どうしても後回しにされてしまいます。

STEP 1

ライブラリのリスク化

ライブラリのリスト化

STEP 2

推移的依存関係の調査

推移的依存関係の調査

STEP 3

EOL情報を探し出す

EOL情報を探し出す

STEP 4

OSS提供元の稼働確認

OSS提供元の稼働確認

STEP 5

継続的な集計と監視

継続的な集計と監視

脆弱性管理のその先へ―
「OSS健全性」という新常識を提案

公式なEOL宣言だけではなく
「真に健全か」の本質を追求

PARADIGM SHIFT

現状、CVE番号が割り振られた「既知の脆弱性」を潰す対応が、サイバーセキュリティにおける常識となっています。しかし、それだけでは不十分であり今後は、公式な「EOL 宣言」、「実質的EOL」、「開発停滞」の追跡が求められます。

Future求められる「OSSヘルスチェック」

 OWASP（Open Worldwide Application Security Project）の ト ッ プ 10リスク リストにも、CVE とは独立して「Unmaintained Software（メンテナンス されていないソフトウェア）」が重大なリスクとして定義されています。

 

これは、CVE が存在しない状態であっても、メンテナンスの欠如自体が重大なリスクであるという合意形成がされていることを示しています。

 

つまり、これからの時代に求められるのは、本当に健全かを判断する「OSSの健康診断（ヘルスチェック）」です。 

OSSのヘルスチェックへ

🚩OSSのEOLに関するまとめ🚩

組織はOSS健全性を
プロアクティブに管理する必要がある

SUMMARY

公式EOLという氷山の一角から始まり、その水面下に広がる「実質的 EOL」と「開発停滞」という巨大なリスクの姿を私たちは明らかにしました。そこから今、我々の手元に厳しい現実と、そこから脱却するための明確な羅針盤があります。

まずは、皆様にもレポートをお届けし、今後の解決策を一緒に歩めると幸いです。

ビジネス基盤のOSS 約半数がリスク
稼働継続
の最優先

企業利用のソフトウェアの大部分はOSSであり、48.5%が「ゾンビ化状態」となっている状況。 

リスクは 三重構造である
リスクは
三重構造である

広く認識されている「公式 EOL」に加え、 その数倍にのぼる「実質的 EOL」と「開発停滞」というサイレントリスクが存在する。

影響は複合的である
影響は
複合的である

陳腐化した OSS は、セキュリティリスクだけでなく、金銭面やビジネスの推進に多角的な悪影響を及ぼす。

手動管理は破綻している
手動管理は
破綻している

ライブラリのリスク化からOSS提供元の稼働確認など、これらのリスクを手動で継続的に管理することは不可能である。