OSSの支持者たちは「『リーナスの法則』に従うのが、よりセキュアなアプローチだ」と主張する。リーナスの法則とは、「十分な数の目玉があれば、全てのバグは洗い出される」というもの。言い換えれば、開発者基盤が大きければ大きいほど、ほとんど全ての問題とその対策が明らかになる、ということだ。例えば、OSSの「Linux」は、全世界の開発者が1時間当たり9件の貢献をしており、それが改良と修正の原動力になっている。

　だがHeartbleed脆弱性の中心にあるOSSである「OpenSSL」の問題は、OpenSSLが広く利用されているにもかかわらず、広範なサポートが提供されていないということだ。

　OSSのセキュリティの現実や安全性に関して、企業はHeartbleed脆弱性からどんな教訓が得られるのか。そして自社にOSSをセキュアに導入する際に留意すべき事柄とは何なのだろうか。

OSSのセキュリティリスクとは

　プログラムのソースコードが公開されているからといって、そのプログラムを正しく理解し、定期的にその評価とテストをしている専門家がたくさんいるわけではない。OpenSSLは、推定で全世界のWebサーバの約3分の2で使われているにもかかわらず、そのコードを検証したり、現在でも安全であるのかどうかを（つい最近まで）誰も確認しようとしかった。2年にもわたってHeartbleed脆弱性が気付かれることなく放置されていたのは、そのためだ。

　とはいえ「欠陥が発見されて修正されたのだから、OSSモデルはうまく機能した。ソースコードが公開されていなければ、こうした検証や修正は不可能だ」と主張する人も多いだろう。

　サポートされていないソフトウェアの使用を社内規定で禁じている企業は多い。だが現実には、何千社もの大企業がOpenSSLプロジェクトで開発された重要なセキュリティソフトウェアを何の疑問も抱かずに配備してきた。同プロジェクトは年間わずか2000ドル（約20万円）程度の寄付を受けているにすぎず、フルタイムのスタッフは1人しかいない。OpenSSLのような複雑なソフトウェア製品をサポートするのに必要なマンパワーを維持するには、リソースが決定的に不足しているのが実情だ。

　Linuxや「OpenStack」などのOSSプロジェクトは一般に、そのソフトウェアを利用する企業から専従スタッフの提供を受けている。これらのスタッフは、プロジェクトに協力するとともに、コミュニティー全体でコードを共有している。

　注意しなければならないのは、OpenSSLがOSSであることがHeartbleed脆弱性の原因ではない、ということだ。OpenSSLプロジェクトが必要なサポートを得ることができなかったことが原因なのである。このため、OpenSSL Software Foundationは現在、コードの定期的な検証と変更記録の作成、複雑さの軽減、コミュニティーとの意思疎通の改善などの取り組みに必要な資金援助を求めている。

　OpenSSL Software Foundationが特に求めているのは、重要なセキュリティライブラリを広範に利用しながらも、長い間それを当然のように思ってきた民間企業と政府組織からの支援だ。Heartbleed脆弱性を修正するには数百万ドルの費用が掛かる見込みだが、わずか数千ドルの開発援助資金が提供されていれば、この問題を避けることができたかもしれないのである。

　幸いにも、米Facebook、米Google、米IBM、米Microsoftなどの業界大手は、Linux Foundationと共同で「Core Infrastructure Initiative」というプロジェクトを立ち上げた。このプロジェクトの狙いは、OpenSSLなどのOSSのコア技術をめぐる資金調達と開発環境を改善することにある。

　この資金援助がOSSに追い風となるのは間違いない。ただし企業は、OSSを社内で利用する際に検証を怠ってはならない。これはソースがオープンであるかクローズドであるかにかかわらず、どんなタイプのソフトウェアについてもいえることだ。

OSSのセキュリティに関するベストプラクティス

　企業がHeartbleed事件から学ぶべき最大の教訓は、ソフトウェアのセキュリティに関しては、誰かが「このソフトウェアは安全だ」と言ったとしても、それを当てにしてはならないということだ。企業のセキュリティチームは独自にリスク評価を行い、自社のインフラに影響する可能性が高い脅威に対して、ソフトウェアのコードやコンポーネントのセキュリティが確保されているか検証しなければならない。また、全ての前提条件を文書化して第三者による検証を可能にする必要もある。

　リスク評価には、「脆弱性が発見されたら、すぐにパッチが配布されるのかどうか」「パッチはどのような形で提供されるのか」といった問題の分析も含めるべきだ。特にOSSの場合、コントリビューション（寄贈コード）の評価と採用に関する明確な基準を持った成熟したコミュニティーが存在し、エラーや問題に対処するための体制が整っている必要がある。さらにいえば、ソフトウェアのダウンロード件数よりも、配備の成功例を検証したケーススタディの方が価値があるということだ。

　ソフトウェアの問題は、OSSに限ったことではない。クローズドソースの商用ソフトウェアに関していえば、企業はセキュアな開発ライフサイクルフレームワークが何らかの形で運用されていることを確認する必要がある。ベンダーにソフトウェア開発ライフサイクルについて問い合わせ、資料を請求すればいいのだ。セキュリティを重視した健全な開発プロセスを採用しているベンダーであれば、情報提供をいとわないはずである。あるいは少なくとも、開発責任者に製品のセキュリティに関する説明をさせるだろう。

　企業がオープンソースとクローズドソースのどちらのソフトウェアを採用するにせよ、コンポーネントに突然、障害が起きたり、それが弱点になったりすることがあるという前提でインフラを構築することが肝要だ。コンポーネント間の依存関係を理解し、必要があればそれらを交換できるようにしておく必要がある。

　オープンソースかクローズドソースかにかかわらず、ソフトウェアの障害に耐えられるインフラを構築することが、将来のソフトウェアの脆弱性が企業とそのデータにもたらすリスクを最小限に抑えることにつながるのだ。

本稿筆者のマイケル・コッブ氏は、セキュリティを専門とする著名なライターで、IT業界において20年以上の経歴を持つ。現在は理解と実践が容易なITセキュリティのベストプラクティスの作成に力を注いでいる。共著書に『IIS Security』があり、大手IT出版社に多くの技術記事を寄稿している。Microsoft認定データベースアドミニストレータ（MCDBA）、Microsoft認定プロフェッショナル（MCP）の資格を持ち、CESG（英国の情報保証国家機関）認定のアドバイザー（CLAS）に登録されているコンサルタントでもある。