オープンソースソフトウェアに潜む5つのリスク

オープンソースソフトウェアを採用するメリットは明らかです。今や、アプリケーション開発プロセスに欠かせない要素となっています。

無料で利用できるライブラリ、フレームワーク、プロセスを活用すれば、アプリケーションスタック全体をゼロから開発する時間とコストを削減できます。開発を加速し、イノベーションを促進できます。

プロプライエタリソフトウェアとは異なり、オープンソースコードは難読化されていません。そのため、各社固有のビジネスニーズに合わせてコードベースを簡単に調整できます。さらに、誰でもコード内のバグを見つけ、問題の修正を提案できます。その結果、問題がより早く発見されることが多く、場合によっては、オープンソースソフトウェアのほうがプロプライエタリソフトウェアより堅牢で安全になることもあります。

オープンソースソフトウェアのリスク

ただし、スタックに追加するプロジェクトを選ぶ際には、オープンソースソフトウェアに伴うリスクも考慮する必要があります。

たとえば、成熟度の低さやドキュメント不足が原因で、導入や利用が難しいものもあります。また、堅牢性が十分でないために、ハードウェアとの互換性の問題が起きることもあります。技術的なサポートを受けるために、高額なサードパーティのサポートサービスへの加入が必要になる場合もあります。

この記事では、オープンソースソフトウェアを利用する際に特に注意すべき、重大なリスクをもたらす5つの領域を詳しく見ていきます。

1. ソフトウェアの品質

2. 長期的な持続可能性

3. ソフトウェアライセンス

4. 著作権侵害

5. ソフトウェアセキュリティ

1. ソフトウェアの品質

オープンソースプロジェクトは一般にコミュニティを中心に進められ、共同で参加する人々によってソフトウェアの開発、テスト、改善が行われます。そのため、プロプライエタリな代替製品より信頼性が高いと見なされることが少なくありません。

しかし、何事も保証されているわけではありません。特に、少数の参加者だけで保守されているプロジェクトには注意が必要です。

また、貢献者によって知識、スキル、経験は異なります。ほかの人ほど時間を割けない人もいます。リソースが不足しているプロジェクトでは、品質が低下するのは避けられません。

オープンソースプロジェクトを評価するには、保守状況やセキュリティなどの指標を確認する方法があります。こうした項目を評価し、類似するオープンソースプロジェクトを比較すれば、より適切な判断に役立ちます。100万件以上のオープンソースパッケージを網羅するSnyk Open Source Advisorを使えば、プロジェクトに最適なオープンソースパッケージを簡単に見つけて評価できます。

Snyk AdvisorのReactオープンソースパッケージの健全性概要

また、通常は何らかの保証が付く商用ソフトウェアとは異なり、性能を発揮できなかった場合に保護を提供するオープンソースライセンスはごくわずかです。

2. 長期的な持続可能性

オープンソースソフトウェアの多くは、少人数の貢献者によって開発されています。ボランティアである彼らは、フルタイムの仕事を続けながらプロジェクトを保守するプレッシャーにさらされることがよくあります。

その結果、貢献者が継続的に関わることが難しくなり、プロジェクトが停滞するオープンソース疲れに陥ることがあります。そして最終的には、完全に終了してしまうこともあります。

保守が終了したオープンソースコンポーネントに依存していると、脆弱性やその他のコード上の欠陥を自分たちで修正しなければならない可能性があります。プロジェクトがどのくらいの頻度で更新されているか、必ず確認しましょう。

3. ソフトウェアライセンス

オープンソースソフトウェアのほとんどは無料で利用できますが、ほぼすべてが何らかのライセンスの下で提供されています。

現在、OSI承認済みのオープンソースライセンスは100種類以上あります。そのため、複雑なアプリケーションスタックや開発環境では、多種多様なオープンソースライセンス契約が適用されることがあります。その中には、非常に複雑で細かな条件が定められたものもあります。

ソフトウェアライセンスの5つの種類

オープンソースライセンスは、大きく分けてパーミッシブライセンスとコピーレフトライセンスの2種類に分類されます。

• MIT Licenseなどのパーミッシブライセンスでは、一般にコードを自由に利用できます。また、元の開発者に謝辞を示せば、コードを自社のプロプライエタリアプリケーションに組み込み、派生ソフトウェアを配布することもできます。

• コピーレフトライセンスも、GNU General Public LicenseやServer Side Public License（SSPL）のように、コードを自由に変更できます。ただし、コードを転用して配布する場合は、新しいソースコードを自由に利用できるようにしなければなりません。コピーレフトライセンスのコンポーネントをプロプライエタリソフトウェアに組み込むと、ソフトウェアライセンスに準拠するために自社のコードを公開しなければならない場合があり、特に問題となることがあります。

ライセンスの問題を避ける方法のひとつは、承認済みのオープンソースコンポーネントのリストを作成し、システムで使用しているオープンソースソフトウェアの一覧を管理することです。オープンソースポリシーを策定することも、ライセンスのコンプライアンスを維持する方法のひとつです。

また、利用するオープンソースコンポーネントを決める前に、異なるアプリケーションやサービスの連携方法など、技術面の課題も十分に検討しましょう。アプリケーションを社内利用に限定していても、将来公開する可能性があることも念頭に置いてください。

4. 著作権侵害

オープンソース開発者の多くは趣味で活動しています。自分の判断に任されていることが多く、保護された知的財産という概念を理解していない、あるいは尊重していない場合もあります。

そのため、著作権侵害のリスクが生じます。経験不足や不注意のあるコーダーが、プロプライエタリコード（またはコピーレフトコード）をプロジェクトに混入させてしまう可能性があるためです。その結果、オープンソースライセンスでは、著作権やその他の知的財産権の侵害について責任を負いません。

法的措置やそれに伴う損害賠償請求のリスクを避けるため、オープンソースソフトウェアを採用する前に十分な調査を行いましょう。

5. ソフトウェアセキュリティ

オープンソースは、協業と透明性を特徴とするため、一般にプロプライエタリソフトウェアよりもソフトウェアセキュリティの評価が高い傾向にあります。

商用アプリケーションでセキュリティ上の欠陥が見つかった場合、ベンダーの対応を待たなければなりません。一方、オープンソースソフトウェアでは、すぐに修正に取りかかる人がいることも少なくありません。

しかし、必ずそうなるとは限りません。特に、小規模なプロジェクトでは注意が必要です。

さらに、オープンソースプロジェクトのほぼ半数では、いまだにセキュリティ監査の手順が整備されていません。

そのため、オープンソースコミュニティの誰もが常にプロジェクトを確認し、オープンソースのセキュリティ問題を探しているという考えに頼るべきではありません。

さらに、最新のソフトウェアアップデートやパッチ、未解決の脆弱性をすべて把握するのは簡単ではありません。

たとえば、Snykの脆弱性データベースなど、既知の脆弱性を扱うさまざまなデータベースのフィードを購読できます。しかし、National Vulnerability Database（NVD）のような最大規模で網羅性の高いサービスでさえ、報告されたすべての問題を掲載しているわけではありません。

また、これらのサービスでは通常、オープンソース開発者が脆弱性について検討し、修正してテストする時間を確保するため、更新の公開が数週間保留されることにも注意が必要です。

この方法には妥当性があるものの、内部情報を知るハッカーに攻撃を計画して実行する時間を与えてしまいます。脆弱性の通知を受け取っても、パッチの適用が遅れるユーザーもいれば、さらに深刻なことに、影響を受けるコンポーネントを使っていること自体を把握していないユーザーもいます。

先手を打つ

オープンソースソフトウェアには広く認められたメリットがありますが、組織に適したソリューションを選ぶには、事前に十分な調査が必要です。

導入環境の管理に役立つツールも必要です。オープンソースの利用状況を明確に把握できるツールを選びましょう。そうすれば、アプリケーションで使用しているすべてのフレームワークやライブラリを追跡し、オープンソースライセンスの要件への準拠を維持できます。

攻撃者に悪用される前にオープンソースの脆弱性を早期に検出できるなど、アプリケーションセキュリティを継続的に確保できるソリューションも探しましょう。

オープンソースの利用を慎重に管理し、セキュリティや法務上の潜在的な問題に特に注意を払うことで、後々高額な問題が発生するリスクを最小限に抑えながら、オープンソースモデルのメリットを最大限に活用できます。

ただし、自動化されたセキュリティとガバナンスのツールがなければ、ライセンスへの準拠や最新のパッケージ脆弱性を把握するために、多くの作業を手動で行わなければなりません。