元・Java専門記者がLog4j 2脆弱性に見た「複雑性と魔神のかけら」 Javaの歴史とバザールの矛盾（2/6 ページ）

[星暁雄，ITmedia]

　この中国当局の反応から、次の2つの洞察が得られる。1番目に、脆弱性の問題は、ソフトウェア開発者コミュニティーやシステムを利用するユーザーだけの問題ではなく、国の安全保障に関わる問題となっている。2番目に、中国当局がこのような強い反応を示したことは、中国が国際的なサイバー戦争に参戦している当事者であることを示唆する。

　米国政府も素早く反応した。Log4j 2の脆弱性問題を受け、1月13日にホワイトハウス主催の「オープンソース・ソフトウェア・セキュリティ・サミット」が開催された。そこに参加した企業の1社であるGoogleは、次の提案を行った。（1）官民でOSS（オープンソースソフトウェア）の重要プロジェクトを特定する。（2）セキュリティ、保守、テストの基準を確立する。（3）公的・私的支援を拡大する。

　オープンソースといっても内容はさまざまだ。Googleのような巨大テック企業が自社製品や自社技術の一部と同様に支援する重要プロジェクトもある。こうしたプロジェクトの名前を明らかにし、資金援助も積極的に行っていこうという訳だ。

　今や脆弱性はシステムの開発者、利用者だけの問題ではない。私たち全員にとっての問題といえる。今後は、オープンソースのソフトウェアも機能だけでなく、開発リソースが潤沢なのか、よくテストされており安心して使えるかどうかを、より意識する必要が出てきそうだ。

バザールの矛盾──便利な機能を入れようとしたばかりに……

　JavaのライブラリApache Log4j 2の脆弱性（CVE-2021-44228）を引き起こしたものは「ルックアップ」と呼ばれる機能だった。この機能は「任意の場所でLog4j 2の設定に値を追加する方法を提供する」というもの。

　Log4j 2に限らず、たいていのJavaライブラリは設定ファイルにより柔軟に機能をカスタマイズできるよう作られている。Log4j 2ではその柔軟性が行き過ぎ、任意のコード実行を可能としてしまった。

　オープンソースソフトウェア開発では、「目玉の数さえ十分あれば、どんなバグも深刻ではない」という“考え方”（ナラティブとも）がある。これはオープンソースという概念の提唱者であるエリック・レイモンドの論文「伽藍とバザール」に「リーナスの法則」として登場する。

　Log4j 2の脆弱性は、Log4j 2がオープンソースであることにより第三者が発見して報告できた。だが「これだけ深刻な脆弱性はレビュー段階で発見して塞がれるべきだった」という考え方もあるだろう。何が問題だったのか。「目玉の数」（それを見る人の数）が十分ではなかったのかもしれない。あるいは、エリック・レイモンドのいうリーナスの法則には例外があるのかもしれない。Log4j 2の脆弱性はオープンソース・ソフトウェア開発の信頼を揺るがすような出来事だと考える人がいるかもしれない。

　オープンソースソフトウェア開発の裾野が広がり、多種多様なプロダクトが登場していること、Javaのライブラリの機能範囲は広大なことを考えると、この種の事故が出てくるのは時間の問題だったのかもしれない。前述のGoogleらの提案は「リーナスの法則」に頼らない正攻法といえる。

　Apache Log4j 2の開発リソースは潤沢ではなかったようだ。この先、この種の問題の再発を防ぐ仕組みをどう作ればいいのか。セキュリティへの知見を持つ開発者によるレビュープロセスを入れるにしても、そのためのリソースは誰が提供するのだろうか。オープンソース開発の落とし穴が露呈したと考える人もいるだろう。

専門記者が見たJavaテクノロジーの背景　ルーツはSunの情報家電プロジェクト

　ここまでは脆弱性を巡る事実関係や背景を追ってきた。ここから先は、Javaテクノロジーの本来の設計思想について、歴史的背景の話を交えて語っていく。

　ここであらためてお断りしておくと、筆者はJavaテクノロジーについては1995年のデビューからジャーナリストとしてウォッチしてきた。独自の情報源も持っていた。そのため、ソフトウェア開発やコンピュータサイエンスに詳しい人にとっても初耳の情報が含まれるかもしれない。「この情報は初耳だから怪しい」と感じる場合もあるかもしれないが、そんなときには「元・Java専門記者が語るナイショ話」として受け止めていただければありがたい。