オープンソース ソフトウェア コンポーネントに関する企業の懸念事項を確認する

  • 8 分

最新のソフトウェア開発は、基本的にオープンソース コンポーネントに依存します。 この依存関係により、商用販売、内部使用、パブリック サービスのいずれに対しても、ソフトウェアを構築する組織に大きな懸念が生まれます。 オープンソースは大きな利点を提供しますが、組織は関連するリスクを理解して管理する必要があります。

基本的な課題

組織は、オープンソース ソフトウェアを導入する際に 重要なバランスを取る行為 に直面します。

開発者のニーズ: 開発者は、開発の高速化、最新のフレームワーク、実証済みのライブラリ、現代の開発プラクティスを可能にするオープンソース コンポーネントを自由に使用することを望んでいます。 オープンソースの使用を制限すると、生産性が低下し、開発者に不満が生じ、優秀なエンジニアの採用が困難になります。

組織のリスク: 無制限のオープンソース導入により、組織はセキュリティの脆弱性、法的負債、運用の中断、コンプライアンス違反にさらされる可能性があります。 企業は知的財産を保護し、セキュリティを維持し、運用の安定性を確保し、法的義務を遵守する必要があります。

解決策: 成功した組織は 、リスクを管理しながら開発者を支援する方法を見つけます。これにより、潜在的な問題を特定して軽減するガバナンス フレームワーク内でのオープンソースの使用が可能になります。

セキュリティに関する懸念事項

セキュリティ リスクは、オープンソース ソフトウェアに関する最も直接的で深刻な懸念事項を表します。

既知のセキュリティの脆弱性

オープンソース コンポーネントには、セキュリティの脆弱性が頻繁に含まれています。

  • 普及： セキュリティ研究者は毎年、オープンソースコンポーネントで数千の新しい脆弱性を発見しています。 国の脆弱性データベース (NVD) は、CVE 識別子を持つ脆弱性をカタログ化します。
  • 重大度の範囲: 脆弱性は、影響の少ない問題から、リモートでのコード実行、データの盗難、または完全なシステム侵害を可能にする重大な欠陥までさまざまです。
  • 開示のタイミング: 多くの場合、脆弱性は検出前に何年も存在します。 影響を受けるバージョンを使用するアプリケーションは、更新プログラムが適用されるまで脆弱なままです。
  • 推移的な依存関係: 脆弱性は、直接使用するパッケージではなく依存関係に存在し、検出がより困難になる可能性があります。

影響の例: 一般的な Java ログ ライブラリ Log4j の Log4Shell の脆弱性 (CVE-2021-44228) は、世界中の何百万ものアプリケーションに影響を与えました。 組織は、Log4j を使用してすべてのアプリケーションを特定し、パッチをデプロイし、単一のオープンソースの脆弱性が大規模な波及効果を与える可能性があることを示しました。

悪意のあるコード挿入

サプライ チェーン攻撃の対象となるオープンソース ソフトウェア:

  • パッケージハイジャック: 攻撃者は、一般的なパッケージメンテナ アカウントを制御し、資格情報を盗んだり、バックドアをインストールしたり、暗号通貨をマイニングしたりする悪意のある更新をプッシュします。
  • タイポスクワッティング: 有名なパッケージに似た名前を持つ悪意のあるパッケージが、開発者を騙し、悪質なコードをインストールさせます（例：「python-dateutil」と「python-datutil」）。
  • 依存関係の混乱: 攻撃者は、内部プライベート パッケージと一致する名前を持つパブリック レジストリに悪意のあるパッケージを発行し、パッケージ マネージャーの解決動作を悪用します。
  • メンテナーの侵害: 攻撃者は、フィッシング、資格情報の盗難、ソーシャル エンジニアリングを通じてメンテナー アカウントを侵害し、悪意のあるコードを信頼されたパッケージに挿入します。

インシデントの例: npm の eventstream パッケージは、暗号通貨ウォレットの資格情報を盗むために侵害されています。 Colors.js と Faker.js のメンテナーは、意図的に無限ループを追加して、財務サポートなしで企業の使用に抗議し、何千ものアプリケーションを壊しました。

メンテナンスされていないプロジェクトと破棄されたプロジェクト

多くのオープン ソース プロジェクトには、アクティブなメンテナンスがありません。

  • プロジェクトの破棄: 保守担当者は、関心を失ったり、ジョブを変更したり、プロジェクトの保守を続ける時間が不足したりします。 放棄されたプロジェクトは、脆弱性が検出された場合でもセキュリティ更新プログラムを受け取りません。
  • 単一の保守管理者のリスク: 多くの重要なオープンソース プロジェクトは、単一の個人に依存しています。 そのユーザーが利用できなくなった場合、プロジェクトは実質的に一晩中維持されなくなります。
  • 資金調達の課題: 多くの保守担当者が自発的に作業します。 資金がなければ、大規模なプロジェクトを維持することは持続不可能になり、最終的な放棄につながります。
  • メンテナンスのラグ: アクティブなプロジェクトでも、セキュリティの問題に対する応答時間が遅くなり、パッチを待っている間にアプリケーションが脆弱になる可能性があります。

組織への影響: 保持されていないパッケージに依存する組織は、代替パッケージに切り替える (大幅なリファクタリングが必要)、パッケージ自体をフォークして維持する (メンテナンスの負担を増やす)、または脆弱なコードの使用を続ける (セキュリティ リスクを受け入れる) 必要があります。

品質と信頼性に関する懸念事項

セキュリティ以外にも、コード品質はアプリケーションの信頼性と保守容易性に影響します。

可変コード品質

オープンソース コンポーネントの品質は大きく異なります。

  • 品質基準の欠如: オープンソース プロジェクトには、必須の品質要件はありません。 コードの品質は、保守担当者のスキル、プラクティス、優先順位に完全に依存します。
  • 制限付きテスト: 小規模なプロジェクトでは、自動化されたテストが最小限に抑えられるか、エッジ ケースのカバレッジが不十分であるか、継続的インテグレーションがない可能性があり、バグの可能性が高くなります。
  • ドキュメントのギャップ: ドキュメントが不十分な場合、コンポーネントの正しい使用が困難になり、統合エラーや誤用のリスクが高まります。
  • パフォーマンスの問題: コンポーネントは、パフォーマンス、スケーラビリティ、またはリソース効率のために最適化されず、アプリケーションのパフォーマンスに影響を与える可能性があります。

低品質コンポーネントの影響:

  • 保守性： コード構造が悪いと、デバッグとカスタマイズが困難になります。
  • 確実： テストが不十分な場合、アプリケーションエラーの原因となるバグが発生します。
  • パフォーマンス： 非効率的な実装は、アプリケーションの応答時間とリソースの使用状況に影響します。

互換性と安定性

オープン ソース コンポーネントでは、下位互換性が常に優先されるわけではありません。

  • 破壊的変更: メジャー バージョンの更新プログラムでは、アプリケーションの変更を必要とする重大な変更が頻繁に発生します。
  • API の不安定性: 若いプロジェクトでは、設計が成熟するにつれてインターフェイスが頻繁に変更される可能性があります。
  • 依存関係の競合: コンポーネントには、他のコンポーネントと競合する特定のバージョンの依存関係が必要になる場合があります。
  • プラットフォームの互換性: すべてのコンポーネントが、すべてのプラットフォーム、ブラウザー、または環境で動作するわけではありません。

オープンソース ライセンスは、組織が尊重する必要がある法的義務を作成します。

ライセンス コンプライアンスの義務

各オープン ソース ライセンスでは、次の要件が課されます。

  • コピーレフトの要件: 一部のライセンス (GPL など) では、派生物が同じライセンスを使用する必要があります。この場合、組織はオープンソースの専用コードを強制的に使用する可能性があります。
  • 属性の要件: ほとんどのライセンスでは、著作権表示とライセンス テキストを維持する必要があります。これは分散ソフトウェアに表示される必要があります。
  • ソース コードの開示: 特定のライセンスでは、バイナリを受け取るすべてのユーザーにソース コードを提供する必要があります。
  • 特許付与: 一部のライセンスには、組織の特許戦略と対話する特許付与または終了条項が含まれます。

コンプライアンスエラーが発生すると、次の結果が発生する可能性があります。

  • 訴追： 著作権者は、ライセンス違反を訴え、損害賠償と差し止めを求めることができます。
  • 評判の損傷: ライセンス違反は一般に公開され、開発者コミュニティの組織の評判を損ないます。
  • 配布の制限: 違反を解決するには、コンプライアンスが達成されるまで製品の配布を停止する必要があります。
  • 強制オープン ソーシング: 極端なケースでは、組織はコピーレフト ライセンスに違反するオープンソースの独自コードを要求される場合があります。

ライセンスの急増と互換性

最新のアプリケーションには、さまざまなライセンスを持つ何百ものコンポーネントが組み込まれています。

  • ライセンス インベントリ: 組織は、アプリケーション内のすべての依存関係に適用されるライセンスを追跡する必要があります。
  • 互換性分析: 一部のライセンスには互換性がありません。GPL のソフトウェアを特定の他のライセンスのソフトウェアと組み合わせることはできません。
  • ライセンス条項の解釈: 法務チームは、ライセンス条項を解釈し、特定のユース ケースの義務を決定する必要があります。
  • ライセンスの変更: プロジェクトの保守担当者は、バージョン間でライセンスを変更する場合があり、コンプライアンスの再評価が必要になります。

課題の規模: エンタープライズ アプリケーションは、20 から 40 個の異なるライセンスを持つ 500 から 1,000 個のオープンソース パッケージに推移的に依存する可能性があります。 コンプライアンスを手動で追跡することは実用的ではありません。自動化されたツールとプロセスが必要です。

運用上の懸念事項

セキュリティと法的リスクに加えて、オープンソースでは運用上の課題が発生します。

外部インフラストラクチャへの依存関係

オープンソース エコシステムは、パブリック インフラストラクチャに依存します。

  • レジストリの可用性: アプリケーションは、パブリック パッケージ レジストリ (npm、PyPI、NuGet) から依存関係をフェッチします。 レジストリの停止により、ビルドとデプロイが防止されます。
  • パッケージの削除: 作成者はパッケージの発行を取り消し、それらに依存するアプリケーションを中断できます。 "left-pad" インシデントは、小さな 11 行のパッケージを削除すると、何千もの JavaScript アプリケーションを壊したときのこのリスクを示しました。
  • 地理的アクセス: 一部の組織は、パブリック パッケージ レジストリへのアクセスが制限されたリージョンで動作します。
  • ネットワークの信頼性: 低速または信頼性の低いネットワーク接続は、ビルド時間に影響し、ビルドエラーの原因となる可能性があります。

軽減策には次のようなものがあります。

  • プライベート レジストリ: 組織の管理下にあるプライベート レジストリのパブリック パッケージをミラー化します。
  • ベンダー パッケージ: ビルド中に外部の依存関係を排除するために、ソース管理に依存関係を含めます。
  • キャッシュ： パッケージをキャッシュすることで、繰り返しのダウンロードを減らし、ビルドの信頼性を向上させます。

更新管理の負担

依存関係を最新の状態に保つには、継続的な作業が必要です。

  • 継続的な更新: 新しいパッケージ バージョンは常にリリースされます。 組織は、更新プログラムを評価し、互換性をテストし、変更を展開する必要があります。
  • セキュリティの緊急度: 重大なセキュリティの脆弱性には即時更新が必要で、計画された作業が中断される可能性があります。
  • 破壊的変更: 大規模な更新では、コードの変更が必要になる場合があります。メンテナンスの負担が増えます。
  • テスト要件: 依存関係の更新ごとに、何も中断しないように回帰テストが必要です。

体系的な更新プロセスがない場合:

  • 依存関係の誤差: アプリケーションは現在のバージョンに遅れ、技術的負債が蓄積されています。
  • セキュリティの公開: 修正プログラムが適用されていない脆弱性は引き続き悪用可能です。
  • 雪崩の更新: 更新を遅らせると、大規模なバックログが作成され、適用がますます困難になり、リスクが高まります。

自由度と制御のバランス

組織は、開発者のエンパワーメントとリスク管理のバランスを取る戦略を策定する必要があります。

ガバナンスアプローチ

成功した組織は、バランスの取れたガバナンスを実装します。

事前承認プロセス:

  • パッケージの評価: セキュリティチームと法務チームは、最初に使用する前にパッケージをレビューし、セキュリティ履歴、ライセンスの互換性、品質を評価します。
  • 承認済みパッケージ リスト: 開発者が自由に使用できる、事前に承認されたパッケージのキュレーションされたリストを維持します。
  • 例外プロセス: 開発者は、承認されたリストにないパッケージの承認を要求し、適切なチームによる評価を行うことができます。

自動スキャン:

  • 脆弱性スキャン: 既知の脆弱性の依存関係を自動的にスキャンし、開発者にすぐに警告します。
  • ライセンス検出: すべての依存関係のライセンスを特定し、互換性のない、またはライセンスに関するフラグを設定します。
  • 品質メトリック: 自動コード分析を使用して依存関係の品質を評価します。

開発者教育:

  • セキュリティの認識: 依存関係を選択するときにセキュリティを考慮するように開発者をトレーニングします。
  • ライセンスの理解: 開発者がさまざまなユース ケースに対するライセンスへの影響を理解するのに役立ちます。
  • ベスト プラクティス: オープンソース コンポーネントを評価するためのガイドラインを共有します。

継続的な監視:

  • 新しい脆弱性: 既存の依存関係で新しく開示された脆弱性を監視します。
  • ライセンスの変更: プロジェクトがライセンスを変更するタイミングを追跡します。
  • メンテナンスの状態: 依存関係が非メンテナンスになるタイミングを特定します。

オープンソースを公開している組織に関する懸念事項

独自のオープンソース ソフトウェアを公開する組織は、追加の課題に直面しています。

ビジネス モデルに関する考慮事項

オープンソース ソフトウェアを収益化するには、慎重な戦略が必要です。

  • オープン コア モデル: 独自の拡張機能やエンタープライズ機能を販売しながら、基本的な機能をオープンソースとして提供します。
  • サポートとサービス: オープンソースソフトウェアを自由に提供しますが、サポート契約、コンサルティング、トレーニングを販売します。
  • ホステッド サービス: ソフトウェアをオープンソースで提供しますが、マネージド ホスティング サービスを販売します。
  • デュアル ライセンス: オープンソース プロジェクトのオープンソース ライセンスと、専用ソフトウェアの商用ライセンスでソフトウェアを提供します。

コントリビューション管理

公開されたオープンソース プロジェクトは、外部からの投稿を受け取ります。

  • 投稿レビュー: 組織は、品質、セキュリティ、プロジェクトの方向性との整合に関するコミュニティの貢献を確認する必要があります。
  • 共同作成者ライセンス: 共同作成者が貢献に必要な権限を付与することを保証するプロセスを確立します。
  • メンテナー リソース: 問題への対応、pull request の確認、コミュニティの管理には専用のリソースが必要です。
  • 方向の競合: コミュニティの要望は組織の優先事項と競合し、管理する外交が必要になる可能性があります。

クローズド オープン ソースアプローチ: 一部の組織ではコードを公開しますが、変更できるユーザーを制限します。 コミュニティ メンバーは、問題やプル要求を通じて変更を提案できますが、変更をコミットできるのは組織の保守担当者だけです。 これにより、コードの品質と方向の制御を維持しながら、透明性が提供されます。

知的財産の保護

組織は、オープンソースの内容を慎重に検討する必要があります。

  • 競争上の優位性: 競争上の差別化を提供するオープン ソーシング コードは避けてください。
  • セキュリティに関する懸念事項: セキュリティ メカニズムや脆弱性を公開するコードは公開しないでください。
  • タイミングの決定: コードを最初は独自に保持し、後でオープンソースにしておくことが戦略的に有利な場合があります。
  • 特許に関する考慮事項: オープンソースライセンスに適切な特許付与または保護が含まれるようにします。

オープンソース ソフトウェアを効果的に実装するためには、これらの企業の懸念事項を理解することが不可欠です。 次のユニットでは、オープン ソース ライセンスについて詳しく説明し、さまざまなライセンスが作成する法的義務と、組織のライセンスへの影響を評価する方法を理解するのに役立ちます。