オープンソースはソフトウェアの開発の現場で広く利用されています。しかし2014年以降、OpenSSLのHeartbleed、glibcのGhost、BashのShellshockなどオープンソースの脆弱性が相次いで報告されています。本稿ではオープンソースの脆弱性と、その対策について説明します。
オープンソースの利用は広がるものの・・・
オープンソースの利用はあらゆる分野に広がっています。ゲーム、エレクトロニクス、プリンタといったソフトウェアでは早くからオープンソースが利用されていましたが、最近ではモバイルや自動車関連、IoTといった分野でもオープンソースを利用されることが普通になっています。世界最大のオープンソースのリポジトリサイトとして有名になったGitHubでは、登録されているオープンソースの数が2013年12月の時点で 1000万プロジェクトを超え、現在も増え続けています。 GitHubに限らず、新しいオープンソースプロジェクトが日々生まれる状況は続いており、オープンソースの利用も今後ますます広がっていくと考えられます。
一方で、冒頭で述べたようにオープンソースの脆弱性が相次いで報告されているという現状もあります。オープンソースの品質は実際のところはどうなのでしょうか。
オープンソースの品質と脆弱性
静的解析ツールのCoverityは、オープンソースの品質の向上を支援する Coverity Scan というサービスを提供しています。このCoverity Scanで実施したサービス を元に、Coveirty Scanレポートでは、オープンソースと商用ソフトウェアのバグ密度を比較した結果を報告しています。 このレポートによれば、調査の対象となった C/C++、Java、C# のオープンソースのバグ密度(1000行あたりのバグの数)は0.61、一方、商用ソフトウェアは0.76という数値でした。オープンソースの方が商用ソフトウェアよりも若干バグ密度が低いのです。バグの密度という観点では、オープンソースは商用ソフトウェアに遜色ない品質だということが言えます。
一方、Webアプリケーションの脆弱性にどの程度対応しているかという観点では、全く異なる結果が報告されています。 OWASP(Open Web Application Security Project)Top 10 は、Webアプリケーションの脆弱性の内、もっとも重要な10の脆弱性を報告しているオープンなプロジェクトです。このOWASP Top 10に該当するバグの割合(10万行ごとのバグ数)という視点で、商用ソフトウェアとJavaのオープンソースを比較すると、商用ソフトウェアの0.56という数値に対して、 オープンソースは8.61という非常に高い数値になっていることがわかりました。
オープンソースの品質は一般的なバグ密度という点では商用ソフトウェアと比較して遜色ありません。しかし、Web セキュリティという観点においては、この調査の対象となったオープンソースは、商用ソフトウェアよりもバグ密度が高い傾向にある、ということが言えそうです。商用ソフトウェアと比較すると、一般的にはオープンソースはセキュリティよりも機能追加等を優先するため、このような傾向があると考えられます。オープンソースは基本的には自己責任で利用することが求められているのです。
オープンソースの脆弱性回避にはバージョンの把握が必須
それでは、オープンソースを利用しつつ、脆弱性の問題を回避するにはどうすればよいのでしょうか。オープンソースの脆弱性は、オープンソースの特定のバージョンに紐付いています。例として、脆弱性を一元的に管理している NVD(National Vulnerability Database) というサイトでOpenSSLの Heartbleedの脆弱性のページ を見てみましょう。 ページ下部の“Vulnerable software and versions"の部分には、この脆弱性に該当するバージョンが羅列されています。逆にこれ以外のバージョンではHeartbleedの脆弱性は存在しません。つまり、脆弱性を含むオープンソースであっても、その脆弱性を持つのは特定のバージョンだけなのです。よって、オープンソースのバージョンを把握することで、より正確に脆弱性の有無がわかります。オープンソースを利用する際には、ソフトウェアの機能、ライセンスだけではなくバージョンもきちんと把握し、上記NVD等を参照して対象のバージョンに脆弱性がないかを確認してから利用するようにしましょう。
この脆弱性の有無の確認は、開発プロセスの早い段階で実施することをお薦めします。通常、実装すべきソフトウェアの機能が確定すると、利用するオープンソースもおのずと決まります。開発の段階に入ってから確認したのでは手戻りが発生してしまうため、この段階で脆弱性の有無を確認すべきです。後述しますが、この時点で利用しているオープンソースとそのバージョンをきちんとリスト化しておくとのちのち役に立ちます。
未知の脆弱性に対応するために
オープンソースの既知の脆弱性については、これまでご説明した方法で対応することができます。対応することが難しいのは、まだ発見されていない脆弱性です。オープンソースの脆弱性は、リリース後多くの人に利用され、何年か経過した後に顕在化するケースがほとんどです。例として挙げたOpenSSLのHearbleedの脆弱性を含むバージョンがリリースされたのは2012年の1月でした。一方、この脆弱性がHearbleedとして明らかになったのは2014年4月です。このケースでは作りこまれてから脆弱性が発覚するまで2年以上のタイムラグがありました。このように、ソフトウェアのリリース時に脆弱性が報告されていなくても、将来的にオープンソースの脆弱性が顕在化することはよくあります。事前に脆弱性を完全に把握しておくことは困難なため、現時点で脆弱性が報告されていないオープンソースにも将来的には脆弱性が発覚する可能性がある前提でオープンソースを管理しておく必要があります。
このような場合にも、利用しているオープンソースとそのバージョンを把握しておく方法が効果的です。オープンソースのバージョンを事前にきちんと管理しておくと、いざオープンソースの脆弱性が明らかになった場合でも、バージョンが異なるため脆弱性の影響を受けないのか、バージョンが合致して脆弱性への対応を取る必要があるのか、いずれにせよ迅速に判断し対応することが可能になります。 ですので、調査した時点で脆弱性が報告されていなくても、利用しているオープンソースについてはバージョンまできちんと把握しリスト化しておくことをお薦めします。また、オープンソースは利用しっぱなしではなく、当該のオープンソース、バージョンに新たな脆弱性が報告されていないか、NVDや該当するオープンソースのプロジェクトページを定期的にチェックする必要があります。
オープンソースをライブラリではなく、ソースコードとして利用している場合には、ソフトウェアに脆弱性がないか、製品のリリース前にもう少し積極的に確認することができます。現在では静的解析ツールはかなり進化しており、高い精度でバグを検知することが可能です。スクラッチで作成したコードだけではなく、オープンソースのコード、またオープンソースのコードと組み合わせたソフトウェア全体としてもバグや脆弱性がないかを検出する事ができます。自社作成コード部分に絞ってこういったツールを利用するケースが多いようです。しかし、オープンソースも製品に含まれるソフトウェアの一部です。静的解析ツールを自社作成コード部分だけではなくオープンソースの部分にも適用することで、リリース時には顕在化していないオープンソースのバグを事前に発見する事ができる可能性があります。
まとめ
オープンソースの脆弱性を避けるためには、まず利用しているオープンソースのバージョンを事前に確認することが大切です。それにより、既に報告されている脆弱性の有無を確認できます。また、バージョンをきちんと管理しておくことで、仮に脆弱性が顕在化した場合でも迅速に対応することができます。脆弱性が発覚してから、過去に遡ってリリース済みのソフトウェアで利用しているオープンソースのバージョンをすべて洗い出すことは困難です。開発の早い段階、つまり利用するオープンソースを確定した際に、そのオープンソースとバージョン、またライセンスも記録しておくことを推奨します。これは将来的に顕在化する脆弱性への対策だけでなく、ライセンス違反への対策にもなります。
本稿がオープンソースの脆弱性の管理・対策の一助となりましたら幸いです。