サプライチェーンにおけるオープンソース・ソフトウェアのリスクを軽減

オープンソース・ソフトウェアの内容を把握することで、オープンソースの利用者も製作者もサプライチェーンのセキュリティ・リスクを管理できます。

サプライチェーンにおけるオープンソース・ソフトウェアを管理 | シノプシス

最近のオープンソース・ソフトウェア（OSS）の動向は、商用ソフトウェアの閉鎖性と保護が強化されるようになった80年代に始まりました。これにより学者、研究者、愛好家は、公然と再利用、変更、配布できるソースコードにアクセスすることが可能になりました。当初、企業でのOSSの採用は遅々としたものでしたが、この20年間でOSSが急速に普及し、今日では、ほとんどの企業向けソフトウェア・プロジェクトにオープンソース・ソフトウェアが含まれています。

オープンソースソフトウェアの隆盛

シノプシスが作成した2021年の「オープンソース・セキュリティ＆リスク分析」（OSSRA）レポートでは、長年にわたり監査されているコードベースでのオープンソース・ソフトウェアの使用状況を集計しました。年次報告書の最新のイテレーションでは、過去5年間で商用コードベースのオープンソース・ライブラリが259%増加し、2020年に監査されたコードベースの98%が少なくとも1つのOSSライブラリに依存していることが分かりました。

2021年版OSSRAレポートをダウンロード

この増加にはもっともな理由があります。オープンソース・ソフトウェアにより、最新ソフトウェアのあらゆる共通部品を利用できるので、プロジェクト・チームはアプリケーションの差別化に集中することができます。多くの場合、これらの部品は無料で高品質。しかも活発なコミュニティによって常に最新の状態に維持されています。ただし、これは多くのOSSユーザーがOSSの貢献者でもあることが前提になります。つまり、オープンソースでは、ソースコードを共有し、コミュニティ全体で改良していくことが重要です。

各ライブラリに1つ以上のライセンスを適用することで、このソースコード共有の原則が実施されます。ライセンスは多様で、条件の緩いものから制限の厳しいものまでさまざまです。企業プロジェクトで使用するライブラリと著作権の所有者を開示するだけで済む場合もあります。ライセンスによっては、企業プロジェクトの独自ソースコードを元のOSSと同じライセンス条件で配布する必要があり、しかもプロジェクトでのコードの使用がサービスの提供に限定される場合があります。これは当然、ソフトウェアの商業的価値を活用できる権利を守りたい企業の思惑と矛盾する可能性があります。

そのため、プロジェクト・ドメイン、配布モード、プロジェクト・アプリケーションでのOSSの使われ方の特性を考慮して、企業プロジェクトでオープンソース・ソフトウェア・ライブラリ・ライセンスを適切に管理する必要があります。まず、使用されているライブラリと該当するオープンソース・ライセンスを特定するために、プロジェクト内のOSSライブラリのインベントリを示す正確な部品表（BOM）を作成します。企業によっては、使用するオープンソースの宣言を開発者に要求することでBOMを維持している場合があります。これでも何もしないよりはましですが、多くの場合、ライブラリは認識の欠如または懈怠により、使用されているオープンソース（およびそれに関連する依存関係）の量が膨大で、しかも悪意が潜んでいる可能性があるため、宣言なしでインクルードされています。ソフトウェアコンポジション解析ツール、特にBlack Duck®などの多因子メカニズムを持つツールを使用する方法は、これに比べてはるかに優れています。

しかし、これはソリューションの一部に過ぎません。この方法により効率化が可能ですが、そのためには教育、検出、検証を含む、明確に定義されたコンプライアンス・プロセスの適用を併せて実行する必要があります。このプロセスは企業ごとに異なるため、事業の法的要件、製造されるソフトウェアの種類、内部組織に合わせて調整する必要があります。

ソフトウェア・サプライチェーンではオープンソースのトレーサビリティの確保が困難

企業が1つ以上のソフトウェア・プロバイダーに依存し、提供されたソフトウェアをソフトウェア依存関係として直接、または製品に組み込まれたデバイスのファームウェアを介して統合すると、問題はさらに複雑になります。サプライチェーンのトレーサビリティ要件は、物理的な商品市場では以前から一般的でしたが、ソフトウェア・サプライチェーンにおけるOSSのトレーサビリティは比較的新しく、最近になってようやくソフトウェア業界でも重要視されるようになり始めました。

それに対する準備ができている企業はごくわずかです。2021年のOSSRAの報告書によると、監査対象のコードベースの65%がライセンスの競合を抱えており、26%がライセンスのないサードパーティ・コードを保有していたことがわかりました。これらの数字は2020年に報告された数字よりもわずかに低く、企業が問題に取り組み始めていることを示唆している可能性がありますが、依然として懸念される高さです。

サプライチェーンでは、この問題がさらに悪化します。プロバイダーが自社開発コードに潜むOSSライセンスのリスクを見つけられない場合、利用者はどうすればよいでしょうか？ソフトウェアの配布方法に応じて、利用者はソフトウェアを受け入れる前に体系的にスキャンすることができます。配布物としてソースコードとバイナリコードが提供されている場合はスキャンが可能で、Black Duckなどのバイナリ・スキャナーを使用してスキャンすることもできますが、配布物がファームウェアを搭載したハードウェアである場合は複雑になる可能性があります。配布されたコードをスキャンすることをお勧めしますが、その段階で問題が検出された場合、再出荷前にプロバイダーにソフトウェアを更新してもらう必要が生じ、そのプロセスに時間がかかります。

これは、他の市場が適切なサプライチェーンマネジメント・プラクティスによって対処している問題です。世界の商品市場のサプライチェーンマネジメントを改善し、近代化するためにソフトウェアがさまざまな機能を提供してきたにもかかわらず、業界独自のサプライチェーンマネジメントがいかに時代遅れであるかは明らかです。

サプライ・チェーンに潜むリスクを低減

まず、独自のソフトウェア開発に適したオープンソース・ソフトウェア・ライセンスのコンプライアンス・プロセスを実施することが重要です。その取り組みには社内のさまざまなチームが関わります。法律専門家は、受諾可能なライセンスとコンテキスト、および以前に評価されていないライセンスの取り扱いを決定するための一連のルールを正確に評価する必要があります。ソフトウェア・エンジニアリング・チームは、オープンソース・ソフトウェアの使用に対する法的な影響についての教育を受け、新しいOSSライブラリを検討する際の手順を知っておく必要があります。ソフトウェアファクトリーは、統合および配布時にOSSライセンスを考慮に入れ、リスクの高いビルドを拒否する可能性もあります。前述のように、優れたソフトウェアコンポジション解析ツールはソフトウェア内のOSSを迅速かつ正確に把握するために重要なツールであり、法律専門家が定義したルールに基づいてリスクを評価できます。

これらの取り組みは、自社開発のソフトウェアも含め、配布するすべてのソフトウェアに適用する必要があります。つまり、製作者にも自社と同レベルのオープンソース・ソフトウェア・コンプライアンスを適用することをお勧めします。製作者のスタッフが自社のスタッフと同様の教育を受け、OSSライセンス・コンプライアンスのワークフローを取り入れていることを信頼できる必要があります。自社と同じプロセスに従う必要はありませんが、製作者も同レベルの信頼性を実現する必要があります。プロバイダーが汚染したライセンスを配布物に導入した場合、自社のライセンスも汚染される可能性があり、両者がリスクにさらされます。

適用する必要があるライセンスルールについても明確にする必要があります。プロバイダーは、どのライセンスが受諾されるかを推測できません。プロジェクトに関してプロバイダーと交渉する場合、機能、パフォーマンス、セキュリティと同様に、受諾可能なライセンスの付与も要件に含める必要があります。それでも汚染されたライセンスが網の目をすり抜けるリスクが完全に排除されるわけではありません。準拠していないOSSの配布を拒否する権利を明確化し、コンプライアンス違反のリスクを軽減するため、OSSのサニティ・スキャンは受け入れフェーズに含める必要があります。

協業が鍵

社内のオープンソース・ソフトウェア・コンプライアンス管理の成熟度が一定レベルに達していたとしても、おそらく社内の手順を調査してオープンソースが基準に達しているかどうかを判断する余裕がないため、製作者がどの程度信頼できるかを知ることは困難です。この問題に対処するためにOpenChainプロジェクトが創設され、現在はISO 5230標準となっています。Linux FoundationプロジェクトであるOpenChainのビジョンは、信頼できる一貫したコンプライアンス情報をオープンソースに提供するサプライチェーンの構築です。そのために、ソフトウェア・サプライチェーンに参入している企業がオープンソースを効果的に管理するための明確な要件を確立しました。プロジェクトの認定を受けるということは、これらの要件を満たし、プロバイダーや顧客など、認定されたサプライチェーンの他の利害関係者と協業する準備が整っていることを意味します。

オープンソース・ソフトウェアを使い始めたばかりの場合でも、OpenChainプロジェクトは今後の道筋を示す貴重な情報源となります。要件と要件を満たす方法を示す豊富な素材を自由に入手可能なので、認定を受ける過程で徐々に素材を導入することができます。

サプライチェーンの最弱リンクを保護

企業のオープンソース・ソフトウェア・コンプライアンスの成熟度は、何も規定されていないプログラムから明確に定義されたプログラムまで、さまざまですが、サプライチェーンの場合、リスクはチェーンの最も成熟度の低い部分で定義されます。一部の企業は、OpenChainプログラムへの参加など、最弱リンクの強化を目指して行動していますが、このような動向はまだ始まったばかりです。今後数年間で、OSSコンプライアンスは、ソフトウェアや従来のテクノロジーの問題以外の領域に関わる業種を含め、サプライチェーン要件の一部として強化されていくことが期待できます。それは好ましいことです。プロバイダーとの取引により労力が増えることになったとしても、長期的にはリスクと関連コストが大幅に低減するのですから。今すぐにでもこれに取り組まないと、企業は今後、ソフトウェア・サプライチェーンの中での地位を見出すことに難儀するかもしれません。