その答えはLog4jを利用している組織の対策が不十分だからだ（注1）。現在でも、アプリケーションの4割近くが脆弱なバージョンのままだという。

　報告書によると、アプリケーションの約3分の1が2015年8月にサポートが終了した「Log4j2 1.2.x」を使用しており、パッチで更新していない。さらに2.8％のアプリケーションで、Log4Shellの脆弱性が残ったままのバージョンが利用され続けている。

　Veracodeによると、3.8％のアプリケーションで「Log4j2 2.17.0」が使われている。Log4Shellに対するパッチが適用されているが、「CVE-2021-44832」という別の脆弱性を含んでいる（注2）。この脆弱性も深刻であり、リモートでコードを実行される恐れがある。

状況の改善には数年がかりの取り組みが必要

　報告書によると、ソフトウェア開発とオープンソースの使用に関連するセキュリティの慣行を改革するための数年にわたる取り組みはまだ不十分だ。

　「開発者は自分が開発したアプリケーションに対して責任を負うべきであり、オープンソースソフトウェアのセキュリティには、間違いなく改善の余地がある」（Veracodeのクリス・エング氏《最高研究責任者》）

　エング氏によると、多くの開発者は脆弱性の危機に対して、当初はセキュリティアップグレードを適切に使用してバージョン2.17.0をインストールした。だが、2.17.1のリリース以降はパッチを適用しない形に戻ってしまったという。

　ASF Security Responseチームの広報担当者は、次のように述べた。

　「Apache Software Foundation傘下のプロジェクトにおいて、以前からLog4jは脆弱性のないバージョンにアップグレードされており、これは、より広いアクティブなオープンソースエコシステムにも当てはまる。私たちは深刻度の高い共通脆弱性識別子（CVE：common vulnerabilities and exposures）を遅滞なく発行するなど、あらゆる適切なチャンネルを通じてアップグレードの緊急性を下流のプロジェクトに積極的に通知してきた」

3866もの組織でどのバージョンが使われているのかを調査

　Veracodeは報告書を作成するために、2023年8月15日から同年11月15日までの90日間で、3866の異なる組織で使用されている3万8000以上のアプリケーションをソフトウェアスキャンして得られたデータを研究者が分析した。これらのアプリケーションは、最も古いものでLog4jのバージョン「1.1」を使っていた。最新の「3.0.0 alpha 1」を使用する組織もあった。

　今回の調査結果は驚くべきものではない。連邦政府による2022年の報告書「Cyber Safety Review Board」は（注3）、Log4jの危機を完全に解決するには何年もかかると警告している。