2012年8月に明らかになったJREの脆弱性は、以前のパッチに起因すると考えられている。これは、JavaのサブコンポーネントであるAbstract Window Toolkit（AWT）のバグで、ローカルシステム上でコードの実行を可能にする恐れがある。これによりサンドボックスを回避し、システムに侵入することが可能となる。

　Oracleのソフトウェアアップデートが新たな脆弱性を暴露する結果になっていることもあり、Javaのソフトウェア開発ライフサイクルの信頼性に対しても疑問の声が上がっている。全てのバグを防ぐことは不可能にせよ、Javaの新たなバグの導入を防ぐには、強力なセキュリティ開発ライフサイクルが必要であることは明らかだ。

　実際問題としては、Javaのセキュリティ問題は当分解消されることはないだろう。今後も脆弱性が発見されて攻撃され、Oracleによってパッチが提供されるはずだ（その対応速度と効果は、その都度異なるだろうが）。OracleがJavaの開発を推進しながら、一方でセキュリティを維持するというのは、決して容易なことではない。残念ながら、Sunから受け継いだ資産の上に、OracleがJavaの技術的負債を加えてしまった結果、Javaの脆弱性が増え続けているのだ。

　Oracleのラリー・エリソンCEOは、Oracleの製品は「極めて堅牢」だとかつて宣伝した。ただし、セキュリティに対するこうした姿勢は、JREには適用されていない。Oracleのセキュリティに対するアプローチは、米MicrosoftやAdobe Systemsといった競合ソフトウェアベンダーと比べて成熟度が低いと一般にみられており、そのことが企業でのJREの利用にも影響を与えている。

　MicrosoftとAdobeは、それぞれのセキュリティ方針を改め始めた。その結果、従来製品やレガシーアプリケーションでOracleと同様の技術負債を抱えていたにもかかわらず、両社のアプリケーションのセキュリティは改善された（参考：米Oracleの怠慢を批判――「Javaはアンインストールすべき」）。一方のOracleは、CIA（米中央情報局）などセキュリティに対する要求が厳しい顧客に長い間ソフトウェアを提供してきたが、Oracle社内での意識の隔絶が大きくなっており、JavaとJREで強力なセキュリティの開発を推進する動きはまだ見られない。JREが企業にとって大きな脅威にならないようにするには、この状況を改めなければならない。

Javaをセキュアにする方法

　「Javaのセキュリティは悲惨な状況なので、企業のクライアントサイドアプリケーションではJavaを無効にしなければならない」と考えている人は多い。Adobe Readerのようなソフトウェアの場合、有力な代替選択肢が存在する。だがJREには、今のところ代替となる現実的な選択肢は存在せず、多くのエンタープライズアプリケーションがJavaに依存しているのが実情だ。つまり多くの企業にとって、Javaを無効にするという選択肢はあり得ないのだ。

　とはいえ、一般のクライアントソフトウェアのセキュリティを維持するための標準的なアドバイスは、全てJREにも当てはまる。一例を挙げれば、

• 必要としないのであればJREをインストールしない（もしくはアンインストールする）
• JREを最新状態に保つ
• 旧バージョンのJREを削除する
• クライアントサイドでパッチ管理とエンドポイントセキュリティ対策を実施する

といったことだ。

　また、Javaを対象とした追加的な対策も考慮すべきである。例えば、

• JREと関連ソフトウェアを社内の仮想マシンで動作させる
• JREを低い権限で実行する（これは既にデフォルトポリシーになっているはずだ）
• ホワイトリストに含まれるJavaアプレットを「NoScript」などのソフトウェアとともにJRE内で実行させる

などの対策が考えられる。また、Microsoftが提供する「Enhanced Mitigation Experience Toolkit（EMET）」を使えば、WindowsシステムでJREをさらにセキュアな構成にすることができる。

　JREの問題を回避するには、Javaコードをネイティブの実行可能プログラムにコンパイルするという方法もある。ただしこれは、「Write Once, Run Anywhere（同じプログラムがどこでも動く）」というJavaの利用価値を否定することでもある。ほとんどのJavaアプレットがWindowsかMac OSのどちらかで動作しているので、この方法が妥当だと考える企業もあるだろうが、Javaが動作する全てのプラットフォームに対処できるわけではない。コンパイルが可能であれば、たった1つのアプリケーションのためにJREをインストールしているシステムの数を削減できるかもしれない。こうした方法は、大きな労力を伴うが、リスクを引き受け可能なレベルにまで下げることができる可能性が高い。

結論：必要なければJREをアンインストールすべき

　Javaのエコシステムは、複数システムに対応したソフトウェア開発を容易にする機能を数多く生み出した。クロスプラットフォーム開発を容易にしたいというニーズの結果として生まれたのがJREだ。だが残念なことに、JREとOracleのソフトウェア開発ライフサイクルで明るみになった多数の脆弱性のせいで、Javaエコシステムは大きな批判にさらされることになった。

　企業は、Javaの利用方針について真剣に考えなければならない。幸いなことに、ビジネスでどうしてもJREが必要だとしても、それがエンドポイントにもたらすリスクを低減する手段は幾つか存在する。逆に、どうしても必要だということでなければ、JREをインストールすべきではない。