サポート切れフレームワークという時限爆弾｜更新遅れが情報漏えいを招く構造

2026年に起きた大型の情報漏えいを並べると、原因の書きぶりは各社バラバラである。ただ、翻訳すると同じ一文になる事案が多い。「更新が止まっていた部品を、外から突かれた」。派手なゼロデイ（未修正の欠陥を狙う攻撃）より、はるかに地味で、はるかに件数が多い。ここでは、開発の土台そのものが古びていく問題を扱う。

サポート終了とは「弱点が公開されたまま放置される」こと

ソフトウェアのサポート終了（EOL）は、単に「問い合わせ窓口が閉じる」ことではない。本質は、新しく見つかった欠陥に対する修正プログラムが二度と出てこなくなることである。

やっかいなのは、終了後もソースコードの公開や部品の配布は続く場合が多い点だ。動かそうと思えば動く。しかも当面は問題なく動いてしまう。だから「まだ使えているのだから、まだ大丈夫」という判断が通ってしまう。

タイムズカーで指摘された「10年前の土台」

9月の大型事案の公表直後、技術者の間で話題になったのが、サイトの画面ソースから読み取れる「Seasar」という文字列だった。国産のJava向けフレームワーク（アプリの共通土台）で、2016年9月26日にほぼ全製品のメンテナンスとサポートが終了している。あわせて、読み込まれている部品に2008年公開の古い版が使われている点も指摘された。

2026年の事案は「更新遅れ」の可能性が多い？

今年の主要な事案を、原因の言い換えで並べ直すと見えてくるものがある。

どれも「新種の攻撃にやられた」話ではない。既に世に出ている弱点を、埋める前に使われただけである。攻撃側から見れば、古い土台を使っているサイトは、鍵の型番が外から読めるようなものだ。

なぜ更新が止まるのか

現場を責めても解決しない。更新が止まるのは、だいたい次の5つのうちどれかが理由である。

1. 作った人がいない。受託開発で納品され、保守契約も切れている。中身を読める人間が社内にも取引先にもいない。
2. 移行先が用意されていない。サポートが終わったフレームワークには、そもそも「次の版」が存在しない。作り直す以外に道がなく、見積もりが跳ね上がる。
3. 止められない。会員が使い続けているサービスを、機能追加もなしに数か月止める意思決定は通りにくい。
4. 予算がつかない。作り直しは売上を増やさない。「今まで動いていたのに、なぜ金がいるのか」と必ず聞かれる。
5. 誰の担当か決まっていない。これが最も多い。土台の更新は情報システム部門の仕事か、事業部門の仕事か、委託先の仕事か。曖昧なまま年が過ぎる。

つまり更新遅れは技術の問題ではなく、予算と責任分界の問題である。技術者がどれだけ危ないと言っても、決裁の構造が変わらなければ何も動かない。

今日から着手できる棚卸しの手順

1. 外から見える情報を自分で確認する。自社サイトの画面ソースに、使っている土台や部品の名前と版が出ていないか。攻撃側が最初に見る場所を、こちらが先に見る。
2. 部品表を作る。システムごとに、使用している土台・部品・その版・サポート期限を一覧化する。SBOM（部品表）という言い方をするが、最初は表計算で十分である。
3. サポート期限を色分けする。すでに終了、1年以内に終了、それ以降。これで予算要求の材料が揃う。
4. 個人情報を扱う画面から優先する。全部は直せない。本人確認書類や決済に触れる画面を先に切り出して置き換える判断もある。
5. 委託先に同じ表を出させる。自社の一覧だけ作っても、預けた先が古ければ結果は同じ。契約更新の機会に提出を求める。
6. 更新の担当と頻度を文書にする。「気づいた人がやる」は運用ではない。四半期ごとの点検日を決めて、実施記録を残す。

経営層が受け止めるべき一点

10年前に作ったシステムが今も動いているのは、当時の担当者の仕事が良かったからである。それ自体は誇っていい。問題は、良く作られたものほど壊れずに残り、誰も触らなくなることだ。動き続けているという事実が、点検しない理由にすり替わっていく。

情報漏えいの記者会見で「調査中」と言い続けるコスト、監督官庁への報告、数百万人への個別通知、失った信用。これらを合計すれば、土台の更新費用は毎回きれいに安く見える。事故が起きた後にしか、その計算が成り立たないのが厄介なだけである。

使っているシステムの土台が、いつサポートを終えるのか。それに即答できないなら、まずそこを調べる。

やられる前にできるところからはじめたい。

関連情報