SBOMフォーマット「CycloneDX」の中身

お世話になっております。株式会社　日立ソリューションズの中村と申します。

本日は、CycloneDX について理解を深めていただけるよう昨年投稿したCycloneDXの記事をより掘り下げて紹介したいと思います。

CycloneDXとは？

CycloneDXは、ソフトウェア開発に際するリスク対応において重要な役割を担うSBOM（Software Bill of Materials:ソフトウェア部品表）フォーマットの一つです。SBOMは、OSSやサードパーティソフトウェア、自社開発ソフトウェアなどさまざまなコンポーネントで構成されているソフトウェア開発ライフサイクルの安全性と透明性を保つために、米国大統領令や経済産業省によって使用が推奨されています。そして、CycloneDXはOWASPというオープンソース・ソフトウェアコミュニティのプロジェクトによって、2017年に開発された自動処理可能なセキュリティに特化したBOM規格です。

本記事の目的は、CycloneDXフォーマットの中身の説明を通して、CycloneDXの理解を深めていただくことです。したがって、本記事ではCycloneDXの概要的な説明は省略します。CycloneDXの概要について知りたい方はコチラをご参照ください。

BOM各種

CycloneDXはソフトウェア部品表（SBOM）だけでなく、ハードウェアなど９つの規格をサポートしています。こちらでは、それぞれの規格について紹介をします。

Bill of Materials （SaaSBOM）

SaaSBOMは、クラウドネイティブアプリケーションをサポートするサービス、エンドポイント、およびデータフローのインベントリとして機能します。Infrastructure-as-Code（IaC）を補完し、複雑なシステムを論理的に表現し、各サービスのインベントリ、ほかのサービスへの依存関係、エンドポイントのURL、データの分類、およびサービス間のデータフローの方向性などの詳細を提供します。
Hardware Bill of Materials （HBOM）

さまざまな組み込みデバイスを含む多様なコンポーネントをサポートするフォーマットです。これにより、従来のEBOM（Engineering Bill of Materials）およびMBOM（Manufacturing Bill of Materials）といったハードウェアデバイスに関する情報を効果的に扱うBOMのユースケースに最適です。
Machine Learning Bill of Materials （ML-BOM）（CycloneDX v1.5以上）

ML-BOM（Machine Learning Bill of Materials）は機械学習モデルとデータセットに透明性を提供し、これによりセキュリティ、プライバシー、安全性、および倫理的な考慮事項が可視化されます。CycloneDXは、モデルカードを標準化することで、モデルとデータセットのインベントリをHBOM、SBOM、およびSaaSBOMで定義されたソフトウェアやハードウェアコンポーネント、またはサービスのインベントリと独立して使用したり、組み合わせたりすることができます。
Operations Bill of Materials（OBOM）

OBOMは、ランタイム環境、厚生、および追加の依存関係のフルスタックのインベントリを提供します。
Manufacturing Bill of Materials （MBOM）（CycloneDX v1.5以上）

MBOMは、製品の製造方法を記述し、製品がハードウェア、ファームウェア、ソフトウェア、プロセス、およびテストをどのように組み合わせて最終製品を作成するかを文書化します。製品データの記録として機能し、ツールチェーンや製品のエコシステム、コード、コンポーネント、およびこれを可能にするプロセスのセキュリティの懸念や弱点を明らかにすることができます。
Bill of Vulnerabilities （BOV）

BOVは独占的に脆弱性データを含むことができ、これによりシステムや脆弱性インテリジェンスソース間でこの情報の交換が容易になります。これらのBOMは複雑な脆弱性の詳細を表現することができ、ソース、参照、複数の深刻度、リスク評価、具体的な詳細、推奨事項、影響を受ける製品、およびそれらの対応するバージョンを包括的に示すことができます。
Vulnerability Disclosure Report（VDR）

VDRは、コンポーネントとサービスに影響を与える既知／未知の脆弱性について通知します。また、ISO/IEC 29147:2018で定義された脆弱性開示情報のデータフィールド要件を上回っています。
Vulnerability Exploitability eXchange （VEX）

VEXは、脆弱なコンポーネントが使用されている製品のコンテキストにおける悪用の可能性を伝えます。VEXはVDRのサブセットです。製品が脆弱なコンポーネントを含んでいるだけで脆弱性の影響を受けないことがよくあります。VEXは、脆弱性の悪用可能性の状態を伝え、どの脆弱性がリスクを引き起こす可能性があるのかについて明確な情報を提供します。
Common Release Notes Format

リリースノートを共通の、機械可読なフォーマットに標準化します。この機能により、ソフトウェアの提供者と利用者の両方に新しいワークフローの可能性が開かれます。この機能は、仕様のBill of Materialsの機能の有無に関係なく動作します。

このように、CycloneDXはあまり耳馴染みのないようなBOMにも対応しており、多用途です。 SBOMフォーマットとしてはもちろん、さまざまな用途や状況に合わせて使用できるようなイメージです。

オブジェクトモデル

CycloneDXのフォーマットは、体系立てられたオブジェクトモデルで構成されています。このオブジェクトモデルをもとに、解析対象の製品の解析結果をそれぞれの項目に記載されていきます。
※各要素の説明はコチラをご参照ください。

必須項目

CycloneDXフォーマットの必須記載項目（v1.5）は、CycloneDXとしてのbomFormatとCycloneDXのバージョン（specVersion）です。 v1.4以下では、上記の二項目に加えて、BOMのバージョン（version）も必須項目とされています。したがって、解析対象の製品に前述したオブジェクトモデルの各項目に満たす要素が含まれない場合、その項目は無いものとして出力されます。

※出力結果をSBOMとして活用する場合は、米国NTIA（National Telecommunications and Information Administration）によって定義されたSBOMの最小要素を満たす必要があります。CycloneDXフォーマットでの必須項目とは異なります。

NTIA最小要素

米国NTIA（National Telecommunications and Information Administration）では、下記項目をすべて含むことが最小要件として定義されています。下の表は、NTIAで示された要件とCycloneDX上でのフィールド名の対応関係です。

要素	フィールド
Supplier	bom.metadata.supplier, bom.components[].supplier
Component Name	bom.components[].name
Component Version	bom.components[].version
Other Unique Identifiers	bom.components[].cpe,purl,swid
Dependency Relationship	bom.dependencies[]
Author of SBOM Data	bom.metadata.author
Timestamp	bom.metadata.timestamp

Identifier識別子

CycloneDXフォーマットで作成されたBOMの識別子として、serialNumber（シリアルナンバー）とversion（バージョン）があります。

serialNumber（シリアルナンバー）

それぞれのBOMにシリアルナンバーが割り当てられる。
version（バージョン）

デフォルトのバージョン値を１とし、必要に応じて更新される。

ライフサイクル機能

CycloneDXには、どのライフサイクルに生成された成果物なのか分析してくれる機能が備わっています。
※ライフサイクル機能はv1.5以降に追加された機能です。 SBOM作成ツールによってサポートしているフォーマットのバージョンが異なるため、ツールによっては使用できない機能となります。

CycloneDXのBOMにライフサイクルのフェーズを組み込むことで、BOMがいつ、どのように作成されたかというコンテキストがMetadataに追加されます。それにより、ライフサイクルのさまざまな段階でさまざまな種類のデータが利用できます。そのためBOMには、特定のライフサイクルに固有のデータや特定のライフサイクルでしか取得できないデータが含まれる場合があります。（SBOMの生成方法、SBOMに含まれるデータの正確性、サードパーティのソフトウェアコンポーネントに対する組織の依存関係の性質について）

↑の７つのポイントに分けられて、それぞれ扱われます。

フェーズ	説明
Design	含まれるであろうコンポーネントと外部サービスのインベントリを含むBOMを、開発の初期段階に生成する。
pre-build	ソースファイル、アーティファクト、マニフェストファイルなどを含む、ビルドする前に得られた情報で構成されるBOM。
Build	コンポーネントインベントリが使用可能な際にビルドの過程で得られた情報を含むBOM。解決されたコンポーネントの正確なバージョンと、それらがどこから取得されたかを示す出所も含まれる。
Post-build	ビルド後に得られた情報を含むBOM。CI／CDプロセスの結果である場合があり、システムやデバイスにインストールまたはデプロイされ、文書化および分析目的のためにシステムやデバイスからの検索や抽出を必要とする場合がある。
Operations	OBOMは、ステージングまたは本番環境を含む、実行中および運用中のインベントリを表す。基本的には複数のSBOMやハードウェアの部品表であるHBOMを含んでいる。
Discovery	ネットワークディスカバリによって生成されたBOM。組み込み、オンプレミス、クラウドネイティブなサービスのスナップショットをキャプチャする。これには、特定の時点におけるサーバー・アプリケーション、接続デバイス、マイクロサービス、サーバーレス機能が含まれる。BOMはこれらのサービスの一覧を提供し、ネットワークの現在の状態と構成に関する見識を提供する。
Decommission	運用から撤退する、または撤退したインベントリを含むBOM。

下図はライフサイクルを含むMetadataをxml形式で出力した場合の例です。
残念ながら、どのような値をいれるとどのフェーズとして判別されるのかわかるような具体例を提示することはできませんが、Metadataにどのように表示されるのか、少しでもイメージを持っていただけると幸いです。

inventory — *The image is from the https://cyclonedx.org/docs/1.5/xml/#type_metadata

Componentユースケース

※本章の内容はコチラのページをもとに作成されています。

インベントリ

Components内に、正確なインベントリが表示されます。下図がそのイメージです。

各コンポーネントのタイプが表示されます。

Application
Container
Data
Device（ハードウェア）
Device Driver
File
Firmware
Framework
library
Machine Learning Model
Platform（ソフトウェア実行環境）

コンポーネント識別子

コンポーネント識別子として下記の表記がサポートされています。

Coordinates：コンポーネントを構成するバージョンや名前など
Package URL（PURL）：異なるベンダーやプロジェクトにまたがるソフトウェアパッケージを一貫して識別および検出できるように、ソフトウェアパッケージのメタデータの表現方法を標準化したもの
SWIDタグ：ソフトウェア製品を識別し、そのメタデータを提供するための標準化された形式
CPE：ソフトウェアやハードウェアに割り当てられた識別子

この中のPURL、SWID、CPEは、各コンポーネントの脆弱性情報管理として使用することができます。

整合性検証

インベントリデータの整合性検証に関する仕組みがあります。

Hashes（ハッシュ値）：構成要素や関連するデータの内容に対するハッシュ値を計算。
整合性保護機能：ファイルの整合性を保護するためのデジタル署名をサポート

これらに対応することで、セキュリティや信頼性を向上させることができます。下図がイメージになります。

アーカイブのリンク — *The image is from the https://cyclonedx.org/guides/sbom/use_cases/

ライセンス情報

ライセンス情報は大きく二つに分けることができます。

OSSライセンス
商用ライセンス

商用ライセンスでは、ライセンス名だけでなく、組織名、ライセンスタイプなどの詳細情報も表記されます。

プロバナンス

ソフトウェアコンポーネントがどのようにして生成または取得され、どのような変更が加えられたかなどのソフトウェアコンポーネントの起源情報を表します。開発プロセスの可視化、コンプライアンス管理、セキュリティ調査、デプロイメントトラッキングなど、ソフトウェア開発ライフサイクル（SDLC）において、ソフトウェアコンポーネントに関する詳細な履歴を提供し、さまざまなコンテキストで役立ちます。

入れ子・系図

コンポーネントが複雑に入れ子になっている場合、その情報をわかりやすく表記します。下図がそのイメージ図になります。

nesting-genealogy-0 — *The image is from the https://cyclonedx.org/guides/sbom/use_cases/

また、解析されたコンポーネントの系図を可能な範囲で表記する機能も備わっています。

nesting-genealogy-1 — *The image is from the https://cyclonedx.org/guides/sbom/use_cases/

そのほか

そのほかにも、FOCI（Foreign ownership, Control, or Influence）への対応、Vendor Risk Managementのベンダーのリスク管理やSupply Chain Managementのサプライチェーン管理などさまざまなリスクに合わせた情報を提供できます。

Compositionsユースケース

Compositions（構成要素の完全性）には、依存関係（Dependencies）、関係性（relationships）、コンポーネント（Components）、サービス（Services）とその完全性が表示されます。

フェーズ	説明
complete	コンポーネント、サービス、依存関係や関係性を含むものがそれ以上存在しない。
incomplete	不完全。
incomplete_first_party_only	不完全で、ファーストパーティに関するそれぞれの関係性のみ表示されている。
incomplete_first_party_proprietary_only	不完全で、ファーストパーティのプロプライエタリに関するそれぞれの関係性のみ表示されている。
incomplete_first_party_opensource_only	不完全で、ファーストパーティのオープンソースに関するそれぞれの関係性のみ表示されている。
incomplete_third_party_only	不完全で、サードパーティに関するそれぞれの関係性のみ表示されている。
incomplete_third_party_proprietary_only	不完全で、サードパーティのプロプライエタリに関するそれぞれの関係性のみ表示されている。
incomplete_third_party_opensource_only	不完全で、サードパーティのオープンソースに関するそれぞれの関係性のみ表示されている。
Unknown	完全性が不確定。

加えて、前述したComponentsの入れ子コンポーネントの表記と同様、Dependenciesも入れ子表記が可能です。

補足ですが、混同しやすい依存関係（Dependencies）と関係性（relationships）は異なる要素です。 dependencies要素はコンポーネント自体が依存している外部のコンポーネントを記述しますが、relationships 要素は異なるコンポーネント間の関係性を表現します。

まとめ

CycloneDXは幅広い用途に使用可能なBOM規格である。
CycloneDXは体系立てられたオブジェクトモデルで構成されており、それぞれの項目に合わせたユースケースがある。
CycloneDXはセキュリティとソフトウェア開発ライフサイクルに合わせたフォーマットである。
ライフサイクル機能などの一部機能は、フォーマットのバージョンによっては備わっていない。そのため、SBOM作成ツールでCycloneDXフォーマットのSBOMを出力するとき、そのツールがサポート対象としているバージョンを確認する必要がある。

SBOMの代表的なフォーマットCycloneDXについての理解が深まり、使用イメージがもてましたでしょうか。前回のCycloneDXに関する記事では伝えきれなかった情報を伝えることに注力しました。少しでもCycloneDXについてのイメージを掴むことができましたら幸いです。また、CycloneDXの活用に関してお悩みをお持ちの方・SBOM活用に関してご支援を必要としている方は、本ページお問い合わせからお気軽にご連絡ください。

参考

• CycloneDX
• 経済産業省：SBOMの手引き
• OWASP
• NTIA
• SPDX
• FOCI（Foreign ownership, Control, or Influence）