オープンソースソフトウェアのセキュリティ

オープンソースソフトウェアのセキュリティは、オープンソースソフトウェアにおけるソフトウェアの誤用・障害や不正アクセスに対するセキュリティの評価である。

メリット[編集]

プロプライエタリソフトウェアでは利用者はソフトウェアベンダーが提供するパッチやアップデートの更新頻度に依存したセキュリティレベルを受けなければならない^[1]。このようなソフトウェアモデルでは使用されているコンパイラは信頼できるソフトウェアを生成することを仮定しているが、Thompson hackにより名祖となったケン・トンプソンが提示したように、コンパイラはバックドアを用いて適切な意図を持った開発者により不適切なソフトウェアを非意図的に生成するよう改竄することができる^[2]。コンパイラのソースコードがオープンソースソフトウェアとして利用できる場合、開発者は不適切な意図がコンパイラに含まれていれば、それを見つけることができるかもしれない。デイビット・A・ウィーラー（英語版）は2つの異なるオープンソースのセルフコンパイラを用いることで、Thompson hackによって改竄されていないことを確認されたコンパイラを特定することができると述べた。ケルクホフスの原理は敵が軍事機密システムを盗むが軍事機密情報を得ることはできないことを基点としている。アウグスト・ケルクホフスのアイデアは現代の多くのセキュリティの考え方の基点にもなっており、隠蔽によるセキュリティ（英語版）は不適切な考え方と見なされている ^[3]。

デメリット[編集]

ソースコードが利用可能なだけではレビューの恩恵を受けることはない。セキュリティシステムの設計・開発の専門家であるマルクス・J・ラナム（英語版）が出会った事例としては、彼が初めてファイアウォール・ツールキットをリリースした際、即座に2,000以上のウェブサイトがそのツールキットの利用を開始したが、彼にフィードバックやパッチを返したのは10人だけだった^[4]。リーナスの法則で「十分な目玉があれば、全てのバグは洗い出される」とは言われるが^[5]、十分な目がセキュリティバグに視点を向けてバグを改修することに貢献するとは限らない。

評価モデルと手法[編集]

いくつかのソフトウェアに対するセキュリティシステムの評価モデルと評価手法がある。

改修日数の計測[編集]

潜在的な脆弱性が発見された後、脆弱性を改修するまでが最も脆弱であると考えられている。脆弱性が発見されてから改修するまでの日数を測ることでセキュリティシステムを評価することができる。このような評価手法にはいくつかの指摘があり、全ての脆弱性は同等に危険なのではなく、多くの障害を素早く改修することが、オペレーティングシステムのアカウントを不正に取得したり改修することで非常に効果的な少しの障害を改修することより、必ずしも良いとは限らない^[2]。

ポアソン過程[編集]

ポアソン過程（英語版）はオープンソースとクローズドソースのソフトウェアの間でセキュリティ障害が発覚した割合を評価するために利用することができる。ポアソン過程において脆弱性の数をN_v、有償レビュー者数をN_pとする。障害を発見する無償レビュー者の割合はλ_v、障害を発見する有償レビュー者の割合はλ_pとなる。無償レビューグループが障害を発見する期待時間は1/(N_v λ_v)、有償レビューグループが障害を発見する期待時間は1/(N_v λ_v)となる^[2]。

モーニングスター・モデル[編集]

Morningstar, Inc.（英語版）が投資ファンドの格付け評価に使用しているような、様々の種類のオープンソースとクローズドソースのプロジェクトを星の数で比較することはプロジェクトのセキュリティ強度を分析することに利用することができる。十分に多いデータセットを用いて分析は1つのグループにおける全体の有効性の評価に用いられる。

そのような評価モデルとして以下の評価基準がある^[6]。

• 星1 - 脆弱性過多
• 星2 - 信頼性に問題
• 星3 - 最善のセキュリティ理念に準拠
• 星4 - 文書化された安全な開発スタイル
• 星5 - 独立したセキュリティレビュー通過

脚注[編集]