「手書きでOK」製造業のSBOM第一歩。TOPPERSパッケージでの実践入門ガイド

SBOMはソフトウェアの部品表であり、サプライチェーンの透明性とリスク管理を支える必須ドキュメントです。本コラムではまずハードウェアBOMとの共通点とSBOMが求められる背景を整理し、SPDX Liteという手書き可能な軽量仕様に焦点を当てます。TOPPERS ASP3パッケージを題材に、SPDXファイルの基本構造からライセンス記述、依存関係の記載まで実践的に作成手順を示し、spdx.devでの検証やSBOMツールの活用方法も紹介します。さらにSPDX v2とv3の仕様差や移行判断のポイントまで把握でき、自社製品のSBOM作成に即活用できる知識が得られます。

1. BOM（Bill of Materials）—構成部品を明らかにすること

組込みシステムの開発に従事していれば、BOM（Bill of Materials）ファイルという、Excelなどで作成されたファイルをみたことがあるでしょう。日本語に直訳すると、BOMは「部品表」でしょうか。BOMは、ボードのSchematic（回路図）と同様に開発者間や部門間（設計／製造／購買）で共有されます。マイコンベンダーが販売する評価・開発用の商品ボードでもBOMが公開されることが多いので、このファイルを見たことがあるでしょう。

ハードウェアのBOMは、製品を構成する材料や部品のリストです。料理の素材や成分一覧のような存在です。同じハードウェアの再生産（量産）にBOMは必須です。

BOMの主目的は構成部品の可視化ですが、以下のリスク管理の意義もあります。

• 部品の生産・サポート終了（EOL）のリスクへの対応
• 部品の不具合情報の追跡

産業機器の場合、コンシューマ向け機器と異なり10年以上の長期供給保証が基本です。いきなりの製造中止・供給停止に対して、互換性のある代替部品によるリスクヘッジも長期供給のためには重要な課題です。部品の不具合のエラッタ情報を監視し続けることも重要です。

2. SBOM（Software Bill of Materials）—ソフトウェアの部品提示の要請

前例のないソフトウェアの製造技術・品質管理の技術(ソフトウェア工学）は、既存のハードウェア製造技術を前例として参照します。現在SBOM（Software Bill of Materials）というソフトウェアの部品表が注目されていますが、参照したのはハードウェアのBOMです。

SBOMが注目され始めたのは、2021年に米国で発令された大統領令（EO 14028）です。この大統領令により、政府が調達するソフトウェアにはSBOMの提出を求められたのです。この引き金となったのが、国際情勢の悪化やそれを背景にした度重なるサプライチェーンに対するサイバー攻撃でした。米国発の調達ルールは欧州、日本、そして民間企業にも浸透してきています。民間産業においても医療、航空、車の自動運転など、人命に関わるリスクが大きいソフトウェアの調達ルールとしてSBOMの提出が求められてきています。

2-1. 組込みシステム開発文化の変容

書き換え不可のROMに書き込んで機器に組込むソフトウェアの開発は、とても保守的でした。ブートストラップコードから、RTOSのような実行環境、デバイスドライバやアプリケーションに至るまで、全て自社で開発する文化がありました（フルスクラッチ開発）。コンパイラにバイナリで付属するC標準ライブラリでさえ、品質が確認できないソフトウェアの汚染と捉える最右翼の風潮もありました（ライブラリレス・プログラミング）。

しかし、組込み機器の機能が複雑化・多様化したことで、一社で全てのソフトウェアを開発するには限界を迎え、サードパーティのプロプライエタリライセンスのソースコード（SDK）を購入して、自社の核心となるソフトウェア開発にコストを投入するようになります（ハーフスクラッチ開発）。

その後、OSS（オープンソースソフトウェア）の塊である組込みLinuxが組込み機器で使われるようになりました。これは、多機能なシステムの開発に要するコスト・時間と、OSSの再利用による恩恵をトレードオフした結果です。 このようにOSSに対するアレルギー体質も改善されていく流れのなかで、今は多くのマイコンベンダーがOSSのみで構成したSDKを提供しています。しかし、OSSの利用には次のようなリスクが存在します。

• 無償で配布されるOSSはソースコードが公開されており、潜在するセキュリティホールへの攻撃リスクが存在する。セキュリティホールが報告された直後には、悪意のある攻撃にさらされてしまう、いわゆるゼロデイ・アタックのリスク。
• ソフトウェアのバグ（不具合）ゼロは不可能であり、バグはセキュリティホールとなるリスクがある。セキュリティホールを利用したサプライアへの攻撃で、悪意があるソフトウェアが混入される可能性がある。
• プロプライエタリライセンスであった商用ソフトウェアも、突然の供給停止（EOL）や買収によるOSS化のリスクが存在する。
• OSSにはコピーレフトのような、閉鎖的な企業のソフトウェア開発とは相性が良くないライセンスで使用許諾されるものある。コピーレフトライセンスは、秘匿性の高い自社ソフトウェアに感染するリスクがある（ソースコードの開示義務の汚染）。

2-2. SBOM管理の意義とSBOMの種類

このようなリスクを踏まえると、ソフトウェアの受け入れ側が「納品物のソフトウェア部品の構成を明らかにして欲しい」と求めるのは合理的といえます。特に国防、国家・企業機密、人命に関わる分野であれば、その必要性は高まるでしょう。

SBOMは、納品物の透明性をその一覧性で明らかにします。SBOMの意義を以下に示します。

• 製品を構成するソフトウェアを一覧できるようにする。これにより、リスクがあるライセンスソフトウェアを排除することができる。
• ソフトウェアに不具合があった場合、また脆弱性が指摘された場合、その影響度を計ることができる。
• ソフトウェアのバージョンアップによる変更箇所を追跡可能にする。
• ソフトウェアの開発・サポート停止のEOLリスクを管理可能にする。

SBOM管理には、このような利点があります。では、SBOMにはどのような種類があるのでしょうか？ 次に3つの代表的なプロジェクトをリストします。

2-3. PDXと軽量版SPDX Liteの仕様について

上記リストの中でも、ソフトウェアパッケージのライセンス・バージョン・依存関係に特化したSBOMとして、SPDXが代表的な存在と考えます。本コラムでは、SPDXと軽量なSPDX Liteについて解説します。

SPDX仕様にはv2系とv3系が存在します。このうち、v3系はSPDXの可用性を高めるためにドキュメントの概念モデルが大きく変更されており、複雑で手書きで記載することは困難な内容になっています。そのため、本コラムではv2系（最新v2.3)を解説しています。

下記は、SBOMツールでNXP社が公開しているMCUXpresso SDKに含まれるSPDXファイルのアウトラインを表示させた内容です。

>bom document outline SBOM.spdx.json
               _
 ___ _ __   __| |_  __
/ __| '_ \ / _` \ \/ /
\__ \ |_) | (_| |>  <
|___/ .__/ \__,_/_/\_\
    |_|

 📂 SPDX Document mcuxsdk-examples-v25.09.00
  │
  │ 📦 DESCRIBES 1 Packages
  │
  ├ mcuxsdk-examples@v25.09.00
  │  │ 🔗 16 Relationships
  │  ├ DYNAMIC_LINK PACKAGE FlowLayout (Example)@1.2
  │  ├ DYNAMIC_LINK PACKAGE Android Arch-Common@2.0.0-alpha1
  │  ├ DYNAMIC_LINK PACKAGE AssertJ@1.2.0
  │  ├ CONTAINS PACKAGE Amazon FreeRTOS@202012.01
  │  ├ DYNAMIC_LINK PACKAGE AWS SDK for Android - AWS IoT@2.22.3
  │  ├ CONTAINS PACKAGE FatFs Module@R0.15
  │  ├ CONTAINS PACKAGE ARM-software/CMSIS-DSP@v1.16.1
  │  ├ CONTAINS PACKAGE lwIP@2.2.1
  │  ├ CONTAINS PACKAGE NXPmicro/rpmsg-lite@v5.1.2
  │  ├ CONTAINS PACKAGE mbed TLS@v3.6.4
  │  ├ CONTAINS PACKAGE FreeRTOS Real Time Kernel@V11.1.0
  │  ├ CONTAINS PACKAGE systemview-target@0.1.1
  │  ├ DYNAMIC_LINK PACKAGE Android ConstraintLayout Solver@1.1.3
  │  ├ DYNAMIC_LINK PACKAGE AssertJ for Android Design Support@1.2.0
  │  ├ CONTAINS PACKAGE cJSON@1.7.15
  │  └ CONTAINS PACKAGE rangehttpserver@1.2.0
  │
  └ 📄 DESCRIBES 0 Files

このように、SDKに含まれるソフトウェア部品（パッケージ）の一覧を可視化してくれます。

SPDXは、テキストファイルとして汎用エディタで記載することができます。記述文法はTag-Value、JSON、RDF、XML、YAMLで記述可能です。ハードウェア基板のBOMで使われるスプレッドシート（xls、xlsx）形式もサポートしています。

2-4. SPDXドキュメント構造（v2系）

SPDXのドキュメント構造を下図に示します。
（The Software Package Data Exchange® (SPDX®) Specification Version 2.3）

SBOMは、ツールによる自動生成を原則としています。SPDXもテキストファイルで記述できますが、自動生成を要求しています。SPDXでファイル単位の詳細な情報を含めることも可能ですが、作成・管理に大きなコストがかかり、マイコンシステムのような小規模プロジェクトには負担が少なくありません。そこで、SPDXのサブセットで必要最低限な項目に絞ったSPDX Liteの登場となります。

2-5. 手書きを前提としたSPDX Liteの仕様

SPDX Liteは、汎用エディタを使った手書きが可能な軽量仕様です。テキストファイルは、SPDX独自のTag-Valueに加えて、JSON/RDF/XML/YAMLの標準文法で記載可能です。また、Excelなどのスプレッドシートも使えます。

2-6. SPDX v2.3 付録 G.3（SPDX Liteのデータフィールド）

SPDX Lite仕様では、個別のファイル情報は含めません（含めてはいけません）。FilesAnalyzedは、falseにする必要があります。

2-7. SPDXライセンス記述（著名なオープンソースライセンスの場合）

SPDX仕様は、既知のオープンソースライセンスの識別名（IDentifier）を決めています。（参照：https://spdx.org/licenses/ ）

ライセンスIDをソースコードコメント行に、規定の形式に沿って記載すると、SPDXスキャンツールでライセンスを自動抽出してくれます。以下は、FreeRTOSのコメント例です。

* FreeRTOS Kernel V11.0.1
* Copyright (C) 2021 Amazon.com, Inc. or its affiliates.  All Rights Reserved.
*
* SPDX-License-Identifier: MIT

SPDXファイルのパッケージのライセンス情報は、Package Informationブロックに記載します。PackageLicenseDeclared はライセンスが宣言されていたことを示し、PackageLicenseConcluded は最終的にこのライセンスを判断したことを示します。

以下は、Tag-Value形式の記述例です。

## Package Information
PackageName: Amazon FreeRTOS
PackageVersion: V11.0.1
PackageLicenseConcluded: MIT
PackageLicenseDeclared: MIT

2-8. SPDXライセンス記述（SPDX IDに登録されていないライセンス）

TOPPERSライセンスのような、SPDX標準ライセンス（周知のライセンス）のリストにない独自のライセンスの場合、独自の識別子をドキュメント内に定義します。慣例として、LicenseRef-<任意の名称>と記述します。

可能であれば、そのSPDX文書内にライセンス条文を貼り付けます。

2-9. SPDXライセンス記述（プロプライエタリなライセンスの場合）

商用ソフトウェアの場合は、独自にエンドユーザ利用規約（EULA）を締結します。商用ソフトウェアパッケージを含む場合は、例えばLicenseRef-[企業名または製品名]-Proprietaryのように表記すれば、プロプライエタリライセンスであると識別できます。

別の方法として、NOASSERTIONと簡易的な表記にする方法もあります。

3. TOPPERSパッケージのSPDX Liteファイルを書いてみよう（実践編）

OSSとして公開されているTOPPERSパッケージのSBOMファイルを、SPDX（v2.3） Liteで作ってみましょう。文法は可読性の良いTag-Value形式で書いています。

TOPPERSの配布パッケージには MANIFESTというファイルが同梱されていて、パッケージのバージョンを確認することができます。このファイルはパッケージの成分表の役割をしていますが、SPDXファイルを記述するために多くの内容を追加する必要があります。

TOPPERSライセンスは、SPDXの公式ライセンスリスト（MITやApache-2.0など）に登録されていません。そのため、SPDXの慣例に従い LicenseRef-TOPPERS という独自のライセンスIDとして記述します。

まずドキュメントヘッダを作成します。

SPDXVersion: SPDX-2.3
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
DocumentName: SPDX-TOPPERS-ASP3-3.7.1
DocumentNamespace: http://spdx.org/spdxdocs/TOPPERS-ASP3-3.7.1
Creator: Organization: Ubiquitous AI Corporation Embedded System Division 2()
Created: 2026-08-01T00:00:00Z

ドキュメント名、SPDX仕様バージョン(2.3)、データライセンスバージョン(1.0)、作成者情報を記載します。一意のドキュメント名前空間としてサーバをホストして公開している場合はそのURLを指定します。そうでない場合、今回は慣例に従い以下のフォーマットを指定しています。

http://spdx.org/spdxdocs/<任意のドキュメント名>

続いてパッケージ情報を記載します。

##### Package情報: TOPPERS ASP3パッケージ
PackageName: TOPPERS ASP3
SPDXID: SPDXRef-Package-asp3
PackageVersion: 3.7.1
FilesAnalyzed: false
PackageDownloadLocation: NOASSERTION
PackageLicenseConcluded: LicenseRef-TOPPERS
PackageLicenseDeclared: LicenseRef-TOPPERS
PackageComment: <text>TOPPERS ASP3パッケージ 3.7.1</text>
PackageCopyrightText: NOASSERTION

SPDX 2.3 Liteのルールでは、これを false に設定します。これは、PackageVerificationCode（ファイル毎の検証コード）の記載を省略（NOASSERTION）する意味です。これにより、手書き運用に最適な最小記載することが可能になります。

SPDXフル仕様で運用する場合、手書き運用は推奨されていないため、ツールで自動生成する必要があります。

次に、当該パッケージを構成するパッケージをRelationship情報として記載します。TOPPERSパッケージに内包されたパッケージはMANIFESTファイルに記載されているので、それを記載します。

内包されるパッケージは、TOPPERSコンフィグレータ、テストパッケージ、拡張パッケージです。

# asp3 内蔵コンポーネント依存関係（内包）の定義
Relationship: SPDXRef-Package-asp3 CONTAINS SPDXRef-Package-cfg
Relationship: SPDXRef-Package-asp3 CONTAINS SPDXRef-Package-tecsgen
Relationship: SPDXRef-Package-asp3 CONTAINS SPDXRef-Package-test
Relationship: SPDXRef-Package-asp3 CONTAINS SPDXRef-Package-test-cfg
Relationship: SPDXRef-Package-asp3 CONTAINS SPDXRef-Package-extension
Relationship: SPDXRef-Package-asp3 CONTAINS SPDXRef-Package-target-dummy-gcc

内包しているパッケージの情報も記載しておきます。

##### Package: 内蔵コンポーネント1 (cfg)
##### TOPPERSコンフィグレータ(内蔵ツール)
PackageName: asp3-cfg
SPDXID: SPDXRef-Package-cfg
PackageVersion: 1.7.0
FilesAnalyzed: false
PackageDownloadLocation: NOASSERTION
PackageLicenseConcluded: LicenseRef-TOPPERS
PackageLicenseDeclared: LicenseRef-TOPPERS
PackageCopyrightText: NOASSERTION

##### Package: 内蔵コンポーネント1 (tecsgen)
##### TOPPERS　TECSジェネレータ(内蔵ツール)
PackageName: asp3-tecsgen
SPDXID: SPDXRef-Package-tecsgen
PackageVersion: 1.8.0
FilesAnalyzed: false
PackageDownloadLocation: NOASSERTION
PackageLicenseConcluded: LicenseRef-TOPPERS
PackageLicenseDeclared: LicenseRef-TOPPERS
PackageCopyrightText: TOPPERS Project TECS WG

##### Package: 内蔵コンポーネント2 (test)
PackageName: asp3-test
SPDXID: SPDXRef-Package-test
PackageVersion: 3.7.1
FilesAnalyzed: false
PackageDownloadLocation: NOASSERTION
PackageLicenseConcluded: LicenseRef-TOPPERS
PackageLicenseDeclared: LicenseRef-TOPPERS
PackageCopyrightText: NOASSERTION

##### Package: 内蔵コンポーネント3 (test_cfg)
PackageName: asp3-test-cfg
SPDXID: SPDXRef-Package-test-cfg
PackageVersion: 3.7.1
FilesAnalyzed: false
PackageDownloadLocation: NOASSERTION
PackageLicenseConcluded: LicenseRef-TOPPERS
PackageLicenseDeclared: LicenseRef-TOPPERS
PackageCopyrightText: NOASSERTION

##### Package: 内蔵コンポーネント4 (extension)
PackageName: asp3-extension
SPDXID: SPDXRef-Package-extension
PackageVersion: 3.7.1
FilesAnalyzed: false
PackageDownloadLocation: NOASSERTION
PackageLicenseConcluded: LicenseRef-TOPPERS
PackageLicenseDeclared: LicenseRef-TOPPERS
PackageCopyrightText: NOASSERTION

##### Package: 内蔵コンポーネント5 (target/dummy_gcc)
PackageName: asp3-target-dummy-gcc
SPDXID: SPDXRef-Package-target-dummy-gcc
PackageVersion: 3.7.1
FilesAnalyzed: false
PackageDownloadLocation: NOASSERTION
PackageLicenseConcluded: LicenseRef-TOPPERS
PackageLicenseDeclared: LicenseRef-TOPPERS
PackageCopyrightText: NOASSERTION

文書内でLicenseRef-TOPPERSの識別子で参照しているライセンス情報を記載しておきます。

TOPPERSライセンスの条文は、日本語と英文が公開されています。この例では、ExtractedText に英語条文を貼り付けています。

## Other Licensing Info
LicenseID: LicenseRef-TOPPERS
ExtractedText: <text>
<Name of Software>

Copyright (C) <Year> by <Copyright Holder 1>
Copyright (C) <Year> by <Copyright Holder 2>
...

 The above copyright holders grant permission gratis to use,
 duplicate, modify, or redistribute (hereafter called use) this
 software (including the one made by modifying this software),
 provided that the following four conditions (1) through (4) are
 satisfied.

 (1) When this software is used in the form of source code, the above
     copyright notice, this use conditions, and the disclaimer shown
     below must be retained in the source code without modification.

 (2) When this software is redistributed in the forms usable for the
     development of other software, such as in library form, the above
     copyright notice, this use conditions, and the disclaimer shown
     below must be shown without modification in the document provided
     with the redistributed software, such as the user manual.

 (3) When this software is redistributed in the forms unusable for the
     development of other software, such as the case when the software
     is embedded in a piece of equipment, either of the following two
     conditions must be satisfied:

   (a) The above copyright notice, this use conditions, and the
       disclaimer shown below must be shown without modification in
       the document provided with the redistributed software, such as
       the user manual.

   (b) How the software is to be redistributed must be reported to the
       TOPPERS Project according to the procedure described
       separately.

 (4) The above copyright holders and the TOPPERS Project are exempt
     from responsibility for any type of damage directly or indirectly
     caused from the use of this software and are indemnified by any
     users or end users of this software from any and all causes of
     action whatsoever.

 THIS SOFTWARE IS PROVIDED "AS IS." THE ABOVE COPYRIGHT HOLDERS AND
 THE TOPPERS PROJECT DISCLAIM ANY EXPRESS OR IMPLIED WARRANTIES,
 INCLUDING, BUT NOT LIMITED TO, ITS APPLICABILITY TO A PARTICULAR
 PURPOSE. IN NO EVENT SHALL THE ABOVE COPYRIGHT HOLDERS AND THE
 TOPPERS PROJECT BE LIABLE FOR ANY TYPE OF DAMAGE DIRECTLY OR
 INDIRECTLY CAUSED FROM THE USE OF THIS SOFTWARE.
</text>
LicenseName: TOPPERS
LicenseComment: <text>This is the TOPPERS License</text>

以上でTOPPERS/ASP3の共通パッケージのSPDX Liteファイルの作成は完了です。

3-1. TOPPERS ハードウェア依存部パッケージ情報の追記

ここでは、特定のハードウェアへのポーティングパッケージを記載する例を示します。

題材として、STマイクロエレクトロニクス社のNUCLEO H563ZI評価ボード用パッケージを使いました。Arm^Ⓡ Cortex^Ⓡ-M共通パッケージとSTM32H563ZIパッケージ情報を追加します。

# ARMv7,8-M,STMicro NUCLEO H563ZI依存部のパッケージ（追加）
Relationship: SPDXRef-Package-asp3 CONTAINS SPDXRef-Package-asp3-arch-arm-m-gcc
Relationship: SPDXRef-Package-asp3 CONTAINS SPDXRef-Package-asp3-nucleo-h563zi-gcc

NUCLEO H563ZI依存部のパッケージには、Arm社のCMSISヘッダファイル、 STマイクロエレクトロニクス社のHALドライバを含んでおり、これらはBSD（3条項）とApache2.0ライセンスのファイルを含んでいます。このライセンスのファイルが含まれていることを記載し、パッケージとしてはTOPPERSライセンスであることを記載しました。

##### Package: 内蔵コンポーネント (ARMv7,8-M依存部)
PackageName: TOPPERS ASP3 Cortex-M GCC
SPDXID: SPDXRef-Package-asp3-arch-arm-m-gcc
PackageVersion: 3.6.0
FilesAnalyzed: false
PackageDownloadLocation: NOASSERTION
PackageLicenseConcluded: LicenseRef-TOPPERS
PackageLicenseDeclared: LicenseRef-TOPPERS
PackageCopyrightText: NOASSERTION

##### Package: 内蔵コンポーネント (STMicro NUCLEO H563ZI依存部依存部)
### ARM社のCMSISヘッダ、STMicroが作成したHALドライバを含む
PackageName: TOPPERS ASP3 STMicro NUCLEO H563ZI GCC
SPDXID: SPDXRef-Package-asp3-nucleo-h563zi-gcc
PackageVersion: 20250325
FilesAnalyzed: false
PackageDownloadLocation: NOASSERTION
PackageLicenseConcluded: LicenseRef-TOPPERS
PackageLicenseDeclared: LicenseRef-TOPPERS
PackageLicenseDeclared: BSD-3-Clause
PackageLicenseDeclared: Apache-2.0
PackageCopyrightText: NOASSERTION

3-2. spdx.devのオンラインツールで検証する

手書きで作成したSPDX Liteファイルを、spdx.devのオンラインツール（Webサービス）で検証してみます。

構文エラー、記載に矛盾、過不足がある場合はエラー箇所が表示されるので、Cプログラムのコンパイルエラーを修正するように、SPDXファイルを修正します。SPDXコミュニティの公認ツールなので、信頼性は高いです。

ここでは、Kubernetes projectが公開するbomコマンドを使い、アウトラインを表示させてみました。SBOM全体像を俯瞰することができます。

SPDX標準化団体が提供する検証ツールは、信頼性が高いです。検証機能の他に、下記の機能を使うことができます。

• SPDX v2フォーマット間の相互変換機能（Eg:Tag-Value からJSON構文への変換）
• SPDX v2 vs SPDX v3 JASON-LD機能の相互変換機能

C:\SBOM>bom document outline toppers_asp3_nucleo.spdx
               _
 ___ _ __   __| |_  __
/ __| '_ \ / _` \ \/ /
\__ \ |_) | (_| |>  <
|___/ .__/ \__,_/_/\_\
    |_|

 📂 SPDX Document SPDX-TOPPERS-ASP3-3.7.1
  │
  │ 📦 DESCRIBES 1 Packages
  │
  ├ TOPPERS ASP3@3.7.1
  │  │ 🔗 8 Relationships
  │  ├ CONTAINS PACKAGE asp3-cfg@1.7.0
  │  ├ CONTAINS PACKAGE asp3-tecsgen@1.8.0
  │  ├ CONTAINS PACKAGE asp3-test@3.7.1
  │  ├ CONTAINS PACKAGE asp3-test-cfg@3.7.1
  │  ├ CONTAINS PACKAGE asp3-extension@3.7.1
  │  ├ CONTAINS PACKAGE asp3-target-dummy-gcc@3.7.1
  │  ├ CONTAINS PACKAGE TOPPERS ASP3 Cortex-M GCC@3.6.0
  │  └ CONTAINS PACKAGE TOPPERS ASP3 STMicro NUCLEO H563ZI GCC@20250325
  │
  └ 📄 DESCRIBES 0 Files

3-3. SBOMフリーツールの紹介

ここでは、無償で公開されているSPDXのフリーツールを紹介します。

SPDX公認ツール

まずは標準化団体Linux Foundationのspdx.devプロジェクトは各種ツールを公開しています。検証ツールや各種フォーマット間のSPDX変換ツールをWebサービスとして公開しています。
▶ SPDX – Linux Foundation Projects Site

SPDX標準化団体が提供する検証ツールは、信頼性が高いです。検証機能の他に、下記の機能を使うことができます。

• SPDX v2フォーマット間の相互変換機能（Eg:Tag-Value からJSON構文への変換）
• SPDX v2 vs SPDX v3 JASON-LD機能の相互変換機能

Kubernetes project bomコマンド

Kubernetesプロジェクト（kubernetes-sigs/bom）は、SPDX準拠SBOM生成・管理するコマンドラインツールを提供しています。このツールはgo処理系で動作します。
▶ https://github.com/kubernetes-sigs/bom

Windowsにgoをインストールした後、以下のインストールコマンド実行でインストールします。

go install sigs.k8s.io/bom/cmd/bom@latest

Microsoft sbom-tool

マイクロソフト社もコマンドシェル、パワーシェルで動作するsbomコマンドを公開しています。インストール方法を以降に記載しました。
▶ https://github.com/microsoft/sbom-tool

winget install Microsoft.SbomTool

4. SPDX v3.0についての考察

SPDX v2系は、v2.3が最終版として位置づけられており、現在は主にメンテナンスフェーズにあります。標準化団体spdx.devの活動は主にv3系が対象となります。

SPDXのver2から最新のver3への進化には大きな変更があり、とても複雑になっています。v2がライセンス管理中心の静的な単一ファイル形式であるのに対して、v3ではAIやセキュリティ、ビルド工程などの用途に対応できるよう拡張されています。この理由から、SPDXv2（Software Package Data Exchange）からSPDX v3は、System Package Data Exchangeへと略称の意味を変えています。以下にその相違を示します。

• データモデルの違い
  • v2：1つのSPDXファイル中にすべての情報を詰め込む一体型構造。
  • v3：データ要素をドキュメントから独立させ、相互にリンク（関係）するグラフ構造をとっています。この仕様により、部分的なデータ交換や再利用が容易な仕様となっています。またオブジェクト指向のクラス、属性、関係(継承)の概念を理解する必要があります。
• 対応可能な問題領域の拡張
  • v2：プログラムのライセンス・著作権・バージョンの管理に特化している。
  • v3：プログラム管理に加え、セキュリティ脆弱性、AI・機械学習のデータセット、ビルド・プロベナンスなど多目的に対応。
• プロファイルの導入
  • v2：すべての仕様がモノリシックに一体化している。(単一プロファイル)
  • v3：コア仕様（基本）に加え、セキュリティやライセンスなどのプロファイルと呼ぶ単位に機能分割されており、必要な機能だけを選択・拡張できる。なお、SPDX v2の補足仕様であるSPDX LiteはLiteプロファイルとして本編に組み込まれました。
  • Understanding SPDX Profiles
• 記載フォーマットの違い
  • v2：独自のTag-Value形式やJSON、YAML、XML形式などのテキストファイルで対応可能。Lite仕様では汎用エディタによる手書き記載・運用も可能。またExcelなどのスプレッドシートも使用可能です。
  • v3：JSON-LD（JSON for Linked Data）に統一されました。実質汎用エディタによる記載・運用は不可能です。

では、SPDX v3系への移行は早急に検討が必要なのでしょうか？

5. すぐにSPDX v3へ移行すべきか？

SPDX v3への移行を急ぐ必要はない、と考えます。SPDX v3は可用性の拡大により仕様が複雑になっており、汎用エディタによる「手書きで」「気軽に運用」とはいきません。

そのため、SPDX v3に移行する必要性があるのは、次のようなケースと考えます。

• 開発の委託元会社やソフトウェアパッケージの納品先がSPDX v3のツールを導入しており、SPDX v3形式のSBOMファイルの提示を求めている。
• 輸出先の法令規則により、機器に対して脆弱性情報（VEX）を含めた高度なSBOMの提出が義務付けられた。セキュリティプロファイルを持つv3への変換・出力が必要になる。
• 組込みLinuxベースの開発を行っており、最新のYoctoプロジェクトのビルド環境を使用する必要がある。最新Yoctoでは、SPDX v3が唯一の選択肢となっています。

もし、納品先から「SPDX ver3.0形式で出してほしい」と要求された場合は、自分たちで複雑なJSON-LDをエディタで書こうとせず、これまでのTag-ValueテキストまたはExcelで入力し、自動でv3形式のJSON-LDに変換してくれるSPDXコミュニティ公式のWebサービスや変換スクリプトを利用するだけで対応可能です。

といった運用を行うことができるのであれば、特に組込みシステムの分野においては、問題はないと考えます。

6. SBOM管理 ことはじめ —まとめ

2021年の米大統領令（EO 14028）に呼応するように、欧州サイバーレジリエンス法（CRA）などグローバルな枠組みでSBOMを要求する法制化が進んでいます。 分断された世界情勢を背景に、サプライチェーンのリスク排除の必要性に迫られたからです。

日本におけるSBOMの法令化ですが、義務化には至っていないものの、国際標準に合わせたガイドラインが整備されています。とりわけ重要な社会資本や特定業界向けには、実質的な要請が急速に進んでいる状況といえます。経済産業省は、日本の企業へのSBOM管理の啓蒙と導入を円滑にするために、「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 」を公開しています。

人命に関わる機器の製造に直接かかわる企業、社会インフラ産業、重大な国内製造産業はもちろん、コンシューマ機器ですらインターネットに繋がる場合はセキュリティ侵害のリスクに晒されています。サプライチェーンに組み込まれている企業にとってSBOM管理はもはや他人事ではなく、早期の取り組みが求められています。

SBOMの社内教育、管理体制構築、デバイス開発におけるCI/CDプロセスへのSBOM管理の統合を検討し始めましょう。

より詳しく技術や​関連製品について​知りたい方へ

本コラムに関係する技術や関連する製品について知りたい方は、お気軽にご相談ください。

お問い合わせはこちらから