オープンソースは、ソフトウェア開発において最も素晴らしいことの一つです。
しかし、意図せず法的な義務を負ってしまう最も簡単な方法の一つでもあります。
ほとんどのチームは、オープンソースの依存関係に大きく依存していることを認識しています。しかし、それらの依存関係がどのようなライセンスを使用しているか、それに伴う義務は何か、あるいはそれらのライセンスが推移的な依存関係やコンテナイメージをどのように伝播するかを正確に知っているチームは少ないです。
そのギャップを、私たちはオープンソースライセンスリスクと呼んでいます。
オープンソースライセンスリスクとは何ですか？
すべてのオープンソースパッケージにはライセンスが付帯しています。そのライセンスは、コードで許可されることと、その対価として行わなければならないことを定義しています。
ライセンスリスクは、それらの義務がソフトウェアの構築、出荷、または収益化の方法と衝突する場合に発生します。
一般的な例をいくつか示します。
- コピーレフトライセンスは、特定の条件下でソースコードの共有を要求する場合があります。
- 帰属表示要件は、配布物にライセンス条項や著作権表示を含める必要があることを意味します。
- 制限付き使用ライセンスは、商用利用を禁止したり、通常とは異なる条件を課したりする場合があります。
- ポリシー違反は、依存関係が貴社で許可されていないライセンスを使用している場合に発生します。
これらはオープンソースが危険であることを意味するものではありません。単に、ライセンスはルールであり、コードが無料であってもルールは適用されるということです。
一般的なオープンソースライセンスと、その主なリスク
なぜチームが常に不意を突かれるのか
ほとんどのライセンス問題は、誤った判断によって引き起こされるものではありません。現代のソフトウェアが深く、階層的で、変化が速いため、これらの問題が発生します。
ライセンスリスクが見過ごされやすいいくつかの理由：
1. 推移的な依存関係は急速に増加します。
1つのパッケージを追加すると、そのパッケージがさらに10個追加し、それらがさらに50個追加します。
依存関係のツリーのどこかで、チームが直接選択することのないライセンスが導入されることがあります。それでも、その製品は出荷されます。
2. ライセンスメタデータは煩雑です
パッケージレジストリは完璧ではありません。ライセンスが欠落していたり、誤ってラベル付けされていたり、広範すぎたりする場合があります。複数のライセンスをリストするパッケージや、バージョン間でライセンスを変更するものもあります。
単一のメタデータフィールドに依存するだけでは、しばしば不十分です。
3. コンテナは独自の予期せぬ問題をもたらします
ソースリポジトリがクリーンであっても、コンテナイメージにはシステムパッケージ、言語ランタイム、ビルドツールが含まれています。
それらにもライセンスが付随します。
4. 監査は意図を考慮しません
顧客、パートナー、調達チームは、SBOMとライセンス開示をますます要求しています。「そこにあるとは気づきませんでした」という回答は、監査中に満足のいくものではありません。
適切なライセンス管理の実態
ライセンスリスクを管理するために、法学の学位や半年かかるプロセスは必要ありません。これをうまく行っているチームは、通常いくつかのシンプルな原則に従っています。
明確なライセンスポリシーを定義する
許可されるライセンス、レビューが必要なライセンス、ブロックされるライセンスを決定します。
年に一度ではなく、継続的にスキャンします
ライセンスチェックは、通常のワークフローの一部として自動的に実行される場合に最も効果的です。プルリクエスト、CI、リリースパイプラインは、問題を早期に発見するための理想的な場所です。
依存関係が出荷される前にライセンス問題を修正することは、顧客が関与した後に修正するよりも劇的に簡単です。
真のリスクを優先します
すべてのライセンス検出が同じレベルの注意を払うに値するわけではありません。すべてをクリティカルとして扱うスキャナーは、すぐにバックグラウンドノイズと化します。
最もリスクの高いライセンスが目立つようにし、チームが迅速かつ自信を持って対応できるようにします。
監査対応可能な出力を生成します
いずれ、誰かがSBOMまたはライセンスレポートを要求するでしょう。そのような場合、スプレッドシートでの作業を開始するのではなく、「エクスポート」をクリックしたいはずです。
実際のライセンス適用
ライセンス適用は、開発者がすでに作業している場所で実行される場合に最も効果的です。
実際には、ライセンスチェックは、個別の監査プロセスとしてではなく、プルリクエストやCI実行中に自動的に行われます。依存関係がポリシーに違反するライセンスを導入した場合、チームは変更をブロックするか、レビューのためにフラグを立てるか、単に監視するかを選択できます。
コードがマージされる前にライセンスの問題を表面化させることで、強制措置の予測可能性を保ち、リリースや監査時の直前の予期せぬ事態を防ぎます。
Aikidoがライセンスリスクをどのように判断するか（そしてその信頼性）
Aikidoは、精度、低ノイズ、監査対応を優先する階層的なライセンス検出アプローチを採用しています。
多くのライセンススキャナーは、静的パターンマッチングや不完全なメタデータに依存することで、多数の誤検知を生成します。時間が経つにつれて、これは結果への信頼を損ない、チームがライセンスの検出結果を完全に無視する原因となります。
Aikidoは、パッケージレジストリの単一の「ライセンス」フィールドに依存しません。実際の依存関係ツリーでは、そのメタデータはしばしば欠落していたり、一貫性がなかったり、誤解を招くものであったりします。
代わりに、正確かつ監査に適した多層的なプロセスを採用しています。
1) 完全な依存関係とライセンスのグラフを構築
複数のエコシステムにわたるマニフェストとロックファイルをインジェストし、依存関係グラフに正規化します。各依存関係はレジストリとリポジトリのメタデータで強化され、推移的な依存関係やコンテナイメージ内のOSパッケージを含め、実際に提供しているものの信頼性の高いインベントリを取得できます。
2) 一般的なケースにはまずルールを適用
標準ライセンス（MIT、Apache-2.0、BSDなど）を持つパッケージの「退屈な80%」については、Aikidoは決定論的な検出ルールを使用します。これにより、高速かつ一貫性があり、不要なノイズを回避できます。
3) 曖昧または複雑なケースにはAI分析
ライセンスが不明確な場合（カスタム条項、異常なフォーマット、メタデータの欠落、または複数のライセンスファイル）、AikidoはAIベースの分析を適用し、パッケージ内に存在するものを解釈し、静的ツールでは見落とされがちな義務を特定します。
大規模または非標準のライセンステキストを処理するために、ライセンスファイルを関連するセクションに分割し、モデルが重要な部分（コピーレフト条項、再配布要件、制限付き使用条件など）に集中できるようにします。
4) 影響の大きいエッジケースには人間の法的検証
Aikidoには検証ステップが含まれており、曖昧な、または影響の大きい検出結果は法務専門家によってレビューされます。これにより、最終的な分類が単なる最善の自動化ではなく、実際のライセンス義務を反映していることが保証されます。
5) バージョン固有の結果とポリシー適用
ライセンス義務はバージョン間で変更される可能性があります。Aikidoは、提供する正確な依存関係のバージョンに対してライセンスを解決し、そのデータをポリシー制御に接続することで、チームはCI/CDで「許可/レビュー/ブロック」ルールを直接適用できます。
Aikidoが他のツールとどう比較されるか
Aikidoは、ルール、AIベースの分析、および法的検証を組み合わせたハイブリッドアプローチを採用しています。これにより、静的パターンマッチングに主に依存するツールよりも、誤検知が少なく、カスタムまたはプロプライエタリなライセンスの処理が向上します。
ライセンステキストのみに焦点を当てるツールとは異なり、AikidoはマルウェアやCVE公開前のリスクも検出し、ソフトウェアサプライチェーンリスクのより完全なビューを提供します。エコシステムのカバレッジはアプリケーションの依存関係を超えて、コンテナイメージ内のオペレーティングシステムパッケージを含みます。
Socketは主にJavaScriptエコシステムと静的ライセンス検出に焦点を当てており、しばしば高い誤検知率や脆弱なバージョン処理につながります。JFrog Curationはより広範なエコシステムをサポートしますが、カスタムライセンスやCVE以外のリスクへの対応は限定的です。
ライセンスの強制は単独で存在するものではありません。現実世界のサプライチェーンリスクには、マルウェア、侵害されたパッケージ、およびまだCVEが割り当てられていない新たな脅威が含まれます。Aikidoは、そのより広範な全体像の一部としてライセンスリスクに対処するように設計されました。
最後に
オープンソースライセンスは恐れるべきものではありませんが、尊重すべきものです。
現代の依存関係ツリーの規模では、手動での追跡は機能しません。ライセンスリスクに先行して対応するチームは、可視性の自動化、実際の問題の優先順位付け、開発の早期段階でのチェックの統合という3つのことをうまく行っています。
それこそが、私たちがAikidoを構築した目的です。
ライセンススキャンが既存のワークフローにどのように適合するかを確認したい場合は、数分で試すか、最初のSBOMを生成できます。将来の自分、そしておそらく法務チームが感謝するでしょう。
