2月から社内でSBOM勉強会を開催しています。勉強会でSBOMのフォーマット（CycloneDX・SPDX）に関してまとめたのでブログにてアウトプットしています。国際標準規格であるSPDXと複数の情報をまとめることができるCycloneDXについて紹介しています。国内外の情報をもとにまとめています。
はじめに
ども！先月から継続的に社内でSBOM勉強会を開催しています。そちらでまとめた内容を記事にしていきたいと思います。
SBOMとは？
SBOMの概要については、以下の記事で紹介していますのでご参照ください。
今回は、具体的な仕様について解説していきたいと思います。
SBOM仕様
SBOM フォーマットは複数の団体が策定しておりますが、そのうちの代表的なフォーマットである CycloneDXと SPDXをメインにご案内いたします。
なお、サンプルを生成するにあたり、セキュリティスキャナの OSS である Trivy を使用しています。
CycloneDX
こちらのSBOM形式は、OWASPが提供しています。OWASPは、ソフトウェアのセキュリティ向上を目的としたNPO団体です。
背景・歴史
プロジェクトの歴史は、公式のこちらのページで参照することができます。
CycloneDXはもともと、OWASP dependency-trackで使用するために開発が2017年にスタートしました。OWASP dependency-trackは、継続的にプロジェクト監視・管理を目的としたツールになっています。継続的なSBOM作成・分析とOWASPが得意としているセキュリティスキャンを統合して、コンポーネントを分析します。
更新頻度としては、開発が始まった2017年のプロトタイプから一年に一度アップデートが行われています。
| バージョン | リーリス日 |
|---|---|
| CycloneDX 1.5 | 2023 年 6 月 26 日 |
| CycloneDX 1.4 | 2022 年 1 月 12 日 |
| CycloneDX 1.3 | 2021 年 5 月 4 日 |
| CycloneDX 1.2 | 2020 年 5 月 26 日 |
| CycloneDX 1.1 | 2019 年 3 月 3 日 |
| CycloneDX 1.0 | 2018 年 3 月 26 日 |
| プロトタイプ | 2017 年 5 月 1 日 |
対応しているBOM
CycloneDXが対応しているBOMに関しては、公式のこちらのページで参照することができます。
以下、主要なBOMをご案内します。
| 項目 | 内容 |
|---|---|
| Software Bill of Materials (SBOM) | コンポーネントとサービス、依存関係のインベントリ作成 |
| Software as a Service BOM (SaaSBOM) | SaaS の様々なcomponentやサービスを文書化HTTP,HTTPS,REST,GraphQL,MQTT に準拠 |
| Hardware BOM (HBOM) | IoT デバイスや産業用制御システムのハードウェアコンポーネントを文書化 |
| Machine Learning BOM(ML-BOM) | ソフトウェアに組み込まれた機械学習機能やデータセット、人工知能 (AI) モデルを文書化 |
| Operations BOM (OBOM) | ハードウェアや OS、ファームウェア、コンテナ、アプリケーション、ライブラリから構成されるランタイム環境全体を文章化 |
| Vulnerability Disclosure Report(VDR) | ソフトウェアの脆弱性とその対処計画のレポート |
| Vulnerability Exploitability eXchange(VEX) | 脆弱性についての詳細や緩和策の取り組みを文書化 |
出力形式
出力形式 (仕様) に関しては、公式のこちらのページで参照することができます。これらは CycloneDX オブジェクトモデルと呼ばれ、SBOM/SaaSBOM/OBOM/MBOM/VEX のユースケース向けに設計されています。
対応している出力フォーマットは、『JSON』『XML』『Protocol Buffers』の3種類です。
| 項目 | 内容 |
|---|---|
| Metadata | サプライヤー、開発者、SBOM ドキュメントが対象とするソフトウェアの範囲、SBOM ドキュメントを作成するために使用したツールやライセンス等の情報 |
| Components | ファーストパーティ及びサードパーティのソフトウェアコンポーネントのインベントリ |
| Services | SBOM ドキュメントが対象とするソフトウェアが呼び出す可能性のある外部 API の情報を提示 |
| Dependencies | コンポーネントと他のコンポーネント間の依存関係を提示 |
| Compositions | SBOM内における各構成要素（コンポーネント、サービス、依存関係を含む）と構成要素の完全性を提示 |
| Vulnerabilities | SBOM に含まれるサードパーティソフトウェアや OSS に存在する既知の脆弱性とその脆弱性の悪用可能性を提示 |
| Formulation | どのように製造、デプロイされたかを提示 |
| Annotations | 注釈がつけられる項目に追加のコンテキストを提供 |
| Extensions | CycloneDX における新しい機能の試行、特殊なユースケースや将来のユースケースのサポート |
特徴
CycloneDXの特徴としては、以下になります。
| 特徴 |
|---|
| セキュリティ管理を念頭に置いた SBOM フォーマット |
| 体系立てられたオブジェクトモデルであるため、学習と導入が容易 |
| 出力形式の拡張が可能であり、要件に応じた新しい機能を試行できる |
| 開発エコシステム（OWASP dependency-trackやGitHub） |
使用例
使用例に関しては、公式のこちらのページで参照することができます。その中でも代表的なものの概要をご案内します。
- ソフトウェアコンポーネントの構成要素とコンポーネント間の依存関係を記述
- ソフトウェアコンポーネントのライセンスを管理
- ソフトウェアパッケージを普遍的に見つけやすいようにするためにメタデータを PURL にて標準化
- CPE、PURL、SWID を用いてコンポーネントの既知の脆弱性を管理
- XML 署名、JWS、JSF による整合性と虚偽防止機能による信憑性の担保
- 親子関係にあるコンポーネントをネストしてアセンブリを形成
- 脆弱なコンポーネントに対して行われた修正や悪用可能性を記載
- セキュリティ勧告などの外部情報参照をサポート
SPDX（Software Package Data Exchange）
こちらのSBOM形式は、Linux Foundationが提供しています。Linux foundationは、2000年にOSSコミュニティに対する支援を目的として設立されています。現在では、Linuxだけでなく幅広いOSSの支援を行っています。
背景・歴史
背景・歴史については、公式のこちらのページで参照することができます。
2010年からスタートしているSBOMの仕様としては、最も古いものになります。継続的に開発が進んでおり、2021年には『ISO/IEC 5962』として国際標準仕様となりました。
各バージョンのドキュメントは、こちらで参照することができます。
| 歴史 | リーリス日 |
|---|---|
| SPDX 3.0-rc1 | 2023年 5月 |
| SPDX 2.3 | 2022年 8月 |
| SPDX 2.2 | 2020年 5月 |
| SPDX 2.1 | 2016年 8月 |
| SPDX 2.0 | 2015年 5月 |
| SPDX 1.2 | 2013年 10月 |
| SPDX 1.1 | 2012年 8月 |
| SPDX 1.0 | 2011年 8月 |
| 草案・プロトタイプ | 2010年 2月 |
出力形式
出力形式に関しては、公式のこちらのページで参照することができます。
対応している出力フォーマットは、『JSON』『YAML』『TAG:Value』『RDF:XML』の4種類です。
| 項目 | 内容 |
|---|---|
| Creation Information（必須） | サプライヤーがSBOM ドキュメントを提供し、利用者がSBOMドキュメントを活用するために必要な情報（SPDXバージョン、SBOMデータライセンス、作成者等）を提示するセクション |
| Package Information | SBOM内にて、製品、コンテナ、コンポーネント等をグループ化するために必要な情報を提示するセクション |
| File Information | 製品、コンテナ、コンポーネント等のファイルに関する情報（名称、チェックサム、ライセンス、著作権等）を提示するセクション |
| Snippet Information | あるファイルが他のリソースから生成されている場合に使用するセクション |
| Other Licensing Information | SPDXライセンス一覧以外のライセンス情報（プロプラ言えたりソフトウェアによる制限等）を提示することが可能 |
| Relationships | SBOM内における製品、コンテナ、コンポーネント等のファイルやパッケージの関係を提示するセクション |
| Annotations | SBOMをレビューし、そのレビュー結果から得た情報を他社へ交友するために使用されるセクション |
特徴
SPDXの特徴としては以下になります。
| 特徴 |
|---|
| SBOM作成対象となるソフトウェアとして、スニペットやファイルにとどまらず、パッケージ、コンテナ、OSディストリビューションまで拡張可能 |
| SBOMドキュメントとして作成された成果物は、提供されたハッシュ地を使用することでSBOM化データ改ざん有無を検証することが可能 |
| 知的財産とライセンス情報のための豊富なリスト（SPDXライセンス）を持つ |
| 他のパッケージ参照システムやセキュリティシステムと連携することが可能 |
| 複雑なシステムに関連するドキュメントを論理的に分割し、SBOMドキュメントの各セクションや項目で管理することが可能 |
使用例
使用例に関しては、公式のこちらのページで参照することができます。
- システムの構成要素と構成要素間の関係性を記述する
- ソフトウェアコンポーネントの知的財産（ライセンス、著作権）を管理する
- ソフトウェアサプライチェーンのリスクアセスメントとコンポーネントを検証する
- ソフトウェアコンポーネント、コンテナコンテンツ等のインベントリーを作成する
- ソースファイルやソーススニペットに遡って実行ファイルを追跡する
- ファイルに埋め込まれたコードの出所を特定する
- ソフトウェアを一位に特定するためのフォーマットであるCPE,SWHD（SoftWare Heritage persisitent IDentifiers）、パッケージURL当を特定のパッケージに関連付け、追加のセキュリティ分析を容易にする
SBOMの導入の際には
CycloneDXは、SBOMとしての最小要素を満たしつつ、他のBOMとの互換性やセキュリティ情報を統合することができます。また、SBOM内に拡張性を持っており、追加の情報を含める必要性があるような使用方法もサポートしています。
SPDXは国際標準規格を取得しており、SBOMの規格としては最も歴史が長いです。
SBOMの導入・運用に関しては、経済産業省が「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引」として公開されています。こちらの資料の「3. SBOM 導入に関する基本指針・全体像」では、導入プロセスと全体像という文脈で、SBOM導入の際にまとめるべきポイントとして整理されています。
米国家安全保障局（NSA）が公開している「SBOM管理のための推奨事項（Recommendations for SBOM Management）」では、SBOMツールとしては、すべてのSBOMフォーマットに対応していることが理想的であるとしています。
以上のことから、SBOM 導入にあたって事前に以下のような点を整理いただくとよいものと考えます。
| SBOMを用いて何を管理したいか |
|---|
| SBOMを用いて何を管理したいか？ |
| 継続的にSBOMの作成・管理を行うことができるか？ |
| SBOMを用いてセキュリティリスクを軽減する仕組みを実現することができるか？ |
実際のプロジェクト管理の観点で、セキュリティ管理とSBOMについて近い位置で議論を行う必要があります。
おわりに
経産省の資料にもありますが、SBOM導入前にSBOM導入によってもたらせられる効果などを整理して効果的に導入する必要があります。SBOM導入がゴールではなく、SBOMを用いてセキュリティインシデントを事前に防止することが目的です。
今後は、ツールの紹介が続きますが前提を忘れないように意識していきたいです。
