オープンソースシステムとクローズドソースシステム

Question

オープンソースシステムは一般的にクローズドソースシステムよりも安全であると考えられています。

いずれかのアプローチまたはそれらの組み合わせを採用する理由には、文化的基準、財政的、法的位置づけ、国家安全保障などが含まれます。これらすべては、そのシステムをオープンソースまたはクローズドソースにすることの影響に関する文化の見方に何らかの形で関連しています。

中心的な懸念の1つはセキュリティです。オープンソースシステムに対する一般的な立場は、攻撃者がシステム内の既知の弱点を悪用する可能性があることです。クローズドソースシステムに対する一般的な立場は、認識不足はせいぜい弱いセキュリティ対策であるということです。一般にあいまいさによるセキュリティと呼ばれます。

問題は、オープンソースシステムは、クローズドソースシステムよりも平均してセキュリティが優れているということです。可能であれば、可能な限り多くの業界の分析を引用してください。例：ソフトウェア、軍事、金融市場など.

この質問はITセキュリティの今週の質問でした。
詳細については、2012年5月25日 ブログエントリ をお読みください。または 自分で送信 今週の質問。

Jesper M · Accepted Answer

オープンソースソフトウェアはクローズドソースソフトウェアよりも本質的に安全であるという概念-または反対の概念-はナンセンスですそして、人々がそのようなことを言うときそれはしばしば [〜＃〜] fud [〜＃〜] であり、議論を有意義に進めるものではありません。

これについて推論するには議論を特定のプロジェクトに制限する必要があります。特定のかゆみをひっかき、指定されたチームによって作成され、明確に定義された対象者がいるソフトウェア。このような特定のケースでは、オープンソースとクローズドソースのどちらがプロジェクトに最適かを判断できる場合があります。

すべての「オープンソース」実装とすべての「クローズドソース」実装のピッチングの問題は、ライセンスを比較するだけではないことです。実際には、オープンソースはボランティアの努力によって支持され、クローズドソースは商業的努力において最も一般的です。だから私たちは実際に比較しています：

ライセンス。
ソースコードへのアクセス。
非常に異なるインセンティブ構造、営利と娯楽。
非常に異なる法的責任の状況。
チームサイズとチームスキルセットが大きく異なります。
等.

オープンソース/クローズドソースが機能しなくなったときにリリースされたすべてのソフトウェアで、セキュリティのためにこれがどのように機能するかを判断することを試みます。それは事実ではなく意見の表明になります。

Thomas Pornin · Answer

維持されているソフトウェアは、そうでないソフトウェアよりも安全です。もちろん、メンテナンスの労力は、ソフトウェアの複雑さと、それを見る人の数（およびスキル）に関連しています。より安全なオープンソースシステムの背後にある理論は、ソースコードを見る「多くの目」があるということです。しかし、これはシステムの人気にかなり依存します。

たとえば、2008年にOpenSSLで発見されましたいくつかのバッファオーバーフロー、その一部はリモートコードの実行につながります。これらのバグは数年間コードに潜んでいた。したがって、OpenSSLはオープンソースであり、はかなりのユーザーベース（これは、結局のところ、HTTPS Webサイトで使用されるメインSSLライブラリです）でしたが、ソースコード監査の数と巧妙さはASN.1デコード（バグが潜んでいたOpenSSLの一部）およびOpenSSLソースコード（正直なところ、これはこれまでで最も読みやすいCソースコードではありません）の固有の複雑さを克服するのに十分です。

クローズドソースシステムでは、平均してQ＆Aを行う人がはるかに少なくなります。ただし、多くのクローズドソースシステムにはpaidの開発者とテスターがいて、フルタイムでジョブにコミットできます。これは、オープン/クローズの質問に固有のものではありません。一部の企業は、オープンソースシステムを開発するために人材を雇用しており、おそらく、無料でクローズドソースソフトウェアを作成できます（これは、Windowsの「フリーウェア」の場合は比較的一般的です）。ただし、有料のテスターがいることとクローズドソースであることの間には依然として強い相関関係があります（相関関係は因果関係を意味するものではありませんが、相関関係を無視する必要があるという意味でもありません）。

一方、クローズドソースであることで、セキュリティの問題を隠しやすくなります。もちろん、badです。

オープンソースシステムとクローズドソースシステムの両方の例があり、セキュリティの問題が多数またはほとんどありません。オープンソースの* BSDオペレーティングシステム（ FreeBSD 、 NetBSD および OpenBSD 、およびその他いくつか）は、セキュリティに関して非常に優れた実績があります。 Solarisも同様に、クローズドソースのオペレーティングシステムでした。その一方で、Windowsはその点でひどい評判を持っています。

要約：私の意見では、「オープンソースはセキュリティを暗示する」という考えは過大評価されています。重要なのは、セキュリティ問題の追跡と修正に費やす時間（およびスキル）です。これは、ソースの公開性の問題とほとんど関係がありません。 ただし、安全なシステムが必要なだけでなく、確実に知っているシステムが安全である（侵入されない）ことも必要です。重要ですが、夜も寝ることができます）。その役割については、オープンソースシステムにはわずかな利点があります。システムがオープンソースの場合、故意に隠されたセキュリティホールはないと確信しやすくなります。しかし、最近の悲劇 OpenBSDの申し立てられたバックドア（私が知る限り、それは赤いニシンであることが判明しましたが、私は自分でコードを確認しない限り、確認してください）。

user2213 · Answer

これに対する最も簡単で単純な見方は、ソフトウェアエンジニアリングに関するものだと思います。引数は通常次のようになります：オープンソースソフトウェアはソースを表示できるため、より安全です！

カーネルをトップダウンで理解するためのソフトウェアエンジニアリングの知識はありますか？確かに、そのようなドライバーを見ることができますが、実際に「ああ、そうです、そこにバグがあるに違いありません」と言われていることについて完全な知識がありますか？

ここに興味深い例があります：少し前に、nrポインター逆参照のバグがベータカーネルの1つに現れましたが、それはgrsecurity（PaXパッチ）の人によって発見されたかなり大きなものでした。

次のようなコードで導入されました。

pointer = struct->otherptr; if ( pointer == NULL ) { /* error handling */ } /* code continues, dereferencing that pointer which with the check optimised out, can be NULL. Problem. */

そしてその pointer == NULLチェックはコンパイラによって正しく最適化されました-nullポインタはメンバーを含む構造体に逆参照できないため、関数内のポインタがnullであっても意味がありません。その後、コンパイラーは、開発者がそこにいると期待しているチェックを削除します。

Ergo、vis、vis、concorantly、そのような大規模プロジェクトのソースコードは正しいように見えるかもしれませんが、実際には正しくありません。

ここで必要な知識のレベルが問題です。 C、Assembly、特定のカーネルサブシステム、カーネルの開発に伴うすべてにかなり精通している必要があるだけでなく、コンパイラの動作を理解する必要もあります。

誤解しないでください。十分な目で、すべてのバグは浅いというライナスに同意します。問題は目の後ろの脳の知識です。製品を開発するために30 Whの子供を払っているが、オープンソースプロジェクトにコードベースの真の知識がある5人しかいない場合、比較的類似した複雑さを前提として、クローズドソースバージョンの方がバグが少ない可能性が高いことは明らかです。。

明らかに、これは、Thomas Porninが議論しているように、時間の経過とともに一時的に発生する特定のプロジェクトにも当てはまります。

Updategccへの参照を削除するように編集しました。

Ori · Answer

クローズドソースとオープンソースを区別するためにほとんどの場合使用される前提はかなり明確に定義されていると思います。それらの多くはここにリストされており、どちらにも支持者がいます。当然のことながら、クローズドソースの支持者はそれを販売するものです。オープンソースの支持者たちはまた、それを素敵で整然としたビジネスにしました（それを宗教として引き継いだいくつかの人を超えて）。

プロオープンソースムーブメントは基本を語り、セキュリティ全般に関しては、ここで最も議論に当てはまるポイントを示します。

カスタマイズ前提
ライセンス管理の前提
オープンフォーマットの前提
多くの目の前提
クイックフィックスの前提

したがって、これを前提ごとに分解すると、最後の2つはここでは他の人たちによってかなり簡潔にカバーされていると思うので、それらはそのままにしておきます。

カスタマイズの前提
セキュリティに適用されるため、Customization Premiseは、ソフトウェアを導入する企業に、ライセンスを保護したり、ベンダーに何かを修正するように説得したりすることなく、既存のプラットフォームにセキュリティコントロールを追加することができます追加彼らのもの。製品の全体的なセキュリティを強化するために、またはギャップを見つける必要がある組織に力を与えます。 SELinuxは完璧な例です。コミュニティに還元してくれたNSAに感謝します。
ライセンス管理前提
多くの場合、F/OSSテクノロジーを使用する場合、サードパーティとテクノロジーライセンスを管理する必要がない（または管理する場合ははるかに少ない）と言われていますが、これは完全にオープンな場合にも当てはまります。ソース生態系。しかし、多くのライセンス（特にGPL）はディストリビューターに要件を課しており、ほとんどの実際の環境は、クローズドソーステクノロジーとオープンソーステクノロジーの異種混合です。したがって、最終的にはソフトウェアの支出を削減できますが、ソースの可用性により、一部の企業はソースをリリースする義務があるときにソースを非公開にすることでOSSライセンスに違反する可能性があります。これは最終的にライセンス管理前提を責任に変える可能性があります（これはクローズドソースの引数against GPLのようなライセンスです）。
オープンフォーマットの前提
これは大きな問題であり、同意する傾向があるため、説教しないように短くしておきます。 30年後、書いたファイルを開けるようになりたい。独自のDRMコントロールを使用してファイルが「保護」されていて、アクセスする必要があるソフトウェアが販売されなくなった場合、自分自身のコンテンツへのアクセスの難しさが劇的に高まりました。オープンで、30年前のオープンソース製品で使用できる私のドキュメントの作成に使用される形式がある場合、それを見つけて合法的に使用できる可能性があります。一部の企業は、オープンソースバンドワゴンにジャンプせずに「オープンフォーマット」バンドワゴンにジャンプしているので、この議論はかなり健全なものだと思います。

Sixth十分に議論されていないため、リストに記載しなかったという前提があります。私はそれに夢中になる傾向があります（パラノイアと呼んでいます）。6つ目の前提は、世界中の防衛部門のキャップの羽毛だと思います。 Windows 2000のソースの一部が漏えいしたとき、それは世界中に広められました。

クローズドソースの責任の前提
企業が数十年にわたる複数のリリースを通じてクローズドソースコードライブラリまたはAPIを作成していた場合、個人の小さなグループが、その作成全体を通じてそのソースにアクセスできました。これらの一部は、サードパーティの監査グループ、および他の会社/政府に移った開発者です。そのコードが十分に静的である場合、クローズドソースの利点の前提と同様に互換性を維持するため、いくつかの弱点は何年にもわたって発表されない可能性があります。そのクローズドソースにアクセスできる人は、コード分析ツールを自由に実行してこれらの弱点を調査できます。これらのソフトウェア開発ショップのバグリポジトリには、悪用につながる可能性のある「マイナー」バグがたくさんあります。この情報はすべて、多くの内部の個人が利用できます。

攻撃者はこれを知っており、この情報を自分自身に求めます。これは、あなたがこれらのショップの1つである場合、会社の内部インフラストラクチャに大きなターゲットを設定します。そして現状では、開発プロセスはセキュリティ責任になります。会社が十分に大きく、コードベースが十分に分散している場合は、人間の侵入活動のターゲットになることさえできます。この時点で、チャーリーミラーの手法：開発者に十分なお金を賄賂として渡すと、検出できないバグが発生する可能性が明らかになります。

これは、同じ方法でOSS製品に採用されないという意味でもありません。それは、あなたが一連のデータを持っていることを意味し、リリースされると、インストールベースの弱点を露呈する可能性があります。非公開にすると、顧客がインストールしたシステムに対して、すぐに返済できないコーディング上の負債が生じます。

Bruce Ediger · Answer

次の論文をご覧ください。

要するに、オープンまたはクローズは、それらに対して行われるテストの量に応じてほぼ同等であるということです。「テスト」とは、平均的な企業向けドローンの「テスター」が何をするかということではなく、むしろ現場での経験に似ています。

knocte · Answer

ここで正直に言いましょう。誰かがオープンソースがクローズドソースよりも安全であると主張するとき、彼らはLinux（オープンソース）とMac/Windows（独自のクローズドソース）のようなサーバー/デスクトップオペレーティングシステムで今日何が起こっているかについて一般化しています。

マルウェアが前者ではなく後者に影響を与える可能性が高いのはなぜですか？いくつかの理由により、最も重要なのは最初の理由です（---から借用この問題の重複としてマークされた質問に対するこの他の回答）：

Linuxディストリビューション（または他のオープンソースOS）の場合にユーザーがインストールするソフトウェアは、通常中央組織によってパッケージ化されます（つまり、 Ubuntuの場合、それはCanonicalによって行われ、それによってホストされます）、オープンソースコミュニティによってキュレーション/監視されたソースからコンパイルされたバイナリをホストします。つまり、ユーザーが感染したソフトウェアをインストールする可能性、またはオープンソースコミュニティが悪意のあるコードの変更を受け入れる可能性は、ユーザーが通常ウェブ上のさまざまな場所からソフトウェアをインストールするMac/Windowsの場合よりもはるかに低いということです、またはAppStoresのさまざまなベンダーから提供されています。また、組織のサーバー（Canonicalなど）がハッキングされるリスクもありますが、これらの組織はサーバーの実行に一流のITエキスパートを採用しているため、このリスクはわずかです。
Linux（または他のオープンソースOS）のユーザー数はWindows/Macユーザーよりもはるかに少ないため、マルウェアの作成者はそれらをターゲットにしないことを好む（利点として） /この場合、コスト比は低くなります）。
Linuxは単なるカーネルであるため、さまざまな異なるディストリビューションから選択でき、マルウェア作成者は悪意のあるコードを作成するために多大な労力を費やす必要がありますそれらの多くと互換性がある（したがって、この場合、利益/コスト比は低くなります）。
Linux（またはその他のオープンソースOS）のソースは、誰でも閲覧/変更できます。つまり、セキュリティの脆弱性が見つかった場合、誰でもその修正を作成できます（ベンダーロックインがなく、修正を開発するために待つ必要のある特定の組織に縛られていません）。したがって、理論的にはセキュリティパッチは、専用ソフトウェアの場合よりも早く発生します。（ただし、実際には、違いはありません。WindowsやMacOSなどの独自のプラットフォームを実行している企業は、たまたま十分な能力を備えた大企業であるためです。）

Geremia · Answer

Jim FruchtermanのOpenSource.comの記事「オープンソースのセキュリティソフトウェアは安全性が低いですか？」は、攻撃者がどのように動作するかを知っているにもかかわらず、オープンソースがエンドユーザーにとってソフトウェアをより安全にする方法と非常によく似ています。：

暗号化は、データに対して安全なロックされた組み合わせと考えてください。あなたはその組み合わせを持っている唯一の人かもしれませんし、あなたはそれをいくつかの近い仲間を選ぶように委託するかもしれません。安全の目的は、権限のない人がコンテンツにアクセスできないようにすることです。彼らは、貴重なビジネス情報を盗もうとする強盗、同僚に関する機密の給与情報を学ぼうとする従業員、または詐欺を実行するために機密情報を取得したい詐欺師かもしれません。すべての場合において、あなたは安全にあなたの物を安全に保ち、許可されていない人を入れないようにします。

さて、貴重品の金庫を選んでいるとしましょう。 1/2インチの鋼鉄の壁、1インチの厚さのドア、6つのロックボルトが付いていると宣伝され、内容が火災の中で2時間存続することを確認するために独立機関によってテストされたSafe Number Oneを選択しますか？または、金庫の設計の詳細は企業秘密であるため、ベンダーが単に信頼すると言っている金庫である金庫番号2を選択しますか？それは安全かもしれません2は合板と薄い板金でできています。または、セーフナンバーワンよりも強いかもしれませんが、要点はわかりません。

Safe Number Oneの詳細な計画と仕様があり、適切な材料とツールがあれば、その金庫の正確なコピーを作成するのに十分だと想像してください。 Safe Number Oneの安全性は低下しますか？いいえ、違います。 Safe Number Oneのセキュリティは、デザインの強さと私の組み合わせを推測する難しさの2つの保護にかかっています。詳細な計画を立てることは、私または安全な専門家がデザインがどれほど優れているかを判断するのに役立ちます。これは、金庫に設計上の欠陥がないこと、または金庫を開ける私が選択した組み合わせ以外の2番目の「バックドア」の組み合わせがないことを確認するのに役立ちます。優れた安全設計により、ユーザーは自分の組み合わせをランダムに選択できることに注意してください。設計を知ることは、攻撃者がその設計を使用する特定の金庫のランダムな組み合わせを推測するのをまったく助けるべきではありません。