JNSA「セキュリティしんだん」

（12）オープンソースとの付き合い方再考（2014年7月4日）

日本ネットワークセキュリティ協会　幹事
（社）日本クラウドセキュリティアライアンス代表理事
アルテア・セキュリティ・コンサルティング　代表　二木真明

昨今、オープンソースのソフトウエア、とりわけフレームワークやライブラリとして多用されているものの脆弱性が大きな話題になっている。オープンソースソフトウエアを使うことのメリット、デメリットは、これまで多くの議論を経て、ほぼ明らかになっている。しかし、その利用実態は、こうした議論とはいささかずれたものになっているかもしれないと筆者は思っている。とりわけ、こうしたオープンソースのソフトウエアの安全性や安定性について、誰が責任を持つべきなのか、という部分が、実際の現場でどこまで考えられているのだろうかという疑問が、このところの脆弱性問題を見ていて湧いてくるのだ。

たとえば、最近大きな問題になった、Apache Strutsの脆弱性、とりわけ、既にコミュニティによるサポートが終了しているStruts1への対応である。こうした、いわゆる開発用のフレームワークは、アプリケーションがその機能に大きく依存するため、後から変更するのが困難になりがちだ。バージョンが一つあがっただけで、互換性がなくなり、アプリケーションの大幅変更を余儀なくされるケースも少なくない。そうした理由から、たとえばマイクロソフト社が提供している .net Framework では、きわめて古いバージョンも、依然としてサポートの対象となっている。
　一方、オープンソースソフトウエアは、移り変わりも激しく、また、コミュニティによるボランタリーな活動に支えられているという性質から、多くの場合、このような長期間のサポートは困難だ。そのライフサイクルはだいたい3年から長くて5年程度である。しかし、Windows XPサポート切れによる混乱を見てもわかるように、企業等の情報システムのライフサイクルははるかに長いのが実情だ。商用のフレームワークにおいてすら、最新バージョンに更新してアプリケーションを変更するために莫大なコストがかかるため、古いバージョンを使い続けざるをえず、そのせいで、Webアプリケーションが最新のWebブラウザに対応できない、といった問題が様々な現場で発生している。商用ソフトウエアならば、追加のコストを支払うことで、継続的なサポートを受ける道はあるかもしれない。しかし、オープンソースコミュニティが相手では、こうしたことは難しいだろう。最終的には、自ら問題を解決するしかないのである。

オープンソースコミュニティによって開発、提供されているソフトウエアは、様々な分野で利用され、いまやITの発展に不可欠の存在になっている。一方、こうしたソフトウエアは基本的に自己責任で使用しなければならない。コミュニティは善意でサポートを行うものの、そのソフトウエアが原因で発生した問題についての責任はとれないからだ。当然ながら、こうしたソフトウエアのライセンス条項には自己責任での使用が明記されている。今回のような場合、脆弱性の対応責任は、それを使ったシステムを開発したSIerとそれを指示または承認したユーザの双方が（コスト負担という形を含め）負わなければならない。

さて、では、こうしたオープンソースソフトウエアは、どれくらい浸透しているのだろう。たとえば、ネットワークに接続できる家電製品などのマニュアルを見ると、その多くに、GPLやBSDなどのオープンソースライセンスに基づく記述がみられる。つまり、直接のIT製品のみならず、マイクロプロセッサが組み込まれる、あらゆる分野において、オープンソースは既に浸透しているということである。
　たとえば、製品にネットワークやUSB周辺機器、各種ストレージなどの機能を組み込むために商用の組み込み用OSではなく、LinuxなどのオープンソースOSが使用されるケースも多い。さらに、その上に様々な機能を実現するためのアプリケーションも、こうした環境で提供されているオープンソースのライブラリ、たとえばOpenSSL で提供される暗号通信やデータ暗号化機能などに依存している。独自開発のプログラムでも、その多くが gccやg++、Perl、PHPといったオープンソースの開発言語環境と、そのライブラリが提供する機能に依存しているのである。つまり、オープンソースはこうした製品を開発する上でのサプライチェインの中に深く組み込まれてしまっているのだ。

たとえば、この4月のHeartbleed以降でも、OpenSSLでは、多くの脆弱性が発見、修正されている。OpenSSLは、暗号や電子署名、ハッシュ、SSL/TLSによる通信などに関連する様々な機能を提供するライブラリであり、多くのソフトウエアがそのライブラリを抱き込む形で作られている。たとえば、WindowsならDLL(ダイナミックリンクライブラリ)、Linux 等ならシェアードライブラリ（オブジェクト）として組み込まれているのであれば、脆弱性への対応は、OpenSSLパッケージを更新してOSを再起動してやればいい。しかし、こうしたライブラリがアプリケーションの一部として組み込まれてしまっている（ハードリンクされている）場合は、それだけでは不十分だ。アプリケーション自体の再リンク（ビルド）が必要になる。こうした点が、アプリケーション開発者や、製品の管理者ににどこまで理解されているかも気になるところだ。製品を提供する者が、その責任においてこうしたことをしっかりサポートしていく必要がある。

さらに、コミュニティによるサポートが切れた場合、脆弱性やバグの修正を誰が行うのかという点も問題である。この場合、責任はそれを使っている側、もちろんエンドユーザではなく、製品として組み込んで提供した側にあることは明らかだ。利用者に不都合やリスクをもたらすような不具合は、自らソースコードを修正して対応する必要がある。強調したいのは、オープンソースの使用を選択した時点で、こうした可能性も視野に入れておく必要があるという点である。サポートが切れる前に製品を更新できなければ、自らソースコードをメンテナンスする覚悟も必要になるのである。製品組み込みの場合、メーカー保証期間内のサポートでよいと思う向きもあるかもしれないが、こと脆弱性となると話はもっと複雑になる。たとえば、利用者に危険が及ぶような問題については、最悪、リコールが必要になる可能性もあるだろう。つまり、一度世に出してしまった製品については、こうした問題をずっとトレースしておく必要があると言うことだ。そのための人材を自ら確保するのか、外部に委託するのかはその企業の考え方だが、いずれにせよ責任が存在するという点を忘れてはならないだろうと思う。

オープンソースは、多くの英知の集合体であり、社会的な財産である。個々の利益ではなく、社会の発展のために提供されている貴重な資源であり、IT社会の発展に大きく寄与している。一方で、これから利益を享受する者は、それに応じた責任も負わなければならない。その点をきちんとわきまえてオープンソースを活用していきたいものだ。

« 「（11）話題のセキュリティ問題を考える」へ

「（13）SSL再考」へ »