ここ数年、人々はソフトウェアでオープンソース コンポーネントを使用することに内在するリスクをますます認識するようになりました。ほとんどのソフトウェアがオープンソースと独自のロジックが混在していることを考慮すると、最終的なソフトウェア製品の適切なリスク管理には、どの成分が外部から直接または一時的にインポートされたかを知ることが不可欠です。複雑なスプレッドシートを使用して成分を追跡する時代は過ぎ去り、起動するのがひどく非効率であるため、そのような追跡を達成する主な方法は、ソフトウェア部品表である SBOM を利用することです。他の部品表と同様、これは基本的に、どのコンポーネントが相互に依存しているかに特に焦点を当て、さまざまなコンポーネント間の関係を追加した、ソフトウェアが構築されるソフトウェアコンポーネントのリストです。
現在市場で使用されている 2 つの主要な SBOM 形式、SPDX と CycloneDX があります。
ソフトウェア パッケージ データ交換 (SPDX) Linux 財団によるオープンソースの機械可読 SBOM プロジェクトです。 SPDX の最新バージョンは、NTIA の「」標準に沿って設計されました。ソフトウェア部品表の最小要素。」ソフトウェアのコンポーネント、著作権、ライセンス、セキュリティ参照がリストされています。
サイクロンDX（CDX） これは、Open Web Application Security Project (OWASP) コミュニティによって開発された、オープンソースで機械可読な SBOM 形式でもあります。 CycloneDX は BOM フォーマットとして、ソフトウェア部品表の作成以外にも応用できます。また、ハードウェアやクラウド システムのコンポーネント、脆弱性、サービスをコンパイルするためにも使用できます。
SBOM が重要なのはなぜですか?
SBOM は、ソフトウェア開発チーム、購買組織、エンド ユーザーにとって非常に役立ちます。これを使用すると、オープンソースおよびサードパーティのコンポーネントが最新であることを保証でき、どのプロジェクトの依存関係にソフトウェアで悪用される可能性がある既知の脆弱性があるかを可視化できます。一方、ソフトウェア購入者は、SBOM を利用して、脆弱性評価を通じて製品に固有のリスクを分析できます。
組織は、ベンダーと協力して、システムや製品に実装されているプロジェクト コンポーネントに関する正しい最新情報に確実にアクセスできるようにすることで、より良いサービスを得ることができます。また、オープンソースおよびサードパーティのコンポーネントを利用するリスクを最小限に抑えるために、SBOM を定期的に評価する必要があります。
SBOMサンプル
使用する SBOM 形式によっては、SBOM のコンポーネントが異なる場合があります。プロジェクトのサイズと複雑さに応じて、SBOM JSON ファイルは簡単に数千行以上になることがあります。 1,000 行のファイルを見てもあまり有益ではないので、既存のより単純な例を使用して、各 SBOM 形式に何が含まれているかを確認してみましょう。現在市場に出ている 2 つの主要なフォーマットのサンプルを詳しく見ていきます。
SPDX
これから説明する SPDX SBOM サンプルは次のとおりです。 こちら.
JSON は、ファイル自体に関する一般情報 (メタデータ) から始まります。
その後、調査しているソフトウェアに関するメタデータを取得します。
チェックサムとその値に注目してください。 SBOM の各セクションには、問題の部分の暗号化と結果が含まれているため、ファイルを調べる人は、言及されているソフトウェアまたはコンポーネントが調べているものと同一であることを確認できます。
その保証がなければ、同じ名前のコンポーネントまたはソフトウェアの複数のコピーが簡単に見つかる可能性があり、これらのバージョンのどれがチェックされているか、ソフトウェアまたはそれを説明する SBOM に含まれているかがわかりません。
チェックされたソフトウェアの説明に続いて、コンポーネントの確認を開始できます。
コンポーネントのライセンス、ホームページ、バージョン、フルネームなどを説明するために含まれる複数のフィールドが表示されます。
SPDX 形式で見つけられるもう 1 つの機能は、注釈です。これは、後でセクションに追加され、より多くの情報が含まれ、場合によってはフリー テキストも含まれます。
この形式とその機能の詳細については、次のサイトを参照してください。 SPDXページ Linux財団の。
サイクロンDX
CycloneDX SBOM フォーマットは、JSON ファイル、XML ファイル、またはプロトコル バッファーで記述できます。物事を均一かつ単純にするために、簡略化された CycloneDX JSON の例に従います。説明されている例は次のとおりです。 こちら.
JSON は、ファイルに関する一般的なメタデータ情報から始まります。
次に、ソフトウェア上のメタデータが検査されました。
その後、ソフトウェア コンポーネントとその依存関係は次のようになります。
これは簡略化された例であり、この形式には他の多くの情報が含まれる可能性があることに注意してください。さまざまなユースケースをより包括的に確認するには、OWASP CyclonDX ユースケースのページをご覧ください。 こちら.
以下は、依存関係のリストの構築を示すそのページの例です。
そして、OWASP から引用した、この形式のさまざまなコンポーネントについてのさらに広範囲にわたる説明を次に示します。 BOM 機能 ページ：
SBOMの使用方法
ここにあるファイルの例を理解できなくても心配する必要はありません。 JSON ファイルは人間が非常に読みやすいですが、専門的に作成されたソフトウェアが情報を取り込み、分析によって得られる結果を吐き出すことができるように、機械で読み取れるほうがはるかに適しています。
ソフトウェア コンポーネントのリストを使用して、不要なオープンソース ライセンス (GPL3.0 または MPL1.1 行) が含まれていないことを確認できます。依存関係のリストを定期的にチェックして利用可能なアップデートがあるかどうかを確認したり、パッケージ名を脆弱性データベースと照合してソフトウェアにどのような問題のある依存関係が含まれているかを確認したりできます。
SBOM を取り込んですべての情報を戻すのは複雑に聞こえるかもしれませんが、すべてを自分で行う必要はないことに注意してください。 Scribe Security プラットフォームのようなサービスは、多くの悩みを解消し、はるかに多くのメリットを提供します。ぜひ当社のプラットフォームをチェックして、開発ライフサイクルと最終製品にわたる継続的な監視システムを使用してリスクを管理する方法をご確認ください。