まとめ
このモジュールでは、最新のソフトウェア開発がオープンソース コンポーネントにどのように依存しているかを調べ、関連するセキュリティ、法的、運用上のリスクを管理しながらオープンソース ソフトウェアを実装するための戦略について学習しました。 これらの概念を理解することで、オープンソースの利点を活用しながら、潜在的な負債から組織を保護することができます。
最新のソフトウェアの構築方法
現代のアプリケーションは、完全にゼロから構築されるのではなく、コンポーネントから組み立てられていることを学習しました。
- コンポーネントの構成: 最新のアプリケーションは、プロジェクトの外部に保持されている約 80% の既存のコンポーネントで構成され、元のビジネス ロジック コードである% は 20 個のみです。
- オープン ソースとクローズド ソース: オープン ソース コンポーネントは、誰でも検査、変更、配布できる一般に利用可能なソース コードを提供しますが、クローズド ソース コンポーネントはソース アクセスなしでバイナリのみを配布します。
- パッケージ エコシステム: コンポーネントは、依存関係管理を自動化する npm、PyPI、NuGet、Maven Central などのパッケージ マネージャーを通じて配布されます。
- コンポーネント ベースの開発の利点: 実証済みのコンポーネントを再利用すると、開発が促進され、コミュニティ審査によって品質が向上し、ライセンス料金を回避してコストが削減され、最先端のイノベーションにアクセスできるようになります。
- 開発速度: オープンソース コンポーネントを使用すると、チームが共通のインフラストラクチャを再構築するのではなく、独自のビジネス価値に集中できるため、市場投入までの時間が大幅に短縮されます。
オープンソース ソフトウェアに関する企業の懸念
あなたは、オープンソース コンポーネントを導入する際に 組織が直面する重大なリスク を調べました。
セキュリティに関する懸念事項:
- 既知の脆弱性: オープンソース コンポーネントでは、毎年何千ものセキュリティ脆弱性が発見されており、継続的な監視と迅速なパッチ適用が必要です。
- サプライ チェーン攻撃: 攻撃者は、パッケージの保守担当者アカウントを侵害したり、入力ミスを使用したり、依存関係の混乱を悪用して悪意のあるコードを挿入したりします。
- メンテナンスされていないプロジェクト: 多くのオープンソース プロジェクトではアクティブなメンテナンスが不足しているため、保守担当者がプロジェクトを中止したときに脆弱性の修正プログラムが適用されません。
品質と信頼性に関する懸念事項:
- 可変品質: オープンソースコンポーネントは、専門的に保守されたプロジェクトから、十分にテストされていない趣味のコードまで多岐に分けられます。
- 破壊的変更: コンポーネントは常に下位互換性に優先順位を付けるとは限らないので、更新時にコードを変更する必要があります。
- ドキュメントのギャップ: ドキュメントが不十分な場合、統合エラーと誤用が増加します。
法的およびライセンスに関する懸念事項:
- ライセンス コンプライアンスの義務: 各オープンソース ライセンスでは、単純な属性から、派生物の必須のオープンソース化に至るまでの要件が課されます。
- コピーレフト伝達: GPL のような強力なコピーレフト ライセンスでは、慎重に管理されていない場合は、アプリケーション全体をオープンソース化する必要があります。
- ライセンスの急増: アプリケーションは、数十の異なるライセンスを持つ数百のパッケージに依存し、複雑なコンプライアンスの負担を生み出す可能性があります。
運用上の懸念事項:
- 外部インフラストラクチャの依存関係: アプリケーションは、障害やパッケージの削除が発生する可能性があるパブリック パッケージ レジストリに依存します。
- 更新管理の負担: 依存関係を最新の状態に保つには、継続的な作業、テスト、デプロイが必要です。
オープンソース ソフトウェアとは
オープンソース ソフトウェアの基本的な特性を学習しました。
- 定義： オープンソース ライセンスの対象となる、検査、変更、配布のためにソース コードが公開されているソフトウェア。
- コラボレーション開発: オープンソース プロジェクトには、世界中の分散コントリビューターが参加し、パブリック リポジトリで開発が透過的に行われています。
- 広範な導入: 90 を超える% の企業が、運用環境でオープンソース ソフトウェアを使用し、オープンソース テクノロジはインターネット インフラストラクチャ、クラウド プラットフォーム、モバイル デバイスに電力を供給しています。
- Microsoft の変換: Microsoft は、オープンソースを脅威として見ることから、それを包括的に受け入れ、.NET をオープンソース化し、Linux と Kubernetes に貢献し、Visual Studio Code や TypeScript などの一般的なオープンソース ツールを作成することに移行しました。
- 戦略的根拠: 組織は、コスト削減、柔軟性と制御、コード検査による透明性とセキュリティ、ベンダーのロックインの回避、コミュニティサポート、イノベーションへの早期アクセスのためにオープンソースを選択します。
オープン ソース ライセンスの基礎
オープンソース ライセンスがソフトウェアの使用を管理する方法について説明しました。
ライセンスの目的:
- アクセス許可を定義します。 ライセンスは、著作権法によって禁止されるソフトウェアの使用、変更、配布を行う権利を付与します。
- 義務を課す: ライセンスには、属性、ソース コードの開示、ライセンスの保持、場合によってはコピーレフト コンプライアンスが必要です。
- 責任を放棄する: 作成者は損害に対して責任を負わず、ソフトウェアは保証なしで「現状のまま」提供されます。
オープン ソース定義の条件:
- 無料再配布: ソフトウェアの販売または提供に関する制限はありません。
- ソース コードの可用性: 変更するには、優先フォームにソースを含める必要があります。
- 許可される派生作品: 変更および派生的な作業を許可する必要があります。
- 差別なし: 人、グループ、または努力の分野を区別することはできません。
- テクノロジに依存しない: 特定のテクノロジまたはインターフェイスを必要とすることはできません。
ライセンス カテゴリ:
- 制限付きライセンス: 最小限の制限 (MIT、Apache 2.0、BSD) を使用して、独自のソフトウェアにコードを組み込むことを許可します。
- コピーレフト ライセンス: 同じライセンスを使用するために派生製品を要求し、ソフトウェアがオープンソース (GPL、AGPL) のままであることを確認します。
- 弱いコピーレフト ライセンス: コンポーネントにオープン ソーシングの変更を必要としますが、独自の使用 (LGPL、MPL) を許可します。
一般的なオープンソース ライセンス
人気のあるライセンスとその主な特性を調べました。
制限付きライセンス:
- MIT ライセンス: 属性のみを必要とする最も制限の少ないライセンスで、導入と商用使用を最大化します。
- Apache License 2.0: 明示的な特許付与と防御的終了を伴う許容ライセンス。特許を明確にします。
- BSD ライセンス: MIT と同様に、3条項BSDでは名称使用制限が商標保護のために追加されています。
強力なコピーレフト ライセンス:
- GPL v2 と v3: 派生物を GPL ライセンスにし、バイナリを使用してソース コードを配布する必要があります。GPL v3 は、特許保護と国際互換性の向上を追加します。
- AGPL: SaaS オファリングのソース開示を必要とするネットワーク使用プロビジョニングで GPL v3 を拡張します。
弱いコピーレフト ライセンス:
- LGPL: ライブラリ自体をオープンソースに変更する必要がある場合に、独自のアプリケーションからライブラリにリンクできるようにします。
- MPL 2.0: ファイル レベルのコピーレフトを提供します。同じアプリケーション内の独自のコードではなく、MPL ライセンスファイルに対してのみソースを開示する必要があります。
ライセンスの互換性:
- 互換性のある組み合わせ: MIT + Apache 2.0、MIT + GPL v3、Apache 2.0 + GPL v3、LGPL + GPL。
- 互換性のない組み合わせ: GPL v2 + Apache 2.0、GPL + 専用、異なるコピーレフト ライセンスの組み合わせ。
ライセンスへの影響とリスク評価
ライセンス リスクを評価し、コンプライアンスを実装する方法について学習しました。
ライセンス リスク フレームワーク:
- 低リスク (緑): MIT、BSD、Apache 2.0 などの制限の緩やかなライセンスは、あらゆる商用使用に対して安全です。
- 中程度のリスク (黄色): LGPLのような弱いコピーレフトライセンス、MPLは、変更の制限を伴う独自の使用を可能にします。
- 高リスク (赤): GPL、AGPL などの強力なコピーレフト ライセンスは、独自のソフトウェア配布と互換性がありません。
- 不明なリスク (オレンジ): カスタム ライセンスまたは不明確なライセンスでは、使用前に法的レビューが必要です。
商用ソフトウェアへの影響:
- パーミッシブライセンス: 帰属要件のみで独自の配布を可能にします。
- 弱いコピーレフト: 独自のアプリケーションでライブラリを使用できますが、ライブラリに対するオープン ソーシングの変更が必要です。
- 強力なコピーレフト: オープンソースの派生製品が必要で、独自のソフトウェアと互換性がありません。
知的財産に関する考慮事項:
- 独自の IP 保護: 制限の緩やかなライセンスは、独自のコードを保持します。コピーレフト ライセンスには開示が必要です。
- 特許条項: Apache 2.0 および GPL v3 には、明示的な特許付与が含まれています。MIT/BSD は特許の明確さを欠いています。
- 営業秘密の損失: ソース コードの開示により、企業秘密の保護が排除されます。
コンプライアンスの実装:
- 依存関係インベントリ: すべてのオープンソース コンポーネントとバージョンを追跡する包括的な部品表を維持します。
- ライセンス互換性の検証: 自動ツールを使用して、ライセンスの非互換性を特定します。
- 属性のコンプライアンス: ライセンス集約ファイルを生成し、[About] ダイアログに含め、ドキュメントで管理する。
- ソース コードのプロビジョニング: コピーレフト ライセンスの場合は、ビルド手順を含む完全なソース コードを提供します。
ソフトウェア サプライ チェーンのセキュリティ:
- 脆弱性スキャン: Snyk、Dependabot、WhiteSource などのツールを使用して、既知の脆弱性の依存関係を継続的にスキャンします。
- サプライ チェーン攻撃の軽減策: パッケージ署名の確認、信頼できるソースの優先、プライベート レジストリの使用、依存関係のバージョンのピン留め。
- 品質評価: メンテナンスの状態、コミュニティ サイズ、ドキュメントの品質、セキュリティプラクティスを評価します。
組織のポリシー:
- 承認ワークフロー: 新しい依存関係を導入する前に、セキュリティ、ライセンス、品質の事前使用評価を実装します。
- 承認済みパッケージ リスト: 開発者がすぐに使用できる事前審査済みコンポーネントのキュレーションされたリストを維持します。
- 開発者教育: ライセンスへの影響、セキュリティ プラクティス、コンプライアンス プロセスについて開発者をトレーニングします。
- 継続的な監視: 依存関係の更新、ライセンスの変更、脆弱性の漏えいを追跡します。
重要なポイント
組織でオープンソース ソフトウェアを実装するときは、次の重要な原則を覚えておいてください。
オープンソースを戦略的に受け入れる: オープンソースは、開発速度、品質、コスト削減、イノベーションへのアクセスなど、大きな利点を提供します。 リスクのためにオープンソースを回避するのではなく、安全な導入を可能にするガバナンス プロセスを実装します。
依存関係を把握する: 推移的な依存関係を含むすべてのオープンソース コンポーネントの包括的なインベントリを維持します。 知らないリスクを管理することはできないため、依存関係の可視性は、効果的なオープンソース管理の基礎となります。
ライセンスへの影響を理解する: ライセンスが異なると、商用ソフトウェアに対する影響が大幅に異なります。 MIT のような制限の緩いライセンスは、独自のソフトウェアに対して安全です。GPL のようなコピーレフト ライセンスには、オープンソースの派生物が必要です。 ライセンスの選択をビジネス モデルと一致させます。
ライセンスの互換性を評価する: さまざまなコンポーネントのライセンスを法的に組み合わせることができることを確認します。 互換性のないライセンスでは、コンポーネントの交換やコードの書き換えなど、コストのかかる修復が必要な法的問題が発生する可能性があります。
自動化されたコンプライアンスを実装する: 手動ライセンス追跡は、何百もの依存関係を持つ最新のアプリケーションにはスケーリングされません。 依存関係のスキャン、ライセンス検出、脆弱性の監視に自動化されたツールを使用します。
セキュリティに優先順位を付けます。 依存関係のセキュリティの脆弱性は、発生元に関係なくアプリケーションに影響します。 継続的な脆弱性スキャンを実装し、重要なセキュリティ パッチの迅速な更新プロセスを確立します。
サプライ チェーンのリスクを管理する: 既知の脆弱性を超えて、パッケージ検証、ソース評判評価、プライベート レジストリ、依存関係のピン留めによって、サプライ チェーン攻撃から保護します。
コントロールと自由のバランスを取る: 開発者は、最新のツールとフレームワークを自由に使用する必要があります。 オープンソースの導入をブロックするのではなく、承認ワークフローと、安全な使用を可能にする承認済みパッケージ リストを実装します。
チームを教育する: ライセンスとセキュリティに関する懸念に対する開発者の認識は不可欠です。 トレーニング プログラムは、開発者がコンポーネントの選択に関して適切な意思決定を行い、組織のポリシーを理解するのに役立ちます。
継続的に監視する: オープン ソース管理は 1 回限りではありません。 新しい脆弱性は常に開示され、ライセンスが変更されることがあり、プロジェクトは破棄される可能性があります。 継続的な監視により、継続的なコンプライアンスとセキュリティが保証されます。
これらの原則を適用し、体系的なオープンソース管理プラクティスを実装することで、組織はオープンソース ソフトウェアの膨大な利点を活用しながら、セキュリティ、法的、運用上のリスクを効果的に管理できます。