ソフトウェア部品管理
ソリューション

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

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

• 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.（ソフトウェアの一部からそのコンポーネントおよび潜在的なサブコンポーネントへの移行性を表現することができる）」とされています。

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

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

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

最後に、「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の消費者は（意図しない）エラーや脱落に寛容であることが求められる。

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

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

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

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

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