SBOMの2大フォーマット「SPDX」「CycloneDX」の違いとは？：解決！OSSコンプライアンス（10）
OSSコンプライアンスに関するお悩みポイントと解決策を具体的に紹介する連載「解決！ OSSコンプライアンス」。今回は、協力会社を巻き込んだ開発で重要性を増す、話題のSBOMと標準フォーマットを詳しく解説します。
本連載では、オープンソースソフトウェア（OSS）の利活用に伴う「ライセンスリスク」と、それをマネジメントするための活動である「OSSコンプライアンス」について取り上げ、エンジニアの方がOSSをスムーズに利用するための実務上の勘所や、これから戦略的にOSSを活用していきたいと考えている企業の方へのヒントとなる情報を紹介しています。
今回からは、「SBOM（Software Bill of Materials：ソフトウェア部品表）」についての本格的な解説に入ります。SBOMは、広義では「ソフトウェアのリスト」あるいは「OSSのリスト」です。本連載でも、これまでに社内でOSSのリストを管理しながらプロジェクトを進行する場面がありました。
しかし、複数のパートナー企業と協力して、サプライチェーンにおけるコンプライアンスおよびセキュリティ担保の取り組みを進めるには、情報内容や記述形式の統一、さらには既存標準の活用が求められるようになってきます。
今回は、そうした狭義のSBOMを管理する場面を見ていきます。
なお、本連載では、特に記載がない限り日本国内でOSSを活用する場合を前提としており、本連載の執筆チームの経験に基づいて説明を記載しています。厳密な法解釈や海外での利用など、判断に迷う場合は専門家にご相談ください。
■今回の登場人物
新城くん 日本のソフトウェア開発会社X社で働く入社3年目の開発者。 佳美先輩のもとでOSS活用に関する経験を積み、大規模プロジェクトのメンバーに抜擢（ばってき）された。
神田さん 新城くんがモジュールの開発を委託しているY社の担当者。前回登場した蒲田さんの同僚で、ソフトウェア開発経験を見込まれて新たにSBOMの管理を任されることになった。Y社は開発の一部をZ社に再委託している。
エピソード15 SBOMって、何をどうやればいい？
新城くんは前回、Y社に開発を委託しているBモジュールとCモジュールについてのOSSのリスト、すなわちSBOMの提供を、同社にお願いしました。次の日、Y社の神田さんからメールを受け取りました。そこには、「できるだけ早く顔合わせのミーティングがしたい」とあります。そこで新城くんは、早々に神田さんとオンライン会議を開催します。挨拶も終わったころ、神田さんから「さっそく相談したいことが」と切り出されます。
送付したSBOMの内容でよかったか、気になりまして。Bモジュール用のSBOMは、OSSの名前、バージョン、ライセンスの情報を整理しています。
一方、Z社から受け取ったCモジュール用のSBOMは、ダウンロードしたプログラムファイルの名前とライセンスのみで、ダウンロードしたプログラムファイル名の中にOSSの名前とバージョンらしき情報が入っているようだ、ということですね。
ええ、記述形式をそろえたかったのですが、確認したところ、御社向けのSBOMのフォーマットや作成手順が見当たりませんでした。
当社から提供できていなかったかもしれません。形式が不ぞろいのままだと、製品全体として一元管理する時にデータの手直しなどの手間がかかるところでした。SBOMのフォーマットと作成手順を整理して、後ほどお送りします。
管理項目名と書式が分かれば、それに従ってSBOMを作成します。
管理項目名と書式も合わせてご案内します。ソフトウェアの取得手段は必要です。弊社で確認する場合があるかもしれませんので。
OSSの取得手段には、パッケージ管理ツールを利用して取得するものと、そうではないものがありますが。
パッケージ管理ツールを使った場合は、そのパッケージ管理ツールの種別、パッケージリポジトリでのソフトウェアパッケージの登録名、バージョンを明確にします。パッケージ管理ツールを使わずにダウンロードした場合はファイル名やURLを記述します。
ライセンスコンプライアンスの観点では、どのような情報が必要になりますか？
ライセンス名、著作権に関する情報、そして、ライセンス文言に関する情報も必要です。
解説：サプライチェーン管理のため、SBOMにどう取り組むか
商用提供する製品やサービス、あるいは自社で利用するソフトウェアやサービスについて、それを構成するソフトウェアの部品表をSBOMと呼びます。本連載ではこれまで「OSSリスト」という言葉を使ってきましたが、これはSBOMをOSS利用の側面から表現したものだと言えます。SBOMは、OSSだけではなく、商用ソフトウェアや独自の経路で入手したソフトウェアなどを管理対象に含む場合があります。
SBOMは、食品の成分表示に例えられることがあります。「どのようなソフトウェアで構成されているのか」が分かれば（透明性）、避けたいものを判別できます。また、「どこから調達してどこで利用しているのか」を管理できれば（追跡性）、何か問題があったときに対処の方針が立てやすくなります。
このため、サプライチェーンにおいてOSSのサプライヤーとなる場合は、OSSの適切な利用を示すためにも、SBOMの管理・運用と提供に取り組む必要があります。契約に基づいてSBOMを利用する場合は、委託元と委託先とで、何のためにどのような管理項目が必要になるのか、また、SBOMの提供・更新の時期や頻度などについての、双方の合意が重要になります。
なお、ライセンスコンプライアンスのために必要な情報については、第6回「OSSライセンスの『クリアランス』ってどういうこと？ 具体的にどうやればいい？」をお読みください。
データ項目と記述形式の例
それでは、データ項目と記述形式について、ライセンスコンプライアンスに関する部分を見ていきます。ここでは情報項目をカテゴリごとに表にしてみました。実際には、人が作業しやすいようにスプレッドシートを用いたり、あるいは、データ処理を優先してYAMLやJSONなどを用いることがあるかもしれません。いずれの手段を用いる場合でも、相互に変換できるような仕組みを導入すると良いです。
下記は、「SPDX」と呼ばれるSBOMフォーマットで定義されている情報項目の例です。あくまでも例であり、SPDXで定義されている情報項目を網羅しているわけではありません。また、SPDX以外のSBOMフォーマットの違いについては後述します。
・ドキュメントとしてのSBOM管理に関する情報項目
まず、ドキュメントとしてのSBOMを管理するための情報の例を紹介します。なお、説明中の「SPDXドキュメント」とは「SPDXフォーマットで作成したSBOM」を意味します。
| データフィールド例 | 説明 |
|---|---|
| DocumentName | SPDXドキュメントの名称。通常は、このSPDXドキュメントが全体として対象とするソフトウェアの名称とバージョンを連結した文字列 |
| DocumentNamespace | SPDXドキュメントのユニークな識別情報。[DocumentName] とUUIDを構成要素とする |
| Creator: Organization | SPDXドキュメントを作成した組織の名称および問い合わせ用のメールアドレス |
| Creator: Tool | SPDXドキュメントの作成にツールを利用した場合、その名称とバージョン番号。SPDXドキュメントを手動で作成した場合の値は”NONE” |
| Created | SPDXドキュメントの作成日時 |
・ソフトウェアをパッケージ単位で管理する情報項目
次は、SBOMの中心的な内容ともいえる、ソフトウェアをパッケージ単位で管理する情報の例です。
| データフィールド例 | 説明 |
|---|---|
| PackageName | ソフトウェアパッケージの名称 |
| SPDXID | 同一のSPDXドキュメント内でユニークな識別情報 |
| PackageVersion | ソフトウェアパッケージのバージョン |
| PackageFileName | ソフトウェアパッケージのダウンロードファイル名 |
| PackageSupplier | ソフトウェアパッケージの提供者名 |
| PackageDownloadLocation | ダウンロードファイルを取得する場合のURLや、VCS（Version Control System）のロケーションなど |
| ExternalRef | 外部で参照可能な情報。例えば、パッケージ管理ツールを利用してソフトウェアパッケージを取得する場合は、そのロケーションなど。それ以外では、関連する脆弱性情報の参照先など |
| PackageChecksum | ハッシュ値は所定のアルゴリズムにより生成されたもの。改ざんの検証に利用する |
| PackageLicenseConcluded | ソフトウェアパッケージに適用されるライセンスのうち、リリースに関係するとして判断したもの |
| PackageLicenseInfoFromFiles | ソフトウェアパッケージを分析して検出されたライセンスの情報 |
| PackageLicenseDeclared | ソフトウェアパッケージの著者が宣言しているライセンス情報 |
| PackageLicenseComments | SPDXドキュメントの作成者による、ソフトウェアパッケージのリリースに関係するライセンスとして判断した根拠や検討に関するメモなど |
| PackageCopyrightText | ソフトウェアパッケージの著作権者 |
| PackageComment | SPDXドキュメントの作成者による、ソフトウェアパッケージに関するメモなど |
| Relationship | SPDXIDで識別されるソフトウェアパッケージ同士の関係を明らかにする。依存関係や、動的や静的などのリンク種別などを記載する |
上記の全ての項目を利用することもあれば、取引先からの指定に従って一部のみを使う場合もあり、逆に項目を追加する場合もあるでしょう。
SPDXとCycloneDX、2大フォーマットの特徴と違い
SBOMに共通の形式を用いることで、ソフトウェアサプライチェーンにおけるSBOMの相互運用性を高めることができます。SBOMについては、標準的なフォーマットとして、「SPDX」「CycloneDX」「SWID（ISO/IEC 19770-2:2015）」などが知られています。このうち、オープンスタンダードとして知られるものはSPDXとCycloneDXです。以下では、この2つのフォーマットの動向を簡単に紹介します。
SPDXは、Linux FoundationのSPDX Workgroupが開発しているSBOMフォーマットです。SPDXはオープンソースのライセンスコンプライアンスに関連する情報を扱うために開発が始まったもので、「パッケージ」「ファイル」「スニペット」の粒度でソフトウェア部品を管理できます。
SPDXはサブセットとして「SPDX Lite」を定義しています（SPDX Specification Annex G）。SPDX Liteはパッケージ単位での管理に焦点を当てており、スプレッドシートなどのアプリケーションで管理運用する場面を想定して設計されています。SPDXはV2.2.1が国際標準化されており（ISO/IEC 5962:2021）、ISO（国際標準化機構）の「Publicly Available Standard」からISO版の「SPDX Specification」（SPDX仕様）を入手できます。SPDX Workgroupは国際標準化以降もコミュニティー版の仕様改訂を続け、SPDX V2.3を2022年8月にリリースしました。この改訂は、後述するSBOMの最小要素に対応するためのものです。SPDX WorkgroupではSBOMの利便性向上に向けて、次期仕様となるV3.0の議論も進めています（spdx-techメーリングリスト）。
一方、CycloneDXは、Open Web Application Security Project（OWASP） Foundation が開発する、セキュリティを念頭に置いたSBOMフォーマットです。コンポーネント間の関係や、ソフトウェアが呼び出す可能性がある外部APIとの関係といった、ソフトウェアとサービスのデータの流れなども記述できます。
最新の仕様であるCycloneDX 1.4（2022年1月リリース）は、オブジェクトモデルに “vulnerabilities”を追加しているのも特徴の一つです。これは、「VEX（Vulnerability Exploitability Exchange） 」、つまり脆弱（ぜいじゃく）性の影響に関する情報を交換するためのモデルです。VEXを利用して、ソフトウェア製品が構成コンポーネント（部品）の特定の脆弱（ぜいじゃく）性の影響を受けるかどうか、また、影響を受ける場合にはどんな是正策が推奨されるか、といった情報を提供することが期待されています。
SPDXとCycloneDXのいずれのフォーマットも、ソフトウェア構成解析（Software Composition Analysis：SCA）のOSS／商用ツールによるサポートが進んでいます。
ライセンス管理におけるSPDXの活用
ライセンス情報の管理・運用については、SPDX Workgroupによる成果の活用が便利です。
SPDX Specificationでは、ライセンスの「Full Name（正式名）」とそれに対応する「Identifier（識別子）」を整理したライセンスリスト（”SPDX License List”） をAnnex Aとして記載しています。一方でSPDX Workgroupは、このライセンスリストを定期的に更新し、別途掲載していますので、後者の最新版を見ると良いでしょう。
また、Annex D “SPDX license expressions”は、2つ以上のライセンスが関係する場合の表現を定めています。例えば、2つのライセンスのどちらかを選択するならば、その間に“OR”を置き、いずれも同時に満たす必要がある場合は“AND”を置くなどです。
さらに、Annex E “Using SPDX license list short identifiers in source files” で言及される、Free Software Foundation Europe （FSFE）のREUSE Specificationは、ソースコード中に著作権情報やライセンス情報などを表現するための記法を定めたものです。この記法は、人が読み書きできることはもちろん、機械処理が可能な手段として設計されています。そのため、LinuxカーネルやLinuxディストリビューションをはじめ、多くのOSSプロジェクトで、このREUSEに沿った記法の採用が進んでいます。REUSEのように機械処理も可能な形式を活用すると、ツールでソースコードをスキャンし、対応する情報をSBOMのデータフィールドを示すタグと関連付けることで、ライセンスコンプライアンスに関連する情報を含むSBOMを自動生成しやすくなるなどの利点があります。
セキュリティを目的とした、NTIAによるSBOMの「最小要素」とは
SBOMに関する議論が活発になったのは、米国で”Executive Order 14028”（サイバーセキュリティ強化のための大統領令） が2021年5月に発行されたことにあります。これにより、製品やサービスにおけるソフトウェア部品の透明性確保のためにSBOMの管理・運用の重要性があらためて意識されることとなりました。
同国では、この大統領令を受けてNTIA（米国商務省電気通信情報局）が “The Minimum Elements for a Software Bill of Materials （SBOM）” （PDF）を同年7月に公開しました。この文書では最小要素となるデータフィールド、つまり最低限記述すべき項目を定めています。さらに、先に挙げた3つのSBOMフォーマットのいずれかの利用を求めると共に、これらの相互運用性を求めています。
下に、この最小要素のデータフィールドをまとめました。なお、表中のカッコ内および説明は筆者による参考日本語訳です。
- 最小要素のデータフィールド
| SBOM Minimum Field | Description （説明） |
|---|---|
| Author Name（SBOMの作成者） | SBOM記載事項の作成者（サプライヤーとは限らない） |
| Supplier Name（サプライヤー名） | SBOM記載事項にあるコンポーネントの提供者の名称又は識別情報 |
| Component Name（コンポーネント名） | オリジナルのサプライヤーが定めたソフトウェア単体の名称 |
| VersionString（コンポーネントのバージョン） | コンポーネントを識別するためのバージョン |
| Component Hash（コンポーネントのハッシュ値） | コンポーネントをユニークに識別するための暗号化ハッシュ値 |
| Unique Identifier（その他の一意な識別子） | コンポーネントの識別や関連するデータベースのルックアップキーとして利用できるユニークな識別情報 |
| Relationship（依存関係） | 上流コンポーネントXがソフトウェアYに含まれる関係性の特徴 |
| Timestamp（タイムスタンプ） | SBOMデータを作成した日時の記録 |
次の表は、最小要素のデータフィールドに対応するSPDXとCycloneDXのデータフィールドです。
- 最小要素のデータフィールドへのSPDXおよびCycloneDXの対応づけ
| NTIA SBOM Minimum Field | SPDX | CycloneDX |
|---|---|---|
| Author Name | （6.8） Creator Tag; “Creator:” |
metadata/authors/author |
| Supplier Name | （7.5） Package Supplier Tag: “PackageSupplier:” |
Supplier publisher |
| Component Name | （7.1） Package Name Tag: “PackageName:” |
name |
| Version String | （7.3） Package Version Tag: “PackageVersion:” |
version |
| Component Hash | （7.10） Package Checksum Tag: “PackageChecksum:” |
Hash “alg” |
| Unique Identifier | （7.2） Package SPDX Identifier Tag:“SPDXID:” （6.5） SPDX Document Namespace Tag: “DocumentNamespace:” |
bom/serialNumber component/bom-ref |
| Relationship | （11.1） Relationship: CONTAINS, DESCRIBES The document must DESCRIBES at least one package. Tag: “Relationship:” |
（Inherent in nested assembly/subassembly and/or dependency graphs |
| Timestamp | （6.9） Created Tag: “Created:” *ISO 8601標準によりUTCで記載 |
metadata/timestamp |
上の2つの表を見てみると、ライセンスコンプライアンスで必要な、ライセンスや著作権に関する情報は含まれていないことが分かります。2つの表の情報はまさにSBOMの核となる最小要素であって、必要に応じて拡張して利用することになります。そのため、SBOMをライセンスコンプライアンスで用いる場合は、先の最小要素にライセンスや著作権などに関する情報を追加して運用します。
CycloneDXからSPDXに変換する場合、幾つかの要素は対応するデータフィールドの値に置き換えることができます。一方で、先に見たようなCycloneDXのVEXに対応するデータフィールドをSPDX v2.3は持ちません。そのため、SPDXでVEXを扱うには、外部参照を指定する "ExternalRef" を活用して解決します。
SBOMは、開発段階に応じた運用が必要
SBOMは、サプライチェーンで提供する形態に応じて作成し、管理することが重要です。ソフトウェアの開発状態に合わせて、ビルド前のソフトウェアを対象とする “pre-build SBOM”、ビルドやパッケージの時点でのソフトウェアを対象とするSBOMを “Build SBOM”、そして、ビルド後にできた成果物を対象とするSBOMを “post-build SBOM” と呼ぶことがあります。また、ソースコードのままを対象とするSBOMを ”Source SBOM”、ビルド後のバイナリを対象とするSBOMを ”Binary SBOM” と呼ぶ場合もあります。
ソースコードには「テストコード」「ビルド時のみ利用するコード」「ビルド時の条件によって取り込むコード」が異なる場合があります（*1）。SBOMを作成する場合は、開発からリリースまでのどの段階のものか、そして、対象に必要なものだけを含む、といったことに注意しましょう。
*1 ビルド時に指定する条件の例として、ターゲットになるCPUを指定する、組み込むアルゴリズムや機能を指定する、特定のライセンスが適用されているライブラリを組み込まないようにする、などがある。
SBOMは、提供するソフトウェアの構成内容を正しく反映している必要があります。そのため、利用ソフトウェアに変更があった場合は、SBOMも更新する必要があります。これに関連して気をつけたいのは、パッケージ管理ツールを介してOSSを利用するケースです。直接利用するOSSがさらに依存するOSSを利用し、それが連鎖する場合がよくあります。手元の開発環境で直接に利用するバージョンを固定しても、パッケージ管理ツールを介してビルドしようとすると、依存しているOSSに変更が発生していることがあり得ます。
そのため、SBOMの作成はCI/CDと連携させて、できるだけビルド時に生成すると良いでしょう。また、パッケージ管理ツールがロック（lock）機能を提供している場合は、それを活用して、依存しているものの一覧とそのバージョンを固定して管理するのも良いでしょう。これは、複数の開発者がいる場合に環境を再現する目的でよく用いられる手法の一つでもあります。
NTIAが発行した“The Minimum Elements for a Software Bill of Materials（SBOM）” は、最小要素として、先のデータフィールドの他に2つの要素を挙げています。
1つは ”Automation Support” です。スケールするソフトウェアエコシステムに対応するために、機械可読性のあるSBOMを自動生成することや、先に触れた3つのSBOMフォーマットの利用を求めています。
もう1つは“Practice and Process”です。SBOMの要求、生成そして使用にかかわる運用を定めるべきとしています。より具体的には、「頻度（frequency）」「深さ（depth）」「既知の未知（known unknown）」などの項目が例示されています。
SBOMを作成して提供する側、受領して利用（消費）する側、それぞれの立場での運用については、同じくNTIAが公開する”Software Suppliers Playbook: SBOM Production and Provision”や”Software Consumers Playbook: SBOM Acquisition, Management, and Use”などが参考になります。これ以外でも、NTIAにおけるSoftware Component Transparencyの取り組みや関連する公開資料は、必要に応じて見ておくと良いかもしれません。日本でも、経済産業省がサイバー・フィジカル・セキュリティ確保に向けたソフトウェア管理手法等検討タスクフォースで、SBOMの管理・運用の検討や実証実験などを進めています。
なお、一定期間の試験評価のみを目的としてSBOMを運用するような場合や、定期的にSBOMを更新して管理する計画がある場合は、その利用目的や有効期限を管理項目とする運用も検討すると良さそうです。
また、SBOMを単体として管理するのではなく、集合的に扱う構成管理データベースを活用すると良いでしょう。こうしておくと、過去の確認結果や利用実績を照合できるため、ライセンスコンプライアンスのレビューや承認を効率化したり、既に利用しているソフトウェアについて新たな問題が発覚した際の影響範囲を把握しやすくなります。
次回は、SBOMの生成を支援するツールや、ライセンスコンプライアンス以外のSBOM活用事例を見ていきます。
Copyright © ITmedia, Inc. All Rights Reserved.