脆弱性「Log4Shell」から考える–OSSの信頼性とセキュリティリスクの管理

今回は「脆弱性「Log4Shell」から考える–OSSの信頼性とセキュリティリスクの管理」についてご紹介します。

関連ワード （セキュリティ等） についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、ZDNet Japan様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

　Java向けのログ出力ライブラリー「Apache Log4j」に見つかった脆弱性「Log4Shell」には1つの予測可能な結果があり、ビジネスリーダーと政府は“オープンソース”に関する懸念を強めています。

　成功につながるソフトウェアの多くが商用ベンダーではなくボランティアによって作成されていること、最も重要なシステムの一部でオープンソースソフトウェアが使用されていることをほとんどの人は知りません。さらに、ほとんどの人は、成功につながるすべてのオープンソースソフトウェアのリストを確信を持って提示することができません。

　SSL/TLS実装ライブラリー「OpenSSL」に見つかった「HeartBleed」やLinuxカーネルの「Dirty COW」、Javaウェブプリケーションフレームワーク「Apache Struts」の脆弱性に起因する、米信用情報会社Equifaxでの情報漏洩などの過去の重大なインシデントで見てきたように、政府の審査が行われており、一部のチームは「良くないオープンソースコンポーネント」（今回はLog4j）を「より安全な代替コンポーネント」に置き換えようとしています。

　しかし、これらのシナリオでは、現代社会におけるオープンソースの信頼性の高さという重要な側面が見落とされています。

　実際に、オープンソースソフトウェアは信頼性が高いと考えられており、一部の組織では、重要なセキュリティレビューを行わず、自由にダウンロードし、そのまま使用しています。つまり、企業が、インターネットからダウンロードしたソフトウェアに対して、自社で開発したソフトウェアに対して行うのと同じレベルのセキュリティレビューを行わない場合があるということです。

　もしオープンソースソフトウェアのセキュリティについて疑問があるなら、組織内でコンテナ仮想化プラットフォーム「Docker」やXMLドキュメントを解析するためのソフトウェアライブラリー「libxml」、またはアプリケーションが依存しているオープンソースのデータベースを評価している担当者に聞いてみてください。

　すべてのオープンソースソフトウェアに対して完全なセキュリティレビューが行われていた場合でも、レビューが行われたのは最初の1回だけで、アップデートのたびに繰り返し行っていないかもしれません。それは、オープンソースの取り組みに対する信頼の証と考えることができるかもしれません（あるいは、レビューやテストのためのリソースが不足しているからかもしれませんが）。

　組織がオープンソースを採用する理由はさまざまですが、主に3つの理由があります。

　まず、多くの場合、オープンソースソフトウェアにはライセンス料金が発生しません。個別にソフトウェアを採用する分には予算承認や調達審査の必要がないため、これはある程度魅力的です。

　次に、選択したオープンソースはその分野のエキスパートによって開発されている可能性が高く、その分野のエキスパートを従業員として雇用するよりも容易でコストもかかりません。

　最後に、選択したテクノロジーは、多くの場合、問題に対して評判の良いソリューションです。たとえば、コンテナオーケストレーションに使用できるソリューションは多数ありますが、「Kubernetes」は最も評判の良いソリューションです。つまり、Kubernetesの実装は同僚と競合他社の双方に信頼されていることを意味しているわけです。

　採用の議論で迷いを生じさせるのは、商用ソフトウェアと同様に、多くの場合、オープンソースソフトウェアは複数のコンポーネントから構成されるということです。単独で実行可能なLinux実行ファイルやKubernetes実行ファイルはありません。それぞれが多数の依存ファイルを必要とします。

　同じことが、モバイルアプリケーション、IoTデバイスのファームウェア、イベントの発生に応じてプログラムを実行する環境を提供する「AWS Lambda」にデプロイされている単純なビジネスロジックの関数にも当てはまります。すべてのアプリケーションには、それらが適切に機能するために必要な依存ファイルがあるのです。