オープン ソース コードの脆弱性は引き続き見出しを付けていますが、 Heartbleed や Log4Shell などの他のテクノロジは、オープン ソース リスクの隠れた原因、つまりオープン ソース ライセンスの非準拠に気付かれません。
パロ アルト ネットワークスは、オープン ソース ソフトウェア ライセンスはリスクの主な原因であると考えています。なぜなら、ソフトウェアの非準拠ライセンスが XNUMX つでもあるだけで、法的措置、時間のかかる是正措置、および製品の市場投入の遅れにつながる可能性があるからです。 明らかなリスクにもかかわらず、ライセンス規制に準拠することは簡単なことではありません。 さまざまなオープン ソース ライセンスと、ソフトウェアに適用されるライセンスを判断することの難しさにより、ライセンスの追跡、理解、および管理が難しくなっています。
高レベルまたは重大な脆弱性を検索する場合と同様に、非準拠ライセンスを検索するには、組織がオープンソースと推移的な依存関係のネットワークを解明する必要があります。多くの場合、その深さは XNUMX ～ XNUMX レベルを超えます。 これらの依存関係により、多くの場合、同じオープン ソース パッケージの複数のバージョンが作成されます。また、この Web に隠されている過度に制限的なコピーレフト ライセンスを見つけることも珍しくありません。 ライセンスが準拠していることを確認するには、組織はソフトウェア構成の高度なコンテキスト分析を活用する必要があります。 これにより、会社を脅かす非準拠のライセンスを特定、検出、優先順位付けすることが可能になります。
オープンソース ライセンスの概要
ユーザーが「オープンソース」という言葉を聞くと、このパッケージを好きなように使用できると考えるのは簡単です。 B. 商用製品の開発に使用する。 しかし、たとえソース コードが全世界に公開されていたとしても、オープン ソース コードは使用制限から自由ではありません。
オープン ソース パッケージには、コードの使用、再利用、共有、変更、および配布を管理するライセンスが付属しています。 何百もの異なるオープン ソース ライセンスが、ユーザーがオープン ソース コードをどのように使用できるかを規定しており、準拠しない場合のペナルティは現実のものです。 企業がオープンソース パッケージを使用していて、ライセンスに準拠していない場合、独自のコードをオープンソース化するか、コード全体から準拠していないパッケージを削除して置き換えるという、費用と時間のかかるプロセスを経ることを余儀なくされる可能性があります。ベース。
では、責任者は、コンプライアンスを維持するために満たす必要がある特定の要件をどのように知るのでしょうか? 要件はライセンスによって大きく異なるため、ここが難しいところです。 一部のライセンス – 例: B. コピーレフト - 非常に制限的です。 他のものは有料ですが、正しい帰属が与えられれば、他のものも自由に使用できます。 ただし、一般に、オープンソース ライセンスは、コピーレフトとパーミッシブ ライセンスの XNUMX つの主要なカテゴリに分類されます。
コピーレフト ライセンス
コピーレフト ソフトウェア ライセンスは、問題のオープン ソース ソフトウェアを使用するコードをオープン ソース化することを企業に要求する非常に制限的なライセンスです。 これらのライセンスでは、ソフトウェアのソース コード ファイルを配布する必要があります。このファイルには、通常、ライセンス条項のコピーが含まれており、コードの作成者のクレジットが含まれています。 最もよく知られているコピーレフト ライセンスは、GNU General Public License (GPL) です。
許容ライセンス
Permissive ライセンスには、ソフトウェアの使用、変更、および配布方法に関する最小限の制限のみが含まれています。 これらのライセンスには、通常、保証の否認が含まれています。 permissive ライセンスの例としては、GNU All-permissive License、MIT ライセンス、BSD ライセンス、Apple Public Source License、および Apache License があります。 2016 年に最も人気のあるフリー ソフトウェア ライセンスは、パーミッシブ MIT ライセンスです。 Apache ライセンスを使用する注目すべき成功したオープン ソース ソフトウェア パッケージは Kubernetes です。
ケーススタディ: コピーレフト ライセンスの不遵守
2008 年、Free Software Foundation (FSF) は、使用しているオープン ソース コードに準拠していない LinkSys ブランドのソフトウェアを販売したとして、Cisco を訴えました。 よくあることですが、GPL 著作権侵害の原因となった非準拠のソフトウェアは、買収の一環として Cisco のソフトウェアに統合されました。 オープン ソース ソフトウェアの普及、買収の台頭、依存関係構造の深化により、商用ソフトウェア製品に深く定着しているオープン ソース ライセンスを特定することがますます難しくなっています。 ただし、遵守しないと、商用の知的財産を非公開に保つ努力が妨げられる可能性があります。 たとえば、ライセンスに準拠していない企業は、そのソフトウェアをオープンソースにするか、そのソフトウェアの販売を停止することを余儀なくされる場合があります。 また、ライセンスがコピーレフト ライセンスほど制限的でない場合でも、チームはソフトウェアを再構築して主要な依存関係を解消する必要がある場合があります。これにはコストがかかり、リリースの速度が遅くなります。
ライセンス コンプライアンスの監視
すべてのライセンスを特定するだけでも十分に複雑であるかのように、オープン ソース ライセンスはいつでも変更される可能性があります。 たとえば、広く使用されているオープン ソース パッケージの Elasticsearch は、2021 年に以前の寛容なライセンスからより制限的なライセンスに切り替わりました。 ライセンス コンプライアンスの確認は、XNUMX 回限りのものではありません。 代わりに、コンプライアンス管理には、他のオープンソース セキュリティ プロセスと同じデューデリジェンスを必要とする継続的なアプローチが必要です。 B. サードパーティのパッケージをより新しく、より安全なバージョンに更新する。
オープンソース管理戦略
一見すると、オープンソース ライセンスへの準拠は簡単に思えるかもしれません。 しかし実際には、それはオープンソース自体の性質と同じくらい複雑であり、悲しいことに、既存のオープンソース セキュリティ戦略に依存関係と脆弱性管理プロセスの徹底的な見直しが含まれていたとしても、依然として重要なオープン性が存在する可能性があります -Source企業が対処しないリスク。 準拠していないパッケージが XNUMX つあるだけで、アプリケーション全体がライセンス要件に準拠していないことになります。 したがって、組織はサプライ チェーンを適切に保護するために、積極的かつ包括的なオープン ソース セキュリティ戦略を戦略に組み込む必要があります. 開発サイクルの早い段階でオープン ソース ライセンスの問題を特定して修復する積極的なアプローチを採用することで、組織は開発者の生産性を向上させることができます. 同時に、開発サイクルの後半で、準拠していないパッケージをソフトウェアから切り離して置き換える必要があるというストレスを軽減できます。
包括的なオープン ソース セキュリティの採用は困難に思えるかもしれませんが、実行可能です。 正しく行えば、開発者にとって使いやすいものになることさえあります。 Checkov などのオープンソース ツールを VSCode や Jetbrains の PyCharm などの IDE と統合することで、アプリケーション開発者と DevOps チームは、開発サイクルのできるだけ早い段階で脆弱性や潜在的なライセンス コンプライアンスの問題を可視化できます。 これにより、準拠していないパッケージの問題をプロアクティブに修正し、リリースの速度を維持できます。
詳しくは PaloAltoNetworks.com をご覧ください
パロアルトネットワークスについて サイバーセキュリティ ソリューションのグローバル リーダーである Palo Alto Networks は、人々や企業の働き方を変革するテクノロジーによって、クラウドベースの未来を形作っています。 私たちの使命は、優先されるサイバーセキュリティ パートナーとなり、私たちのデジタル ライフを保護することです。 人工知能、分析、自動化、およびオーケストレーションにおける最新のブレークスルーを活用した継続的なイノベーションにより、世界最大のセキュリティの課題に対処するお手伝いをします。 統合プラットフォームを提供し、拡大するパートナーのエコシステムを強化することで、クラウド、ネットワーク、モバイル デバイス全体で何万もの企業を保護するリーダーとなっています。 私たちのビジョンは、毎日が以前よりも安全な世界です。