IBMとRed Hat、広く使われるJavaライブラリの400件超の脆弱性を修正

IBMとRed Hatは、広く使われているJavaライブラリで、これまで知られていなかった400件以上のセキュリティ脆弱性を特定し、修正しました。成熟したオープンソースソフトウェアでも、長年見過ごされる弱点が潜んでいる可能性があることを示す結果です。

両社は 10月6日にこの成果を発表し、共同のセキュリティイニシアチブ「Lightwell」が脆弱性の発見と対処を担ったとしています。あわせて「Lightwell Clearinghouse」の一般提供も開始しました。このサービスは、脆弱なオープンソースの依存関係に対する修正を企業が入手できるようにするもので、本番環境で稼働を続ける古いバージョンのソフトウェアも対象です。

Javaアプリケーションに依存する組織にとって、今回の発表は重要な問いを投げかけます。自社のシステムが使うソフトウェアライブラリに、どれだけの脆弱性が潜んだままになっているのでしょうか。

広く使われるJavaライブラリで400件超の脆弱性を発見

IBMとRed Hatによると、Lightwellイニシアチブは、広く導入されているJavaライブラリで、これまで知られていなかった400件以上の脆弱性を特定して修正しました。

ただし両社は、10月6日の発表で、影響を受けるJavaライブラリの名称、個別のCVE、深刻度の評価を明らかにしていません。これらの情報がなければ、発表だけでは自組織が影響を受けるかどうかを判断できません。

また、今回の脆弱性が実際の攻撃で悪用されたことを裏付ける内容も、発表には含まれていません。

今回の成果は、企業のセキュリティチームが直面するより大きな課題を浮き彫りにしています。アプリケーションは多数のオープンソースコンポーネントに依存しており、その中には公開から長い年月を経ても本番環境で使われ続けるライブラリがあります。

こうした依存関係はセキュリティ上の弱点になり得ますが、特定と修正は容易ではありません。コンポーネントをアップグレードすると、既存のアプリケーションに支障が出るおそれがあるためです。

Javaライブラリ「FastJson」の別の脆弱性は、起こり得る影響の大きさを示しています。7月に公開されたCVE-2026-16723は、リモートコード実行につながる深刻な脆弱性です。特定のSpring Bootの実行可能fat-JARアプリケーションにデプロイされたバージョン1.2.68から1.2.83が影響を受けます。 Alibabaのセキュリティアドバイザリによると、この脆弱性はライブラリのデフォルトのセキュリティ設定でも悪用が可能で、修正版はFastJson 1.2.84です。

このFastJsonの脆弱性はLightwellの成果とは無関係です。それでも、広く使われるJavaコンポーネントの弱点が、それに依存する組織にセキュリティリスクをもたらすことを示しています。

同様の依存関係のリスクはJavaに限りません。eSecurity Planetが以前報じた protobuf.jsの6件の脆弱性に関する記事では、このJavaScriptライブラリを使うアプリケーションで、リモートコード実行やサービス拒否(DoS)が起こり得ると指摘しました。

AIを活用した脆弱性の発見も、オープンソースライブラリの弱点を明らかにしています。Anthropicは2月、研究者がClaude Opus 4.6を使い、オープンソースソフトウェアで深刻度の高い500件超の脆弱性を特定し、検証したと発表しました。詳細は eSecurity Planetの解説記事をご覧ください。

この成果はIBMとRed Hatの取り組みとは別のものです。ただ、従来のテストでは見逃されていた可能性のある脆弱性を、AIを活用したセキュリティ研究が掘り起こしていることがわかります。

IBMとRed Hat、Lightwellを拡大し古いソフトウェアの脆弱性にも対応

IBMとRed Hatは脆弱性の発見とあわせて、Lightwell Clearinghouseの一般提供開始を発表しました。企業の顧客は、オープンソースの脆弱性や依存関係について、優先的なレビューを依頼できます。対処の選択肢には、本番環境で稼働を続ける古いバージョンのソフトウェア向けの修正も含まれます。

このサービスは、より大きなLightwellイニシアチブの一部です。Lightwellは、AIを活用したエンジニアリングのワークフローと人間の専門知識を組み合わせ、脆弱性の特定、修正の開発、オープンソースソフトウェアの弱点への対処を支援します。

企業のチームは「Lightwell Network」を通じて、検証済みのパッチを入手し、修正後のソフトウェアを既存の開発・セキュリティのワークフローに組み込めます。

重要な機能の一つが、バックポートです。これはセキュリティ修正を古いバージョンのソフトウェアに適用できるよう調整する作業を指します。

組織が最新バージョンのライブラリにすぐ更新できるとは限らないため、この機能は重要です。互換性の要件、テストの負担、運用上の依存関係により、メジャーアップグレードが難しい場合があります。

IBMとRed Hatによると、該当する修正は、顧客が使っている既存のセキュリティスキャナー、開発パイプライン、ソフトウェアリポジトリと統合できる、保護されたリポジトリを通じて提供されます。

両社はさらに、Lightwellで開発した該当する修正は、責任ある開示のプロトコルに従ってアップストリームのオープンソースプロジェクトに提供すると説明しています。その際、Clearinghouse参加者に対するエンバーゴ(公開猶予)の保護も維持するとしています。

IBMとRed Hatは 2026年5月にProject Lightwellを発表しました。AIの能力と2万人以上のエンジニアを背景に、オープンソースソフトウェアのセキュリティに50億ドルを投じると表明しています。

両社は、自律型AIエージェントの進歩により、攻撃者がリスクの低い複数の脆弱性を組み合わせ、より深刻な攻撃に仕立てやすくなるおそれがあると警告しました。

この懸念は、個々のソフトウェアの欠陥にとどまりません。攻撃者が連携する複数のコンポーネントにまたがる弱点を見つければ、脆弱性の優先順位付けでは注目されにくい組み合わせを悪用できる可能性があります。

ただし両社は、Lightwellで見つかった400件超の脆弱性のいずれかをAIエージェントが悪用したとは報告していません。

組織がAI支援の開発ツールを採用するにつれ、ソフトウェアサプライチェーン全体にも新たなリスクが生じています。

eSecurity Planetが以前公開した ソフトウェア開発のセキュリティに関する分析記事は、AIコーディングアシスタントや開発用拡張機能などのツールが、新たな攻撃経路を生んでいる実態を検証しています。

こうしたリスクは、Lightwellが特定したJavaライブラリの脆弱性とは性質が異なります。しかし、企業アプリケーションの開発や保守に関わるコンポーネントとツールを把握することが重要である点は、どちらにも共通します。

企業のセキュリティチームが次に取るべき対応

400件を超える未知の脆弱性が見つかったことは、企業アプリケーションで使うソフトウェアコンポーネントの可視性を維持する重要性を改めて示しています。

IBMとRed Hatは10月6日の発表で、影響を受けるJavaライブラリの一覧を公表していません。そのため管理者は、この発表だけでは脆弱なデプロイメントを特定したり、必要なパッチを判断したりできません。

それでも、組織が露出を減らすために実践できる対策がいくつかあります。

• ソフトウェアの依存関係を見直す: サードパーティ製アプリケーションに組み込まれた依存関係も含め、Javaライブラリとそのバージョンの正確なインベントリを維持します。
• 修正の優先順位を決める: ベンダーのアドバイザリやアップストリームプロジェクトの開示情報を監視し、利用可能な修正を深刻度、露出の度合い、事業への影響に応じて評価します。
• 古いコンポーネントを評価する: 互換性の要件から本番環境に残っているライブラリを洗い出し、サポートされたアップグレードやバックポートされたセキュリティ修正が利用できるかを確認します。

Lightwellを利用する組織は、自社環境の依存関係がその修復サービスの対象に含まれるかどうかも評価できます。

今回の発表は、Javaソフトウェアを運用するすべての組織が、400件超の脆弱性すべてにさらされているという意味ではありません。実際の露出は、影響を受けるライブラリ、導入しているバージョン、該当するアプリケーションの設定によって決まります。

セキュリティチームにとっての大きな教訓は、脆弱なソフトウェアの特定は問題の一部にすぎないということです。効果的な脆弱性管理には、それらのコンポーネントに依存するアプリケーションへ、テスト済みの修正を届けることも欠かせません。とりわけ、事業運営を止めずに古いソフトウェアを置き換えられない場合はなおさらです。

関連記事: オープンソースのセキュリティリスクについてさらに詳しく知るには、Shai-Hulud npmサプライチェーン攻撃に関する記事をご覧ください。