オープンソース・ソフトウェア (OSS)

オープンソース・ソフトウェアとクローズドソース・ソフトウェアの主な違い
オープンソースによって生じる可能性がある問題

オープンソース・ソフトウェアとは

オープンソース・ソフトウェアとクローズドソース・ソフトウェア（プロプライエタリ・ソフトウェア）のどちらを選択するかはさまざまな要因によって決まりますが、特に重要な2つの要因は、組織のリスク選好度と対象ソフトウェアに関する社内での専門知識の有無です。オープンソース・ソフトウェアかクローズドソース・ソフトウェアかを選択する際は、以下の事項を考慮してください。

通常、オープンソース・コードは公開リポジトリで共有されます。一般の利用者は設計、開発、ソフトウェアの機能強化に貢献することを奨励されます。OSSの一般的な例：

GNU/Linux
Mozilla Firefox
VLCメディア・プレーヤー
SugarCRM
GIMP
VNC
Apache Webサーバー
LibreOffice

オープンソース・ソフトウェアとクローズドソース・ソフトウェアの主な違い

要因	オープンソース	クローズドソース
価格	少額のライセンス料および使用料、または無償で利用可能。	ソフトウェアの規模に応じて価格が異なる。
カスタマイズの自由度	完全にカスタマイズ可能。ただし、オープンソースのライセンスに依存する。内製のための専門知識が必要。	ソフトウェアの販売元企業への変更依頼が必要。これにはバグ修正、機能の強化・拡張が含まれる。
ユーザビリティ	一般にユーザビリティは比較的低い。プロジェクトの目的や保守要員に依存するところが大きい。	一般にユーザビリティは比較的高い。営利目的の製品であるため、適合性やユーザーの操作性が重視されている場合が多い。
アフターサポート	特に広く利用されているオープンソース・ソフトウェア（Red HatやSUSE等のOSSディストリビューションなど）はサポートが充実している。それ以外のオープンソース・ソフトウェアについては、ユーザー・フォーラムやメーリングリストでヘルプが見つかる場合がある。	専門のサポート・チームが設けられている。サービスのレベルはサービスレベル合意書（SLA）によって決まる。
セキュリティ	誰でも自由にソースコードを見ることができる。コードを目にする人が多いほどバグが放置される可能性が低くなるという理論が広く普及しているが、セキュリティ上のバグや欠陥は残されたままで、重大なリスクにさらされている可能性もある。	ソフトウェアの提供元企業（ソフトウェア所有者）がSLAの条件に応じて一定レベルのサポートを保証する。ソースコードは見ることができないため、セキュリティの問題が存在する可能性がある。問題が見つかった場合は、ソフトウェアの提供元が修正の責任を負う。
ベンダーロックイン	コスト面でベンダーロックインは生じない。システムへの統合には技術面での依存性が生じる場合がある。	多くの場合、専有ソフトウェアには多額の投資が行われている。別のベンダーやオープンソース・ソリューションへの切り替えは高コストになる可能性がある。
安定性	現在のユーザー層、ソフトウェアの保守要員、市場に出てからの年数によって異なる。	発売されてから長い期間が経っているソリューションほど安定性が高い。新製品にはオープンソース製品と同様の課題がある。
普及度	一部のオープンソース・ソリューション（Linux、Apacheなど）は広く普及し、市場をリードしている。	業種によっては、専有ソフトウェア（特に発売されてから長年経っている製品）の方が広く利用されている。
総所有コスト（TCO）	使用コストが少額またはゼロであるため、TCOは低く、初期費用になる。必要な保守レベルによって異なる。	TCOははるかに大きく、ユーザー層の規模によって異なる。
コミュニティへの参加	オープンソースでは、開発、レビュー、批評、機能強化に参加するコミュニティの存在が重要。	クローズド・コミュニティ
他のオープンソース・ソフトウェアとの相互運用性	保守レベルとグループの目的によって異なる。一般にクローズドソース・ソフトウェアよりは相互運用性が高い。	開発標準によって異なる。
税金の計算	金額が不定なため困難。	明確
新機能の拡張	必要に応じてユーザーが開発できる。	ソフトウェア所有者への依頼が必要。
本番環境への適合性	OSSは技術的に大規模な本番環境で十分に設計またはテストされていない可能性があります。	多くの専有ソフトウェアは何度もテストを行っていますが、それでも本番環境にデプロイしたときに不具合が生じる場合があります。
金融機関での採用の検討	金融業界はオープンソース・ソリューションを敬遠する傾向がある。利用する場合は綿密な調査の実施が必要。	金融機関はプロプライエタリ・ソフトウェアを好む傾向がある。
保証	保証なし。	保証および賠償責任を規定するセキュリティ・ポリシーを定めている企業に最適。

オープンソースによって生じる可能性がある問題

オープンソース・ソフトウェアとクローズドソース・ソフトウェアのいずれにおいてもセキュリティは重要な考慮事項です。どちらがよりセキュアかについての議論が高まっていますが、一般に、プロプライエタリ・ソフトウェア製品を開発した企業はオープンソース・ソフトウェアの作成者よりも評判を意識する傾向があります。セキュリティの欠陥が明らかになった場合には自らが非難や批判を浴びます。OSSの場合、明確なソフトウェア所有者が存在せず、評判を維持する必要もなければ、責任の所在も明らかではありません。

誰もが見ることも使用することもできるオープンソース・ソフトウェアのソースコードは悪意のあるユーザーにも公開されています。一方、プロプライエタリ・ソフトウェアのコードは簡単には入手できないため、攻撃者にとってソフトウェアを参照してエクスプロイトすることは比較的困難です。

多くの専門家が、OSSはソースコードを自由に利用できることによってセキュリティが向上すると主張しています。多くの開発者がコードに携わるため、リーナスの法則に従って欠陥が捕捉され、解決される可能性が高いという主張です。さらに、企業や個人が有志でオープンソース製品の脆弱性をスキャンしてその結果を公開しています。

ところが近年、組織の資産を重大なリスクにさらすOSSの脆弱性（HeartbleedやShellShockなど）が見つかっています。こうしたリスクに対処するため、企業はOSSセキュリティ対策を講じる必要があります。この対策によりOSS固有のセキュリティ・リスクを防げるという一定の安心が得られます。

オープンソースのソフトウェア・セキュリティ対策をセキュアに実装するには、以下のベストプラクティスが有効です。

自社のセキュリティ・ポリシーの要件を満たすOSSの解析を実施する。
- 自社のセキュリティ・ポリシーにOSSが含まれていない場合はOSSも含める必要がある。
明確な責任の所在を含む、社内で使用しているOSSのリポジトリを作成し、管理する。
共通脆弱性識別子（CVE）やNIST脆弱性データベース（NVD）などの脆弱性情報を確実にリポジトリにマッピングし、最新情報を維持する。
社内で使用しているOSSを常に最新の状態に維持する。
OSSの開発や保守が終了した場合、またはOSSの更新が遅れている場合には、リスクを軽減または容認するプロセスを設ける。
現在使用しているすべてのOSSに対するセキュリティ評価を行う（ソフトウェア・コンポジション解析やファジングテストなどを用いる）。
- 社内にセキュリティ・エキスパートがいない場合は、ベンダーに評価を依頼。
プロジェクトに組み込まれる現行および将来のOSSに関するセキュリティ評価計画を策定する。