急増するサイバー脅威と見過ごされてきた内部リスク

――サポートが終了した OSS が企業にもたらすリスクとは

はじめに

ここ数年、日本企業を取り巻くサイバー脅威の状況は大きく変化しています。独立行政法人情報処理推進機構（IPA）が公表した「情報セキュリティ 10 大脅威 2025」では、ランサムウェアやサプライチェーン攻撃が引き続き組織向けの上位脅威として挙げられており、業種や規模を問わずさまざまな組織が影響を受けています。
こうした状況の中で、インターネットに直接さらされていない内部ネットワークのシステムは比較的安全という従来の前提は、現実とのギャップが大きくなりつつあります。本記事では、とくにサポート終了（EOL: End of Life）を迎えたオープンソースソフトウェアが企業にもたらすリスクに焦点を当て、背景となる脅威動向と規制環境の変化を整理します。

内部ネットワークは「安全地帯」ではない

従来、日本企業ではインターネット境界部分の対策（ファイアウォール、WAF、メールフィルタなど）に重点を置いてきました。
しかし、VPN やリモートアクセス経由で一度内部に侵入されると、その後は内部ネットワーク内のサーバーや端末が次々と攻撃対象となります。脆弱性を抱えた古い OS やミドルウェア、アップデートされていないソフトウェアは、攻撃者にとって権限昇格や横方向展開の「踏み台」として利用されるリスクが高くなります。
つまり、従来型の境界防御だけではサイバー攻撃への対策は不十分であり、内部ネットワークへの侵入を前提としたゼロトラストアーキテクチャや内部ネットワーク内の脆弱性管理がますます重要になっているのです。

サポート終了（EOL）を迎えた OSS が抱えるリスク

多くの企業では、プロプライエタリソフトウェアだけでなく、オープンソースソフトウェア（OSS）も利用されています。システムの基盤として、リリースから年数が経過した OS やミドルウェアが稼働していることもあります。代表的な例として、サポート終了した CentOS 7 や PHP 5 系、7 系などが挙げられます。
一般的に、OSS のサポート期間が終了（EOL）すると、コミュニティからのセキュリティパッチ提供は停止されます。その後に新たな脆弱性が見つかった場合でも、公式な修正プログラムが提供されないため、既知の脆弱性が長期間残存することになります。サポート期間が終了した OSS を業務環境で継続利用することは、攻撃者にとって「対策されない脆弱性が存在する」ことを意味し、リスクが蓄積されていく状態と言えます。

主要な OSS の EOL 情報

国内企業で広く利用されていながら、すでにコミュニティのサポートが終了しているか、近いうちにサポート終了予定である主要な OSS をまとめました。

OSS EOL バージョン一覧（2025 年 12 月時点の状況・予定）

OSS 名	EOL 到達最新バージョン	EOL 日付	情報元
PHP	8.1	2025 年 12 月 31 日 ( 予定 )	https://www.php.net/supported-versions.php
Python	3.9	2025 年 10 月 31 日	https://devguide.python.org/versions/
Spring Framework	6.1.x	2025 年 06 月 30 日	https://spring.io/projects/spring-framework#support
.NET	.NET 6 (LTS)	2024 年 11 月 12 日	https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core
Apache Tomcat	10.0.x	2022 年 10 月 31 日	https://tomcat.apache.org/whichversion.html
AngularJS	1.8.x	2022 年 1 月	https://angularjs.org/
Angular	v18	2025 年 11 月 21 日	https://angular.jp/reference/versions

2025 年の主な変更点ハイライト

● PHP: 8.1 が 2025 年末をもってセキュリティサポートを終了するため、8.2 以降への移行が必須となります。
● Python: 長らく使用されていた Python 3.9 がついに EOL を迎えました。AI/ML 分野のライブラリ依存関係に注意が必要です。
● Angular: 高速なリリースサイクルにより、v17 (2025 年 5 月 ) および v18 (2025 年 11 月 ) がサポートを終了しました。
● Spring Framework: 6.1 系の OSS サポートが終了し、6.2 系（2024 年 11 月リリース）への移行が推奨されます。

業界規制やガイドラインへの対応

こうした技術的なリスクに加え、近年は業界規制やガイドラインが組織に求める対応もより厳格になってきています。
EU では、デジタル製品のセキュリティ要件を定めるサイバーレジリエンス法（Cyber Resilience Act, CRA）が 2024 年に正式に採択され、今後順次適用が進む見込みです。CRA では、ソフトウェアやハードウェアを含む対象製品について、設計・開発段階から廃棄に至るまでライフサイクル全体でのサイバーセキュリティ確保が要求され、製品提供後一定期間にわたる脆弱性対応やアップデート提供義務が規定されています。この要件は、EU 向けビジネスを展開する日本企業においても対応が必要となります。
金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」では、ハードウェア・ソフトウェア等の脆弱性管理に関する手続きの整備、脆弱性の深刻度とシステム重要度に応じたパッチ適用期限の設定、対応実績の管理などが求められています。また、内部ネットワーク上のシステムもリスク評価の対象とすることが明記されています。

企業が直面するジレンマ

多くの企業が抱えている課題を整理すると、次の三つの視点が浮かび上がります。
1) セキュリティの視点：サポート終了した OSS が抱える脆弱性は、ランサムウェアやサプライチェーン攻撃の入口や横展開の足掛かりになり得る。
2) ビジネスの視点：システムのリプレースや全面移行には多大なコストと長いプロジェクト期間が必要となる。
3) コンプライアンス遵守の視点：業界規制・ガイドラインや、それらを受けた社内ポリシー等により、脆弱性対応が厳格化され、内部ネットワーク上のシステムであっても対応の先延ばしが難しくなっている。
この三つの要素が重なることで、「すぐに全面更改はできないが、何も対策をしないわけにもいかない」というジレンマに直面する企業が増えています。

サポート切れ OSS 対応、3 つのアプローチ

1) OSS の最新バージョンへのアップデート

最も直接的な対応が、EOL を迎えた OSS を最新バージョンにアップデートすることです。セキュリティパッチが継続的に提供され、新機能やパフォーマンス改善も期待できます。ただし、メジャーバージョンアップには既存アプリケーションの互換性確認とコード改修が必要で、システムの規模にもよりますが一般的に 1〜数ヶ月程度の準備・検証期間とそれに応じたコストがかかるのがデメリットです。

2) システム全体の刷新

2 つ目は、システム全体を新しい基盤へ移行することです。OS バージョンが上がると、ミドルウェアも自動的に最新化されるため、よりセキュリティを確保できます。しかしながら、1) よりもさらに時間とコストがかかるほか、OSS も通常最新バージョン系列のものにアップデートされますので既存アプリケーションの改修コストが必要となってしまいます。

3) OSS の延長サポートの利用

3 つ目が OSS の延長サポートを導入することです。公式サポートを終えた EOL バージョンに対して、外部サービスからセキュリティ修正を受け取り、継続的に脆弱性対応を行います。既存環境のまま、期間やコストを抑えながらセキュリティリスクを軽減でき、アップデートやシステム全体の刷新への移行を計画的に進めるまでの「バッファ期間」として機能します。

経営層への説明では、延長サポートが単なる「先送り」ではなく「安全な橋渡し」であり、その間に計画的な更改を進める戦略的な選択肢であることを明確に伝えることが重要です。

サイバートラストでは、OSS の延長サポートとして、TuxCare ELS を提供しています。