年末に近いので変更リリースとかは年明け以降に、という事にしていましたが、急遽lo4j2にリモートコード実行の脆弱性が発覚したので、使用しているJavaアプリケーションを洗い出して最新ライブラリへ入れ替えの対応をしていました。

　log4j2について人知れず存在していた便利機能が今になって仇となったような感じですが、影響範囲はログ出力だけで、対応もライブラリの置き換えだけなので、実際の作業自体は大したことはありません。最初の脆弱性発覚後バージョンアップは計３回となり、一度脆弱性が指摘されたものに対しては、連鎖的に問題が指摘されやすくなっているようです。とはいえ、オープンソースとして利用させてもらっているのでメンテナンスをしている方々に感謝ですね。

　今回のようにセキュリティ問題として大々的にアナウンスされたものは即対応が必須となりますが、数年前から稼働させているようなアプリでは、使用しているライブラリがバージョンアップされていても、大抵は従来のままという事が多いような気がします。

　明確に運用方針を挙げている組織であれば、ハードやOS、ミドルウェア、言語についての、特にセキュリティパッチについては適切に対処されていると思いますが、アプリで使用しているライブラリやフレームワークまではあまり手を付けていないように思います。

　筆者の場合、基本的に一人で面倒を見ているようなものですが、セキュリティ対応以外でのライブラリのバージョンアップは正直考えたことも無かったです。今回メンテナンス対象となったアプリでいえば開発当時のlog4j2 2.5を使ってそのまま5年以上が経過、今回の脆弱性発覚でやっと2.17に上げたところです。

　稼働中のアプリが使用しているライブラリのバージョン管理はやった方がよいとは思うのですが、情報収集から対応、稼働確認等、かなりの運用コストが掛かり、かつ機能が増える訳でも無いので、やるとしても何かしら追加の業務要件が発生した時の次いでにバージョンをチェックして、変更するか検討するくらいですかね。