SBOM：Software Bill Of Materialsとは？（フォーマット、ユースケース、ツールについて）｜OSS管理ブログ｜ソフトウェア部品管理ソリューション

この内容は、FOSSA社のブログ記事を元に日本語に翻訳・再構成した内容となっております。

はじめに

SBOM（Software Bill Of Materials：ソフトウェア部品表）とは、特定の製品に含まれるすべて（プロプライエタリおよびオープンソースなど）のソフトウェアコンポーネント、ライセンス、依存関係を一覧化したものです。SBOMは、ソフトウェアのサプライチェーンを可視化することに役立ち、ライセンスコンプライアンス、セキュリティ、品質に関するリスクを明らかにします。

今日のアプリケーションは多くのオープンソースおよびプロプライエタリなソフトウェアコンポーネントで構築されています。このような複雑さを考えると、製品に関わる組織や個人（メーカー、オペレーター、バイヤー）が、ソフトウェアのサプライチェーンや、ライセンスコンプライアンス、セキュリティ、品質などのリスクを完全に把握することは困難です。

SBOMは、これらの分野における重要な洞察を提供します。潜在的なセキュリティ脆弱性を迅速に修正、ライセンス要件の遵守、バージョン管理のベストプラクティスの適用などに役立ちます。さらに、バイデン政権が最近発表したサイバーセキュリティ大統領令には、連邦政府に製品を販売する組織に対してSBOMの作成を義務付ける条項が含まれており、このような点からも、SBOMの重要性がさらに高まっていることが伺えます。

この記事では、SBOMのメリット、最低限必要な要素、作成に役立つツールやテンプレートなど、SBOMに関連するさまざまなトピックをご紹介します。

SBOMの構成要素

2021年7月12日、米国連邦政府は、バイデン政権の大統領令に準拠するためのSBOMにおける最低限必要な要素を発表しました。このガイドラインは、連邦政府と取引のある組織にのみ適用されますが、あらゆる種類の組織が早急にこのガイドラインを採用しても不思議ではありません。

これらのSBOMの最小要素は3つの分野に分類されます。

Data Fields
Automation Support
Practices and Processes

以下のセクションでは、これらの各要素を詳しく見ていきます。

Data Fields

データフィールドには、ソフトウェアを構成するコンポーネントに関する情報が含まれます。SBOMの最小要件を発表した米国NTIA（National Telecommunications and Information Administration）によると、データフィールドの意図は以下とされています。

The goal of these fields is to enable sufficient identification of these components to track them across the software supply chain and map them to other beneficial sources of data, such as vulnerability databases or license databases.
これらのフィールドの目的は、ソフトウェアのサプライチェーン全体でコンポーネントを追跡し、脆弱性データベースやライセンスデータベースなどの、ほかの有益なデータソースにマッピングするために、これらのコンポーネントの十分な識別を可能にすることです。

具体的には以下となります。

Supplier Name（サプライヤー名）
Component Name（コンポーネント名）
Version of the Component（コンポーネントのバージョン）
Other Unique Identifiers（そのほかの固有識別子）
Dependency Relationship（依存関係）
Author of SBOM Data（SBOMデータの作成者）
Timestamp（タイムスタンプ）

文脈上、「Other Unique Identifiers」は、Software Identification（SWID）タグ、Package Uniform Resource Locators（PURL）、Common Platform Enumeration（CPE）、またはそのほかの識別子を指す場合があります。また、「Dependency Relationship」とは、基本的に、異なるソフトウェアコンポーネントがどこでどのように組み合わされるかを意味します。NTIAによると、これは「enables the representation of transitivity from a piece of software to its component and a potential sub-component.（ソフトウェアの一部からそのコンポーネントおよび潜在的なサブコンポーネントへの移行性を表現することができる）」とされています。

Automation Support

SBOMのコンポーネントデータを詳細かつ継続的に追跡しようとする企業は、そのデータを一貫性のある分かりやすいフォーマットで提供する必要があります。SBOMの最小要件における「Automation Support」のセクションでは、この問題に取り組んでいます。このセクションでは、組織の境界を超えてSBOMをやりとりする際に組織が使用しなければならない以下3つの報告フォーマットについて規定しています。

Software Package Data Exchange (SPDX)
CycloneDX
Software Identification (SWID) Tags

これらの報告フォーマットについては後ほど詳しく紹介しますが、NTIAがこれらのフォーマットを選択した理由は、それぞれが「人間が読める」「機械が読める」、そして「主要なデータフィールドについて相互運用性があり共通のデータ構文表現を使用している」という点にあります。

Practices and Processes

最後に、「Practices and Processes」のセクションでは、SBOMを、いつ、どのように更新して配信すべきかに関連する6つの要件が含まれています。

Frequency（頻度）：新しいビルドやリリースによってソフトウェアコンポーネントが更新された場合、新しいSBOMを作成しなければならない。
Depth（深さ）：SBOM作成者は、トップレベルのコンポーネントとその推移的（間接的）な依存関係の両方を含める必要がある。
Known Unknowns（既知の未知のもの）：SBOMに完全な依存関係グラフが含まれていない場合、SBOM作成者は、それが a)そのコンポーネントにはそれ以上の依存関係がないのか、b)依存関係の存在が「未知であり不完全である」のかを記すべきである。
Distribution and Delivery（配布と配信）：SBOMは、適切なアクセス許可と役割が与えられた状態で、タイムリーに利用可能でなければならない。
Access Control（アクセス制御）：SBOMの特定の要素を非公開にしようとする組織は、SBOMデータをユーザーのセキュリティツールに統合するための特定の許容範囲などに関するアクセス制御の条件を規定する必要がある。
Accommodation of Mistakes（誤りの許容）：SBOM作成に関する規制は明らかに新しいものであるため、SBOMの消費者は（意図しない）エラーや脱落に寛容であることが求められる。

SBOMのフォーマットと仕様

企業はSBOMをさまざまなフォーマットで作成し、公開することができます。ウェブサイトでSBOMを公開したい企業にとっては、HTMLが合理的な選択肢になるでしょう。SBOMが文書やソースコードに含まれる場合は、プレーンテキストがよりよい選択肢になるでしょう。さらに、Markdown、PDF、CSVなどのオプションもあります。

これらの一般的なフォーマットにくわえて、SPDX（Software Package Data Exchange）、SWID（Software Identification）タグ、Cyclone DXなど、SBOMを提供するために特別に設計された方法も存在します。前述のように、米国連邦政府に販売する組織は、バイデン政権のサイバーセキュリティ大統領令の条件にしたがい、SBOMをこれら3つのフォーマットのいずれかで伝達することが求められます。

SPDX

SPDXは、Linux Foundationが運営するプロジェクトで、SBOMに記載されている情報の共有・利用方法を標準化することを目的としています。SPDXには、コンポーネントの出所、ライセンス、セキュリティなどに関連するデータが含まれます。下の図は、SPDXドキュメントに含まれるデータの概要です。

SWIDタグ

Software Identificationタグ（略してSWID）は、ソフトウェア製品の構成要素を識別するための標準化されたXMLフォーマットです。SWIDタグには4つのタイプがあり、ソフトウェア開発ライフサイクル（SDLC）の異なるポイントで使用されます。

Corpus Tags（コーパスタグ）：インストール前の状態のソフトウェアコンポーネント（プレインストールソフトウェア）を識別し説明するためのタグです。NISTによると、コーパスタグは「ソフトウェアのインストールツールやプロセスへの入力として使用することを意図している」とされています。
Primary Tags（プライマリータグ）：プライマリータグは、インストール後のソフトウェア製品を識別し説明するためのタグです。
Patch Tags（パッチタグ）：その名のとおり、パッチを識別し説明するためのタグです（中核となる製品そのものではありません）。さらにパッチタグには、ほかの製品やパッチとの関係についての関連情報を含めることができます。
Supplemental Tags（補足タグ）：SWIDフォーマットでは、タグ作成者のみがコーパスタグ、プライマリータグ、パッチタグを修正することができます。補足タグは、ソフトウェアユーザーやソフトウェア管理ツールに、ライセンスキーや関係者の連絡先など、ローカルで有用な関連情報を追加する機能を提供します。

組織は、製品に含めるタグや特定のデータ要素を決定する際に、ある程度の柔軟性を持っています。SWIDの仕様では、いくつかの必須フィールドにくわえて、いくつかのオプションの要素や属性の概要が示されています。

最終的に、最小限の有効で適合したタグは、ソフトウェア製品の名称やタグIDなどと、それを作成した組織を説明するほんの一握りの要素のみを必要とします。SWIDタグのデータ要素に関する最も包括的で最新の情報については、ISO/IEC 19770-2:2015規格の全文をご覧になることをお勧めします。

Cyclone DX

Cyclone DXは、そのWebサイトによると、「アプリケーションのセキュリティコンテクストやサプライチェーンのコンポーネント分析に使用するために設計された、軽量のソフトウェア部品表（SBOM）規格」であるとされています。つまり、アプリケーションを構成するソフトウェアコンポーネントに関する重要な情報を提供することで、SPDXやSWIDなどのSBOMフォーマットと同様の目的を達成することを目的としています。

Cyclone DXは、4つのカテゴリーのデータをサポートしています。

Bill of Materialsメタデータ：サプライヤー、メーカー、コンポーネント、およびSBOMを作成するために使用されたツールなどの、アプリケーションや製品自体に関する情報
コンポーネント：ライセンス情報を含む、プロプライエタリおよびオープンソースコンポーネントの一覧
サービス：ソフトウェアが呼び出すことのできる外部API
依存関係：直接的および推移的（間接的）な依存関係

そのほかのSBOMフォーマット

SPDX、SWIDタグ、Cyclone DXが特に一般的ですが、SBOMの配信フォーマットはこれ以外にもあります。NTIAの「Survey of Existing SBOM Formats and Standards（既存のSBOMフォーマットと規格の調査）」レポートには、包括的なリストが掲載されています。

SBOMを作成するメリット

最近のアプリケーションは、さまざまなソフトウェアコンポーネント、依存関係、ライセンスが多数存在するため、それらを管理することは非常に困難です。SBOMがなければ、リスクアセスメントの実施、OSSライセンスのコンプライアンスに関するデューデリジェンス（コピーレフトライセンスのコンポーネントの特定など）、脆弱性の修正などのプロセスに、多くの時間と手間がかかります。

一方で、SBOMの存在はソフトウェアのサプライチェーンにおけるリスク管理に大きく貢献することができます。具体的には、SBOMは以下のような課題を支援することができます。

政府規制へのコンプライアンスの達成
潜在的な脆弱性を特定し、修正するプロセスの迅速化
オープンソースライブラリの使用に伴う帰属要求の遵守
サプライチェーンが曖昧なために発生する開発チームの作業負荷の削減
透明性を高めることによる消費者との信頼関係の構築
発売後における故障コンポーネントの特定と対処
監査におけるビジネス上の混乱の回避

SBOMの使用例

上記のような多くのメリットを考えれば、SBOMの作成は検討する価値があります。そのため、組織は常にすべての製品についてSBOMを作成すること（そして新しいリリースの際には更新すること）を推奨します。

とはいえ、SBOMが特に効果を発揮すると思われる具体的なユースケースがいくつかあります。

資金調達、M&A、IPO：SBOMの作成は、資金調達、M&A、IPOに伴う技術的なデューデリジェンスプロセスの重要な一部です。利害関係者は、製品やサービスに含まれるソフトウェアコンポーネントや、ライセンスコンプライアンス、セキュリティ、コード品質のリスクをより深く理解するために、これらの資料を要求することがあります。

規制遵守：前述のとおり、ソフトウェアのサプライチェーンセキュリティに関するバイデン政権の新しいサイバーセキュリティ大統領令では、連邦政府に製品を販売する組織に対してSBOMの公開を求めています。

お客さまからの要望：ソフトウェアサプライチェーン攻撃の防止が世界中の組織にとって重要になるにつれ、ソフトウェアの購入や更新のプロセスの一部としてSBOMを要求する企業が増加することが想定されます。

下位互換性：古いソフトウェアを大量に保有している企業では、OSSパッケージのアップデートが必要になることがあります。レガシー製品に搭載されているOSSの包括的な一覧があれば、これをより簡単に行うことができます。

SBOMを作成するためのツール

SBOMは、ビジネスを行ううえでますます重要な役割を果たすようになると考えてよいでしょう。しかし、SBOMを作成するために必要なデータ量を考えると、手動のプロセスでは非常に困難です。

FOSSAのようなソフトウェア構成分析ツールは、組織がSBOMを作成するうえで以下のような大きな役割を果たします。

包括的で正確なデータの提供
カスタマイズ可能なレポートフォーマットの提供
SBOM作成プロセスの主要なステップを自動化し、チームの時間を大幅に削減

SBOM：Software Bill Of Materialsとは？（フォーマット、ユースケース、ツールについて）