IDCのリサーチディレクターを務めるケイティ・ノートン（Katie Norton）氏は次の通り述べる。

　「検証済みの脆弱性が見つかってから修正プログラムが本番環境で稼働するまでにどれくらいの時間がかかるか、どれくらいの顧客が実際にデプロイしているのかを確認したい。リポジトリに置かれたままで誰からも取得されない修正パッチは、何のリスクも軽減しない。公的な脆弱性識別子『CVE』（Common Vulnerabilities and Exposures）が付与される検知結果の数や、アップストリームのメンテナーに採用されるパッチの数にも注目したい」

　ChainguardとRed Hatは、公表された脆弱性に識別番号を割り当てる権限を持つCVE採番機関（CNA）に認定されている。ただしAthenaの初期運用の大半で、Chainguardはその認定を受けていなかった。

　協調的脆弱性開示のプロセスにおいて、情報開示は修正作業よりも後の段階で実施される。Chainguardは公表した14件を大幅に上回る脆弱性を修正したと報告している。しかし、影響を受けるオープンソースソフトの元の開発者たちの負担にならないよう、あえて公表のプロセスを慎重に進めているとノートン氏は説明する。

　「AIによって、修正を調整してリリースするよりもはるかに速いペースで脆弱性を発見できるようになった。企業側の対応は後れを取っている状態だ」とノートン氏は指摘し、Chainguardが2万1000件以上の検証済み検知結果を出しながら、公表は14件にとどまっている背景に触れた。

　2026年7月にIDCが実施した調査「DevSecOps and Software Supply Chain Security Survey」によると、約40％の企業が「毎月の脆弱性対応よりも速いペースで新たな脆弱性が積み上がっている」と回答している。

　脆弱性の発見から修正・公開までのタイムラグの拡大という課題に直面しているのは、ChainguardのAthenaだけではない。Anthropicが主導する「Project Glasswing」が更新した脆弱性開示台帳でも同様に、AIが発見する膨大な数の脆弱性と、人間が判定・修正・開示できる件数との間に乖離（かいり）が見られた。調査会社Omdiaの調査によると、AIによって攻撃者の手法が増えたことで、過去1年間にAIの脅威に関連するサイバー被害を報告した組織は80％近くに上った。

　ノートン氏によると、AthenaとLightwellはシステムの迅速なアップデートができない企業向けに、あらかじめパッチが適用された安全なOSSを販売しているという。「両社は『AIが脆弱性を発見する速度は、人間が対応してきた従来の公開・修正モデルが処理できる限界を超えている』という考え方を共有している」

アプリケーションを壊さずに古いJavaを修正する

　両プロジェクトが成果を挙げた対象は、いずれもJavaライブラリに関するものだった。Athenaは「新しいバージョンでは直っているが、公表されておらず古い版に放置されていた脆弱性」に注力した。一方、Lightwellは「企業が使用するJavaライブラリの現行版および旧版の両方で見つかった、これまで知られていなかった脆弱性」に焦点を当てた。

　両プロジェクトはこうした業界に最初に狙いを定めた理由を、ノートン氏は次のように解説する。「Javaは、企業のリスクと修正の経済的合理性が合致する領域だ。銀行や保険、政府機関といった規制が厳しく長期稼働するシステムで使われている。このようなシステムのアップグレードは大規模なプロジェクトになるため、ライブラリの同じバージョンを何年も使い続けることが多い」

　そのため、古いJavaライブラリを使い続けている企業は、新しいバージョンで施された修正内容から脆弱性を逆算するAIの脅威にさらされる恐れがある。

　「検知された内容の中には深刻なものもある。Chainguardが初期に公表した1件は、攻撃者が任意のユーザーになりすましてログインできる恐れがあった」とノートン氏は述べ、広く使われているJavaライブラリ「jjwt」に影響する脆弱性（識別子：CGP-xpq5-jm7p-884r）に言及した。

　Lightwellは、新旧双方のJavaライブラリの脆弱性に対してAIを活用した修正パッチを開発した。Trent AIでアドバイザーを務めるニール・カーペンター（Neil Carpenter）氏によると、ミッションクリティカルなレガシーシステムを運用する企業は、それらのパッチを古いバージョンに適用することで、大規模なアップグレードに伴うリスクを回避できるという。

　「Javaはバックポートの需要が最も高く、アップグレードへの抵抗が強い傾向がある。そのため、両プロジェクトがJavaから着手したのは非常に理にかなっている」とカーペンター氏は語る。

　Broadcomの「Truesource」も、同様のサプライチェーンセキュリティの課題に取り組む取り組みの1つだ。Broadcomは普及度の高いJava開発フレームワーク「Spring」を保守している。

　「多くのユーザーがSpringの特定バージョンに固定したまま運用している。過去5年間、Springやその関連フレームワークには数多くの重大な脆弱性が見つかってきた」（カーペンター氏）

DevSecOpsチームのためのセーフティーネット

　AthenaやLightwellの修正策は有益であるものの、実務者たちはこれらの取り組みを「これさえあれば完璧」ではなく、あくまで「既存のベストプラクティスを補強する」ものだと捉えている。

　NikeのDevOpsエンジニア、スレシュ・ガングラ（Suresh Gangula）氏は「どちらの取り組みも有用だが、強固なセキュリティ対策を実践している組織にとっては必須というよりもセーフティーネットに近い」との見解を示す。

　技術力の高いエンジニアリングチームにとって、脆弱性のあるライブラリへの望ましい対処法は、やはりアップストリームが提供する公式の最新バージョンにアップグレードすることだとガングラ氏は説明する。

　エンジニアリングチームは脆弱性を検知するため、SCA（ソフトウェアコンポジション解析）やSAST（静的アプリケーション解析）／DAST（動的アプリケーション解析）、機密情報のスキャン、開発パイプラインでの自動セキュリティチェックを活用している。コーディング支援AIや統合開発環境（IDE）のセキュリティツールも、コード記述中に潜在的な問題を指摘する。ただし、それらの指摘も確立されたセキュリティ管理策を通じて検証する必要がある。

　LightwellやAthenaが最も真価を発揮するのは、そうした従来の手法では対応し切れない場面だとガングラ氏は述べる。CVEが付与されずスキャナーが検知できない修正や、新バージョンへの移行によって互換性やコンプライアンスが損なわれるケースなどだ。

　「そうした場合、検証済みのバックポートパッチや信頼できるベンダーが再構築したアーティファクトがあれば、直ちにリスクを下げられる。チームが計画的に正規のアップグレードを進めるための時間も稼げる」とガングラ氏は言う。

　ただし、依存関係のスキャンで問題が検出されないからといって、ソフトウェアが安全である証明にはならないとノートン氏は指摘する。「これまで問題なしと判定されていたバージョンでも、スキャナーが警告を出し始める事態を想定すべきだ。脆弱性は最初からそこに存在していたのだから」。

　スキャナーが警告を出さない場合でも、チームは警戒を怠ってはならない。「運用の優先事項は、たとえスキャナーから指示されていなくても、安全な修正パッチを本番環境に確実に適用することだ」（ノートン氏）

　Screen Studioのソフトウェアエンジニアであるカツペル・ミハリク（Kacper Michalik）氏は、Lightwellには依存関係の管理で開発者が直面するトレードオフを解消して、チームの負担を軽減する可能性があると語る。

　「依存しているパッケージに深刻な脆弱性があると判明するのは、大きなストレスだ。自チームの過失ではないにもかかわらず、迅速な対応を迫られる。対策の一つとして、依存関係のバージョンを厳密に固定して、テストしていない要素が更新時に紛れ込まないようにする方法がある。一方で、固定してしまうと自動のセキュリティパッチを取り込めなくなるというトレードオフが生じる。Lightwellのようなプロジェクトは、この溝を埋めることを目指している」（ミハリク氏）