SBOMフォーマット詳細解説

公開日：2026年5月11日

今回は、SBOMフォーマットについてのお話になります。

SBOMフォーマットには、IPA発行の「SBOM 導入・運用の手引き」の中に、「機械判読可能かつ相互運用可能なフォーマットを用いて作成し、共有する必要がある」と記載されています。

機械判読可能というのは、大規模な開発の場合、使用するコンポーネントが数百個になることがあり、手動で作成したり、管理するのは難しいため、ツールを使用することになりますが、その場合にどのツールでも読み込めるように、ルールを決めることが必要となります。
更に、ツールの使用を可能にすることで、SBOM作成の自動化サポートの側面もあります。

相互運用可能なフォーマットというのは、開発現場では、完成されたライブラリやドライバを入手して使用することがありますが、その際に、ライブラリやドライバに対して、主にツールを使用したコンポーネント解析を実施することもありますが、やはり、ライブラリやドライバを提供しているメーカーが作成したSBOMを取り込むことが、望ましくなります。
(今後は、ライブラリやドライバを提供しているメーカーが、SBOMを公開することが多くなると思われます)

その際に、同じルールで記載されていることで、容易に取り込むことが可能となります。
また、一部の機能を別会社に発注した際も、同様の手順が望ましく、サプライチェーンの透明性向上につながると考えられます。

以上のことから、記載する項目や内容、書き方を統一的なフォーマットで定義する必要があります。

現在、SBOMの代表的なフォーマットは、3つあります。

• SPDX（Software Package Data Exchange）
• CycloneDX
• SWID（Software Identificationタグ）

目次

• SPDX
• CycloneDX
• SWID
• どのフォーマットを使用するのが良いか？

● SPDX

LinuxFoundationが手動するプロジェクトで、作成されたフォーマットになります。
2010年から運営され、ISO/IEC5962:2021として、国際標準化されています。

Linux FoundationのSPDXグループとOMG/CISQのTool‑to‑Tool取り組みが連携したSPDXワーキンググループが、ソフトウェアパッケージおよび関連コンテンツに関する情報を、共通の形式で収集・共有できるようにするためのデータ交換フォーマットとして策定されました。

OMG(Object Management Group)は、ソフトウェアやシステム間の相互運用性を目的とした国際標準化団体です。
主な標準として、UML（Unified Modeling Language）やSysML（Systems Modeling Language、INCOSEとの合同作業部会により作成）などがあります。
ツール間・システム間で「同じ意味を正しく共有できること」を重視した標準化を行っています。

CISQ（Consortium for IT Software Quality）は、ソフトウェア品質を客観的・定量的に測定する指標を定義するためのコンソーシアムで、OMG の配下で活動しています。
最大の目的は、「ソフトウェア品質を、誰が測っても同じ結果になる形で評価できるようにする」です。

SPDXは、ソフトウェアの品質を客観的・定量的に測定できることを念頭にし、なおかつ、誰でも同じ意味を正しく共有できるように作成されたフォーマットと言えます。

● CycloneDX

OWASPコミュニティのプロジェクトによって開発されたSBOMフォーマットになります。
CycloneDXは、サイバーリスク軽減のための高度なサプライチェーン機能を提供する、フルスタックの部品表（BOM）標準です。
CycloneDXは、ECMA-424として公開されているEcma Internationalの標準規格です。
OWASP FoundationとEcma International Technical CommitteeのSoftware & System Transparency (TC54)が、この仕様の継続的な発展を推進しています。

OWASP（Open Worldwide Application Security Project）は、ソフトウェアのセキュリティ向上を目的とした国際的な非営利団体です。
目的は、「アプリケーションセキュリティに関する知識・ツール・基準を公開し、誰もが安全なソフトウェアを作れるようにすること」です。
Ecma International Technical Committeeは、Ecma International において特定技術分野の国際規格・仕様を策定・維持する専門委員会です。

Software & System Transparency (TC54)は、ソフトウェアおよびシステムの「透明性（Transparency）」を高めるための国際仕様を策定する委員会です。

• ソフトウェアやシステムが何で構成されているか？
• どのような依存関係を持っているか？
• リスクや品質に関する情報を、共有できているか？

といった点について、標準化された形式で明確に示せるようにしています。

CycloneDXは、SBOM を中核とした「ソフトウェア構成・依存関係・リスク及び品質情報の可視化と共有」を可能にするフォーマットと言えます。

● SWID

ソフトウェアを一意に識別するためのID、改行消去ISO/IEC 19770-2により、ソフトウェア識別 (SWID) タグが国際標準として定義されています。
これらのタグは、ソフトウェアの検出と識別に使用される XML ファイルです。
ソフトウェア製品を一意かつコンピュータが自動的に判別できるように記述するための構造化メタデータ形式です。
NISTは、この規格の最新バージョンであるISO/IEC 19770-2:2015の使用を推奨しています。

SWIDタグ文書は、ソフトウェア製品を識別し、製品のバージョンを特徴付け、製品の製造と配布に関与した組織と個人を識別し、ソフトウェア製品を構成する成果物を一覧表示し、ソフトウェア製品間の関係を確立し、その他の記述メタデータを提供する
構造化されたデータ要素のセットで構成されています。

SWIDタグとは、ISO/IEC 19770‑2に基づき、ソフトウェア製品の識別子、バージョン、製造・配布に関与した組織や成果物、製品間の関係などを、コンピュータが自動的に判別できる形で記述するXML形式の構造化メタデータフォーマットです。

● どのフォーマットを使用するのが良いか？

最後に、どのフォーマットを使用するのが良いかと言われますと、どの要素に重点を置くかで変わると思います。
ソフトウェア構成情報やライセンス情報を共有したい場合は、SPDX、コンポーネントと依存関係、脆弱性を共有したい場合は、CycloneDX、ソフトウェア製品を一意に識別したい場合は、SWIDタグとなるかと思います。

ただ、製品を正確に識別して管理するために、SWIDタグ＋SPDXや、SWIDタグ＋CycloneDXという組み合わせもあるかと思います。

社内の開発部門では、CycloneDXで管理し、正式な提出物としては、SPDXとする、という組み合わせもありなのではないでしょうか？