2022年のOSSRAレポートによれば「組織の88％がオープンソースの情報を最新の状態にできずにいる」

May 18, 2022 / 1 min read

Table of Contents

2022年のOSSRAレポートで明らかにされたオープンソースのトレンド
よりスマートなオープンソース管理に向けて

ようやく、第7版のOSSRAとなる、Synopsysのオープンソースセキュリティとリスク（OSSRA）の年次レポートの日本語版をリリースします。Black Duck Cybersecurity Research Center（CyRC）が作成した今年のレポートでは、BlackDuck®監査サービスチームが主に合併買収（M＆A）手続きのために実施した2,400件を超える商用コードベースの監査結果を検証しました。OSSRAレポートは、オープンソースの使用傾向を強調し、その一部である相互接続されたソフトウェア・エコシステムをよりよく理解するのに役立つ気付きを、開発者に提供します。OSSRAは、セキュリティの脆弱性、古いコンポーネントや放棄されたコンポーネント、ライセンス・コンプライアンスの問題など、管理されていないオープンソースによって引き起こされる広範なリスクについても詳しく説明しています。

2022年の OSSRAレポートをダウンロードする

2022年のOSSRAレポートで明らかにされたオープンソースのトレンド

2022年のOSSRAレポートの調査結果は、オープンソースがあらゆる業界であらゆる場所で使用されており、今日構築されているすべてのアプリケーションの基盤であるという事実を強調しています。

オープンソースの監査は増加

合計2,409のコードベースが2021年にSynopsysによって監査され、そのうち97％がオープンソースを含んでいました。Black Duck監査サービスを実施した数の増加（2020年を64％上回っています）は、2021年中のM＆Aの増加を反映しています。

M＆Aにおける買収者は、買収するソフトウェアに関連するリスク、具体的には、ライセンス、セキュリティ、およびそのソフトウェアで使用されるオープンソースの品質に関するリスクを理解したいと考えています。OSSRAの監査数の増加は、売り手が取引を損なう可能性のあるソフトウェアの潜在的な問題に対してより敏感になり、M＆Aが進行する前に起こりうる問題を軽減する方向に向かっていることを示しています。

調査したすべての業界で、オープンソースが高い割合で含まれていました

2022年のOSSRAレポートに示されている17の業界のうち、4つ（コンピューターハードウェアと半導体、サイバーセキュリティ、エネルギーとクリーンテクノロジー、IoT）には、監査対象のコードベースの100％にオープンソースが含まれていました。残りの業界ではコードベースの93％から99％にオープンソースがありました。

オープンソースは本当にどこにでもあります。 2022年1月のホワイトハウスの声明によれば、ソフトウェアは「経済のあらゆる分野に遍在し、アメリカ人が毎日使用する製品やサービスの基盤となっています。ほとんどの主要なソフトウェアパッケージにはオープンソースソフトウェアが含まれており、価値をもたらすと共に課題もあります。」

ライセンスの競合を含むコードベースの大幅な減少

コードベースの半分以上（53％）にライセンスの競合が含まれていましたが、2020年に見られた65％から大幅に減少しました。全般的に、特定のライセンスの競合は2020年から2021年の間に全面的な減少を見せました。

監査で見られた1つの増加は、Creative Commons Share Alike 3.0（CC-SA 3）ライセンスに関するものでした。CC-SA 3ライセンスの競合はオープンソース・ライセンスに関して見落とされている問題を示しています。ソフトウェアは「そのコードに依存」しているため、開発者はコード・スニペット、関数、メソッド、および操作可能なコードをソフトウェアに導入することがよくあります。これは一般に依存関係と呼ばれます。ただし、依存関係自体は、開発者またはエンドユーザーが認識していないライセンス契約条件を含むサブ依存関係を利用する場合があります。たとえば、人気のあるnode.jsコンポーネントの一部のバージョンには、CC-SA 3ライセンスの下でライセンスされたコードを活用する依存関係が含まれているため、ライセンシーに望ましくない要件が課せられ、IPの問題の可能性について法的な評価が必要になる場合があります。

引き続き、パッチ管理は課題

コードベースの2,097には、セキュリティと運用上のリスクの評価が含まれており、これらのコードベースの81％には、少なくとも1つの脆弱性が含まれているものの、2021年のOSSRAの調査結果から3％ほど減少しています。少なくとも1つのリスクの高いオープンソースの脆弱性を含むコードベースの数は劇的に減少しました。監査されたコードベースの49％には、リスクの高い脆弱性が少なくとも1つ含まれていましたが、昨年と比べて11％減少しました。
運用上のリスクや保守の観点から、2,097のコードベースの85％には、4年以上前のオープンソースが含まれ、88％は最新バージョンが利用可能であるにもかかわらず、使用していませんでした。

ライセンスの競合とリスクの高い脆弱性の減少は良いことですが、監査されたコードベースの半分以上にライセンスの競合が含まれ、半分近くにリスクの高い脆弱性が含まれていたという事実は変わりません。さらに厄介なのは、調査した2,097のコードベース（リスク評価分を含む）のうち、88％に古いバージョンのオープンソースコンポーネントが含まれていたことです。つまり、アップデートまたはパッチは利用可能でしたが、適用されていませんでした。

ソフトウェアを最新の状態に維持しないことには正当な理由がありましたが、88％の大部分は、DevSecOpsチームが新しいバージョンのオープンソースコンポーネントが利用可能であることを認識していないことが原因である可能性があります。
組織がコードで使用されているオープンソースの正確で最新のインベントリを保持していない限り、コンポーネントは、リスクの高いエクスプロイトに対して脆弱になるまで忘れられてしまい、やがて、慌てて使用されている場所を特定して更新することになるわけです。

これはまさにLog4jで発生したことですが、Log4jの脆弱性をめぐる騒動でやや失われたのは、組織が特定のシステムやアプリケーション内のどこにLog4jが配置されているかを知らないことが原因であることが多かったためです。それはまったくそこにありました。その後、問題は何千ものITグループに拡大し、「Log4Shellに対して脆弱ですか？」などの質問に答えるために慌てて対処しました。ベンダーのソフトウェアは脆弱ですか？当社のソフトウェアを使用しているお客様は脆弱ですか？」