6つのSBOMタイプについて知っておくべきこと

オープンソースソフトウェア

ソフトウェア開発においてサードパーティやオープンソースのコードが広く利用されていることを考えると、完全かつ正確なソフトウェア部品表(SBOM)の作成と維持は容易ではありません。しかし、Cybersecurity and Infrastructure Security Agency (CISA:アメリカ合衆国サイバーセキュリティ・社会基盤安全保障庁)が、あらゆるソフトウェアアプリケーションに対して作成可能な6種類のSBOMを定義していることをご存知ですか?各SBOMは、ソフトウェア開発ライフサイクル(SDLC)の特定のフェーズに対応していることがほとんどです。

各SBOMにはそれぞれ長所と短所があり、状況によってはより適切な場合もあります。組織によっては、複数のSBOMが適切な場合もあります。その答えは、SBOMで解決したい課題と、優先順位を付けているリスクによって異なります。

さまざまな種類の SBOMを詳しく調べる前に、米国電気通信情報局 (NTIA) によって定義された SBOM の最小コンテンツが、各 SBOM に適用されることを覚えておくことが重要です。

Design SBOM

Design SBOMとは、新しいソフトウェア成果物に含まれるコンポーネント(一部は存在しない場合もある)の意図された設計のSBOM、です。これは通常、ソフトウェアソリューションアーキテクチャ仕様、提案依頼書(RFP)、またはその他の初期コンセプトから派生します。

Design SBOMは、ライセンスの購入または取得前に互換性のないコンポーネントを特定できます。また、開発者が使用するために承認または推奨されるソフトウェアコンポーネントを定義することもできます。

ただし、Design SBOM は生成が非常に難しい場合があり、他のSBOM タイプほどの詳細を識別できない可能性があります。

設計フェーズ用の SBOM 生成に特化したツールがあり、組織は開発ライフサイクルの早い段階でソフトウェア コンポーネントを計画し、文書化できます。

Source SBOM

CISAは、Source SBOMを、開発環境、ソースファイル、および製品成果物の構築に使用された依存関係から直接作成されたSBOM、と定義しています。Source SBOMは通常、ソフトウェア構成分析(SCA)ツールから生成され、手作業で明確化されます。この手作業は監査とも呼ばれます。

Source SBOMは、ビルドプロセスにアクセスすることなく可視性を提供します。ソースにおける脆弱性の修正を容易にします。また、含まれるコンポーネントの依存関係階層(依存関係分析とも呼ばれます)のビューも提供します。これらの依存関係は、直接的なものと一時的なもの(依存関係の依存関係)の場合があります。

Source SBOMは、一度も実行されたことがない、またはデプロイされたコードではコンパイルされないコンポーネント(脆弱性を含む可能性がある)をハイライトする可能性があることに留意することが重要です。言語やエコシステムによっては、Source SBOMにランタイム、プラグイン、アプリケーションサーバーやプラットフォームライブラリなどの動的コンポーネントが含まれていない場合があります。これらのコンポーネントは、完全性を保つために他のSBOMへの参照を必要とする場合があります。SCAツールがサプライヤー/ベンダーのSBOMを容易に取り込めるようにし、それらを統合して完全なSource SBOMを生成できるようにしてください。

FossID は、アプリケーションのサードパーティ製商用ライブラリやオープンソースライブラリおよび独自ライブラリを含む全てのSource SBOM を生成できます。また、SPDX、SPDX-Lite、CycloneDX などの標準形式をインポート/エクスポートできます。

Build SBOM

CISAはBuild SBOMを、ビルド後の成果物(実行ファイル、パッケージ、コンテナ、仮想マシンイメージなど)の分析を通じて生成されるSBOMであり、このような分析には通常、様々な発見的手法が必要となる、と定義しています。文脈によっては、これは「サードパーティ」SBOMと呼ばれることもあります。

Build SBOM は通常、ビルドプロセスの一部として生成され、最終リリース成果物 SBOM を構成する中間ビルド SBOM とソース SBOM が統合された構成になる場合があります。

このタイプのSBOMは、ビルドプロセスや継続的インテグレーション/継続的デプロイメント(CI/CD)プロセスで利用可能な情報により、製品成果物のSBOM表現の正確性に対する信頼性を高めます。Build SBOMは、ソースコードだけでなく、より多くのコンポーネントの可視性を提供します。ソフトウェアデリバリーワークフローの一環としてBuild SBOMの作成を自動化するもう一つのメリットは、SBOMにデジタル署名することで、ソフトウェアの内容を確実に証明し、顧客との信頼関係を確立できることです。

一方、このSBOMはビルドが実行されるビルド環境に大きく依存するため、組織はビルドプロセスを変更してこのSBOMを生成する必要がある可能性があります。間接的な(いわゆる「一時的な」)依存関係や実行時の依存関係を把握することが困難な場合があります。また、動的にリンクされた依存関係の正しいバージョンが含まれていない可能性もあります(言語やエコシステムによっては実行時に置き換えられる可能性があるため)。

FossID はCI/CD ワークフローと統合して、Build SBOM も生成します。

Analyzed SBOM

Analyzed SBOMは、ビルド後のアーティファクト(実行ファイル、パッケージ、コンテナ、仮想マシンイメージなど)の分析によって生成されます。このような分析には通常、様々な発見的手法が必要です。場合によっては、「サードパーティ」SBOM、と呼ばれることもあります。このタイプのSBOMは、通常、サードパーティツールによるアーティファクトの分析によって生成されます。

Analyzed SBOMは、レガシーファームウェアアーティファクトなどのアクティブな開発環境がなくても可視性を提供します。ビルドプロセスへのアクセスは必要ありません。他のソースからのSBOMデータの検証に役立ち、他のSBOM作成ツールでは見逃される隠れた依存関係を発見できる可能性があります。

ツールがソフトウェアコンポーネントを正確に分解または認識できない場合、分析されたSBOMには欠落、エラー、または近似値が含まれる可能性があります。その結果、発見的手法やコンテキスト固有のリスク要因に依存する可能性があります。

Deployed SBOM

Deployed SBOMは、システム上に存在するソフトウェアのインベントリを提供します。これは、構成オプションの分析と(場合によってはシミュレートされた)デプロイメント環境での実行動作の検証を組み合わせた、他のSBOMのアセンブリである場合があります。このタイプは通常、システムにインストールされたアーティファクトのSBOMと構成情報を記録することによって生成されます。

デプロイされた SBOM は、アプリケーションの実行に使用されるその他の構成やシステムコンポーネントなど、システムにインストールされているソフトウェアコンポーネントを強調表示します。

そのため、生成にはインストールおよび展開プロセスの変更が必要になる場合があります。また、コンポーネントがアクセスできないコード内に存在する場合があるため、ソフトウェアのランタイム環境を正確に反映していない可能性があります。

Runtime SBOM

最後に、Runtime SBOMは、ソフトウェアを実行しているシステムを監視・記録することで生成されるSBOMであり、システム内に存在するコンポーネントだけでなく、外部からの呼び出しや動的に読み込まれるコンポーネントもキャプチャします。文脈によっては、「インストルメント化」または「動的」SBOMと呼ばれることもあります。

この SBOM タイプは通常、システムと対話して実行環境に存在する成果物や実行された成果物を記録するためのツールから生成されます。

Runtime SBOMは、システム実行時に何が使用されているかを把握するための可視性を提供します。これには、動的に読み込まれるコンポーネントや外部接続も含まれます。コンポーネントがアクティブかどうか、どの部分が使用されているかといった詳細な情報も含まれる場合があります。これは、アプリケーションセキュリティ管理におけるノイズの低減に非常に役立つ可能性がありますが、著作権やライセンスコンプライアンス管理の妨げとなる可能性があります。

Runtime SBOMでは、システムを実行中に分析する必要があるため、追加のオーバーヘッドが発生する可能性があることに注意してください。一部の詳細情報は、システムが一定期間実行され、完全な機能が実行されるまで使用できない場合があります。

クラウドセキュリティポスチャ管理 (CSPM) 製品は、Runtime SBOM を提供する傾向があります。

自分に合ったSBOMタイプを選びましょう

言うのは簡単ですが、実行するのは難しいかもしれません。いずれにせよ、具体的な要件、開発・保守プロセス、そして組織のリスクプロファイルに適した詳細情報のレベルを考慮することが重要です。

完全性と正確性が重要な場合(M&A 技術デューデリジェンス、企業の知的財産の保護、オンプレミスまたは組込みシステムなど)には、オープンソース監査サポートとともにSource SBOM and/or Build SBOMを検討してください。

FOSSID製品ページはこちら