SBOMフォーマットについて見ていく
2025.02.18おはようございます( ◜◡◝ )
ゲームソリューション部/業務効率化ソリューション部のきだぱんです。
最近、 「SBOM（エスボム）」 という言葉を耳にする機会が増えてきたのではないでしょうか？
SBOMは「ソフトウェアにおける部品表」として注目を集めており、昨今のサイバーセキュリティ対策において重要な役割を果たしています。
前回のブログでは、SBOMの基本について書いてました。
今回は、SBOMのフォーマットについて、見ていきたいと思います。
そもそもSBOMとは
SBOMは 「Software Bill of Materials」 の略で、日本語では「ソフトウェアの部品表」と呼ばれています。
分かりやすく例えると、食品の原材料表示のようなものです。製造業での部品表（BOM）の考え方をソフトウェアの世界に応用したもので、ソフトウェア製品に含まれるすべての構成要素とその依存関係を一覧化したものとなります。
昨今のソフトウェア開発現場では、以下のような課題が顕在化しています
- オープンソースソフトウェアの利用拡大
- サプライチェーンの複雑化
- サイバー攻撃の巧妙化
- コンプライアンス要件の厳格化
これらの課題に対して、SBOMは透明性を確保し、効率的なリスク管理を実現する強力なツールとして注目されています。
また、2021年5月に発出された米国大統領令（EO14028）において、政府調達におけるSBOM活用の検討指示が明記されたことをきっかけに、米国規制当局を中心とした取引組織へのSBOM整備の義務化など、SBOMが急速に普及しつつあります。
日本でも経済産業省により産業分野ごとのSBOM導入に向けた議論や実証実験が始まるなど、普及に向けた取り組みが進んでいます。
国際取引では納入先からSBOMの提供を求められる事例の増加が今後見込まれるため、受託企業やソフトウェアベンダーはSBOMに関する知見の整理、並びにSBOM作成・共有のためのツールの選定を実施することが望まれます。
ソフトウェア管理に向けた SBOM（Software Bill of Materials）の導入に関する手引 ver 2.0
SBOM必要な要素
SBOMには具体的に何を含めるべきなのでしょうか。
NTIAが定義する「最小コンポーネント要素」は、この問いに対する重要な指針を提供しています。
NTIAの定義によると、SBOMの基本要素は3つの主要カテゴリーに分類されます。
「データフィールド」「実践とプロセス「自動化のサポート」です。
-
「データフィールド」
- コンポーネント名、サプライヤー名、バージョン、一意の識別子などの基本情報が必要です。
- サプライチェーン全体を通じたコンポーネント間の依存関係も明確に記録する必要があります。
- サプライヤー名
- コンポーネント名
- コンポーネントのバージョン
- その他の一意な識別子
- 依存関係
- SBOM 作成者
- タイムスタンプ
-
「実践とプロセス」
- SBOMの作成・更新方法、配布方法、アクセス管理、そしてエラー処理に関する標準的な手順を定義することが求められます。
- 一貫性のある管理と運用が可能となります。
-
「自動化のサポート」
- 大規模なシステムや製品では、数十から数百にも及ぶコンポーネントを管理する必要があるため、機械可読性と自動生成機能は不可欠です。
- 標準化されたフォーマットが必要となります。
- SBOM の作成頻度
- SBOM の深さ
- 既知の未知14
- SBOM の共有
- アクセス管理
- 誤りの許容
ソフトウェア管理に向けた SBOM（Software Bill of Materials）の導入に関する手引 ver 2.0 より
現在、SBOMの標準フォーマットとしては、SPDX、CycloneDX、SWID tagsの3種類が広く認知されています。
SPDXとCycloneDXが頻繁に活用されており、これらのフォーマットについて理解を深めることが重要です。
SBOMフォーマット
SPDX
System Package Data Exchange (SPDX)は、長年にわたりソフトウェア部品のコンプライアンス管理に活用されてきたフォーマットです。
2021年の米国大統領令（EO #14028）で推奨フォーマットの一つとして言及されて以降、事実上の標準として位置づけられています。
特筆すべきは、V2.2.1がISO/IEC 5962:2021として国際標準化されていることです。
RDF、XML、JSON、YAMLなど、多様なファイル形式をサポートしており、特にライセンス情報の管理において優れた機能を提供しています。
SBOM「最小要素」に対応するSPDXの項目
| SBOM「最小要素」のデータフィールド | 対応するSPDXの項目 |
|---|---|
| サプライヤー名 (Supplier Name) | PackageSupplier |
| コンポーネント名 (Component Name) | PackageName |
| コンポーネントのバージョン (Version of the Component) | PackageVersion |
| その他の一意の識別子 (Other Unique Identifiers) | DocumentNamespaceとSPDXIDの組合せ、ExternalRef |
| 依存関係 (Dependency Relationship) | Relationship (DESCRIBES; CONTAINSによる表現) |
| SBOM 作成者 (Author of SBOM Data) | Creator |
| タイムスタンプ (Timestamp) | Created |
CycloneDX
CycloneDXは、OWASPプロジェクトにより2017年に開発された、セキュリティに特化したBOM規格です。
完全な自動化を念頭に置いて設計されており、ソフトウェアだけでなく、SaasBOM、HBOM、OBOMなど、多様なユースケースに対応可能です。
XML、JSON、Protocol Buffersなどのフォーマットをサポートしており、特にセキュリティ関連の情報管理において強みを発揮します。
「最小要素」に対応するCycloneDXの項目
| SBOM「最小要素」のデータフィールド | 対応するCycloneDXの項目 |
|---|---|
| サプライヤー名 (Supplier Name) | component/supplier/name |
| コンポーネント名 (Component Name) | component/name |
| コンポーネントのバージョン (Version of the Component) | component/version |
| その他の一意の識別子 (Other Unique Identifiers) | serialNumber, component/cpe |
| 依存関係 (Dependency Relationship) | dependencies/dependency ref |
| SBOM 作成者 (Author of SBOM Data) | metadata/authors/author/name |
| タイムスタンプ (Timestamp) | metadata/timestamp |
これら二つのフォーマットは、それぞれに特徴があり、、組織の目的や用途、状況に応じて適切な選択をすることが重要です。
実務での運用においては、両フォーマットに対応できる柔軟な管理体制を構築することをお勧めします。
SBOMは本質的に、組織間で情報をやり取りするためのフォーマットです。
そのため、社内でのデータ管理においては、両フォーマットの要件を満たすデータ項目を網羅的に収集・保持することが賢明です。必要に応じて適切なフォーマットでSBOMを生成することが可能となります。
SPDXとCycloneDX間の相互変換ツールも存在しており、これらを活用することで、より柔軟な運用が可能となります。
組織のニーズや外部からの要求に応じて、適切なフォーマットでSBOMを提供できる体制を整えることが、今後ますます重要となるでしょう。
試しに一つSPDXフォーマットで生成した結果をおいておきます。
こちらのファイルで試しています。
> snyk sbom --format=SPDX-2.3+json > SPDX-2.3_mysbom.json
> {
"spdxVersion": "SPDX-2.3",
"dataLicense": "CC0-1.0",
"SPDXID": "SPDXRef-DOCUMENT",
"name": "xxx@xxxx",
"documentNamespace": "https://snyk.io/spdx/sbom-",
"creationInfo": {
"licenseListVersion": "3.19",
"creators": [
"Tool: Snyk SBOM Export API v1.106.2",
"Organization: Snyk",
"Tool: Snyk snyk-cli 1.1294.2"
],
"created": "2025-02-16T11:39:29Z"
},
"packages": [
{
"name": "juice-shop",
"SPDXID": "SPDXRef-1-juice-shop",
"versionInfo": "12.3.0",
"supplier": "NOASSERTION",
"downloadLocation": "NOASSERTION",
"filesAnalyzed": false,
"licenseConcluded": "NOASSERTION",
"licenseDeclared": "NOASSERTION",
"copyrightText": "NOASSERTION",
"externalRefs": [
{
"referenceCategory": "PACKAGE-MANAGER",
"referenceType": "purl",
"referenceLocator": "pkg:npm/juice-shop"
}
]
},
.
.
.
ここからテストが可能です。
おまけ
ちなみに、、、
ツールの選定について、SBOM関連のツールは様々あります。
そんな中の一つ、SnykもSBOM対応しています！！！
以下も併せてご覧いただければと思います。
おわりに
SBOMの実装においては、必要最小限の要素を確実に含めつつ、組織の要件や将来の拡張性を考慮した柔軟な設計が重要となります。
適切なフォーマットの選択と、効果的な管理体制の構築により、持続可能なソフトウェアサプライチェーン管理を実現することができます。
SBOMに関するブログも展開されています。
以下も併せてご覧ください。
この記事がどなたかのお役に立てば幸いです。
以上、きだぱんでした。
![[Snyk] SBOM testためしてみた](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-d557403e71b019583b913fe2f75fb18f/617c320524fa80242fbf959b508fdec7/eyecatch_Synk)
