サポート終了（EOL）オープンソースコンポーネント：サプライチェーンで最も静かなリスク
重大 CVE が出たコンポーネントはニュースになる。メンテナンスが止まったコンポーネントはならない——依存ツリーの中に静かに残り続け、誰もバグを直さず、誰も issue を読まず、新しいリリースも出ない。業界の年次レポートは繰り返し同じ桁の結論を出している。監査対象コードベースの大多数に、4 年以上更新されていないオープンソースコンポーネントが含まれる。これはエンタープライズソフトウェア資産の中で最も静かで、最も広範なサプライチェーンリスクである。
なぜ EOL は危険なのか
脆弱性が永遠に修正されない。Log4j 1.x は 2015 年にサポート終了が宣言されていたが、2021 年の Log4Shell 対応の際、無数の企業が自社でまだ 1.x を大規模に使っていることを調査の中で発見した——そして 1.x 自身のデシリアライゼーション脆弱性（CVE-2021-4104 など）に公式パッチが出ることは決してない。Python 2 は 2020 年初頭に、AngularJS は 2022 年初頭にサポートを終えたが、いずれも今なお大量の本番システムで稼働している。放棄されたコンポーネントの新しい脆弱性は、すべて恒久的なエクスポージャーだ。
依存チェーンの連座。直接依存はまだ保守されていても、その下のライブラリが止まっている——EOL は依存ツリーを上方向に伝播するが、多くのチームは第 2 階層より下の依存状態を一度も確認しない。
単独メンテナー問題。放棄はアナウンスされるものではなく、「メンテナーが消えていく」形で起きる。xz バックドア事件の起点はまさにそこだった——燃え尽きた元メンテナーと、「親切な後継者」として潜入した攻撃者。週間数百万ダウンロードのパッケージが一人の余暇で維持されている状況は、オープンソース世界では例外ではなく常態である。
識別：EOL はデータの問題であり、勘の問題ではない
コンポーネントが放棄されたかどうかはデータで答える。公式 EOL アナウンス、最終リリース日、issue への応答状況、メンテナーの活動量。エンジニアリング上は SCA プラットフォームに任せ、台帳レイヤーで継続的にアノテーションする——利用中の全コンポーネントの最終更新時期、EOL 状態、コミュニティ活動スコアが常時可視化され、次のインシデントで受動的に発覚するのを待たない。導入時評価に「持続可能性」の次元が必須である理由もここにある。5 年後に放棄コンポーネントを処置するより、導入当日にコミュニティの健全性——リリース頻度、コントリビューター数と集中度、issue 応答時間——を一目確認するほうがはるかに安い。
格付け：すべての EOL を今すぐ処理する必要はない
EOL コンポーネントの在庫は通常かなりの数にのぼり、全量即時アップグレードは現実的でも必要でもない。2 軸で格付けする。エクスポージャー（外部入力を処理するか？攻撃経路上にあるか？社内ツール内の放棄コンポーネントと公開サービス内のそれはまったく別のリスク等級だ）と既知脆弱性の状態（未修正 CVE を抱える EOL コンポーネントは最優先へ。既知の欠陥がないものはウォッチリストへ——免除ではなく監視である。新しい開示はいつでも起こりうるし、パッチは永遠に来ない）。
4 つの対処戦略
アップグレード：活発な後継メジャーバージョンが存在する場合（Log4j 1.x → 2.x/Logback）。コストは主に API 移行で、最優先の経路だ。置換：プロジェクトが完全に死んでいる場合は活発な代替へ移行する（AngularJS → モダンフレームワーク）。コストが高いため、技術的負債ロードマップに載せて分割実行する。隔離と強化：短期にアップグレードも置換もできないもの（組込みやレガシー基幹システムに多い）は、ネットワーク分離、WAF による仮想パッチ、権限縮小でエクスポージャーを圧縮し、移行の時間を稼ぐ——これは鎮痛であって治療ではない。商用継続：一部の EOL ソフトウェアには有償の延長サポートを提供するベンダーが存在し、移行サイクルが特に長いコンプライアンス敏感な環境に適する。
ルーチンワークに変える
EOL ガバナンスで最悪なのはキャンペーン式の一斉対応だ。持続可能な形は 3 つの自動化されたリズムである。台帳での EOL と活動量の継続的アノテーション（日常的に可視）、新規コンポーネント導入時のコミュニティ健全性ゲートチェック（増分をこれ以上悪化させない）、四半期ごとの在庫 EOL コンポーネントの格付け再審（最優先項目はその四半期のスプリントへ）。この 3 拍子が回れば、「最も静かなリスク」は時限爆弾ではなく、普通にスケジュールできるエンジニアリング業務になる。