メインコンテンツへスキップ
Securify
トライアル
Securify

SBOMフォーマット比較｜SPDX・CycloneDXの違いとJSON例

セキュリティ解説Securify編集部読了目安 約 19 分
目次14項目
SBOMフォーマットの選び方｜SPDX・CycloneDXと受け渡し時の確認点

SBOMの代表的な形式はSPDXとCycloneDXです。どちらも部品や依存関係を記述できるため、受け渡し先の対応形式・バージョンと、必要な情報を保存できるかで選びます。この記事ではSWIDも含めた比較表、SPDX・CycloneDXのJSONサンプル、用途別の選び方を紹介します。

Log4jの脆弱性やSolarWindsへの攻撃など、ソフトウェアサプライチェーンを標的とした攻撃は大きな被害をもたらしてきました。これらの教訓から、世界各国の政府や規制当局は、ソフトウェアの構成要素を透明化する取り組みを推進しています。特に注目すべきは、2024年に成立し、段階的に適用が進むEUサイバーレジリエンス法（CRA）です。悪用が確認された脆弱性などの報告義務は2026年9月11日から適用されており、製造業者に対する主な義務は2027年12月11日から適用されます。CRAでは、一般的に使用される機械可読な形式でSBOMを作成することが求められます。

しかし、「規定のSBOM形式でデータを出力すれば十分」と考えるのは誤解です。SBOMをツール間や取引先と受け渡すには、受け取り側が理解できる形式で出力する必要があります。JSONやXMLで書かれていても、仕様やバージョンが違えば、そのまま取り込めるとは限りません。また、形式が正しくても、部品の識別子や依存関係が欠けていれば、脆弱性の影響調査には使いにくくなります。

この記事では、SBOM標準フォーマットの基本概念、主要フォーマットの比較、EU CRAなどの要件との関係について解説します。さらに、形式的な対応にとどまらない実効性の高いSBOM運用のポイントについても紹介します。

SBOMフォーマットとは？

SBOM（Software Bill of Materials：ソフトウェア部品表）とは、ソフトウェアに含まれるオープンソースおよびサードパーティのコンポーネント（構成要素）を一覧化したものです。

「SBOMフォーマット」とは、これらの情報を統一された構造で記述するための標準的な方式です。

■ SBOMフォーマットに求められる主要要件（NTIA・EU CRA）

米国NTIA（National Telecommunications and Information Administration：国家電気通信情報局）は2021年に公表した「The Minimum Elements For a Software Bill of Materials (SBOM)」で、SBOMに含めるべき最小限のデータ項目を示しています。また、EU CRAは、製造業者が作成するSBOMの形式と範囲について要件を定めています。

NTIA最小要素に基づく7つのデータフィールド：

  1. Author（作成者名） – SBOMを作成した組織または個人
  2. Timestamp（タイムスタンプ） – SBOM作成日時
  3. Supplier Name（供給者名） – コンポーネントの提供元
  4. Component Name（コンポーネント名） – ライブラリやパッケージの名称
  5. Version（バージョン） – コンポーネントのバージョン情報
  6. Other Unique Identifiers（その他の一意な識別子） – コンポーネントを特定するための識別子（例：後述のサンプルにあるパッケージURL）
  7. Dependency Relationship（依存関係） – あるコンポーネントがどのソフトウェアに含まれているかという関係

依存関係について、NTIAは推移的依存（transitive dependencies）まで記載することを望ましいとし、少なくとも最上位の依存関係は記載するよう求めています。コンポーネントのハッシュ値は整合性の確認に役立つ項目ですが、この7つの最小要素には含まれず、推奨項目として挙げられています。なお、2026年7月には、CISAがNSAなどと共同で、この最小要素を更新した「2026 Minimum Elements for a Software Bill of Materials (SBOM)」を公表し、コンポーネントのハッシュ値などを最小要素に加えています。

EU CRAがSBOMに求める3つの特性：

  1. 機械可読（Machine-readable） – 人が目で確認するためのPDFなどではなく、ツールが自動で解析・処理可能な形式（例：JSON、XML）であること
  2. 一般的に使用されている（Commonly used） – 業界で広く採用されているフォーマットであること
  3. 少なくとも最上位の依存関係を含む（Covering at the very least the top-level dependencies） – 製品が直接依存するコンポーネントを最低限含むこと

CRAが最低限として求めるのは最上位の依存関係ですが、脆弱性が見つかった部品がどの製品経由で取り込まれたかを調べるには、間接的な依存（推移的依存）まで記録されているほうが有利です。提出先や取引先が求める範囲を確認したうえで、必要な直接・間接依存を記録しましょう。

🔍 ポイント：フォーマットが統一されていないと、脆弱性情報（例：NVD、OSV）と自動で照合しにくくなり、リスクの可視化・対応が遅れます。詳細は『SBOMとは？ソフトウェア部品表を脆弱性管理に使う方法』をご参照ください。

SBOM主要フォーマット比較：SPDX、CycloneDX、SWID

SBOMの代表的なフォーマットとして、SPDX、CycloneDX、SWIDタグの3種類がよく挙げられます。以下では、それぞれのSBOM標準フォーマットとしての特徴と用途を比較します。

項目

SPDX

CycloneDX

SWID

主導団体

Linux Foundation / ISO（国際標準化）

OWASP（セキュリティコミュニティ主導）

ISO/IEC（エンタープライズソフトウェア向け）

対応フォーマット

JSON, XML, RDF, YAML など

JSON, XML, Protocol Buffers

XML（主に）

出自・主な用途

OSSのライセンスコンプライアンスから発展。構成・ライセンス・出所情報の交換

セキュリティ用途から発展。部品・依存関係・脆弱性関連情報の表現

商用ソフトウェアの識別とインベントリ管理

脆弱性メタデータ

扱える範囲は仕様のバージョンにより異なる（採用するバージョンで確認）

BOM内に記述可能（VEX対応、脆弱性除外情報も記述可）

なし

生成ツールでの扱い

多くのSBOM生成ツールが出力に対応

多くのSBOM生成ツールが出力に対応

ソフトウェアの識別・インベントリ用途が中心

ライセンス情報

詳細（SPDX License List対応）

標準（SPDX ID互換）

限定的

表は、仕様の出自と主な用途に基づく目安です。SPDXとCycloneDXはどちらも仕様の更新が続いているため、一方を「ライセンス専用」、もう一方を「脆弱性専用」と決めつけると、実際の機能を見落とします。採用するバージョンで必要な項目を保存でき、受け取り側がその項目を利用できるかで選ぶことが大切です。

SPDX

出自と目的： Linux Foundationが主導するSPDXは、ソフトウェアの構成やライセンスなどの情報を交換するための標準です。もともとOSSのライセンスコンプライアンス管理を目的として開発され、2021年にISO/IEC 5962:2021として国際標準化されました。

特徴： SPDXの強みは、ライセンス情報の詳細な記述能力です。SPDX License Listとして標準化されたライセンス識別子を使い、複雑なライセンス条件や例外事項も表現できます。また、著作権情報、パッケージのダウンロード元、チェックサムなど、ソフトウェアの出所を示す情報も記録できます。

ユースケース： 組み込み機器や自動車など、OSSライセンス違反が訴訟などの大きな事業リスクにつながりやすい業界では、ライセンス情報を詳しく記録できることが重視されます。GPLv3などのコピーレフトライセンスを含む製品開発において、ライセンス義務の履行状況を厳密に管理したい場合の有力な候補です。

出力サンプル（JSON形式、SPDX 2.3）：

{
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "Example-App",
  "documentNamespace": "https://example.com/spdx/example-app-1.0",
  "creationInfo": {
    "created": "2025-01-15T10:00:00Z",
    "creators": ["Tool: example-sbom-tool-1.0"]
  },
  "packages": [{
    "SPDXID": "SPDXRef-Package-example-app",
    "name": "Example-App",
    "versionInfo": "1.0",
    "downloadLocation": "NOASSERTION",
    "filesAnalyzed": false
  }, {
    "SPDXID": "SPDXRef-Package-react",
    "name": "react",
    "versionInfo": "18.2.0",
    "downloadLocation": "https://registry.npmjs.org/react/-/react-18.2.0.tgz",
    "filesAnalyzed": false,
    "licenseConcluded": "MIT",
    "licenseDeclared": "MIT",
    "copyrightText": "Copyright (c) Meta Platforms, Inc."
  }],
  "relationships": [{
    "spdxElementId": "SPDXRef-DOCUMENT",
    "relationshipType": "DESCRIBES",
    "relatedSpdxElement": "SPDXRef-Package-example-app"
  }, {
    "spdxElementId": "SPDXRef-Package-example-app",
    "relationshipType": "DEPENDS_ON",
    "relatedSpdxElement": "SPDXRef-Package-react"
  }]
}

この例では、パッケージ単位の情報を記録し、relationships で文書が説明する対象（DESCRIBES）と、アプリケーションがreactに依存していること（DEPENDS_ON）を示しています。

CycloneDX

出自と目的： OWASPコミュニティが主導するCycloneDXは、セキュリティ用途を念頭に設計されたフォーマットで、部品や依存関係を含むSBOMの表現を提供しています。「サイバーサプライチェーンの可視化」を目的とし、SBOMだけでなくVEX（Vulnerability Exploitability eXchange：脆弱性悪用可能性交換情報）やBOV（Bill of Vulnerabilities：脆弱性一覧表）といった関連する用途にも対応しています。

特徴： CycloneDXの強みは、コンポーネントの依存関係と脆弱性情報を同じBOMの中で扱える点です。脆弱性ごとにCVE番号、CVSSスコア、対応状況などを記述し、影響を受けるコンポーネントを参照で関連づけられます。また、コンポーネントのハッシュ値を記録する項目もあり、改ざんの有無を確認する手がかりになります。

ユースケース： DevSecOpsを推進するWebサービス企業やSaaS事業者にとって有力な候補です。CI/CDパイプラインに生成処理を組み込みやすく、新たな脆弱性が発見された際の影響範囲の特定や対応優先度の判断に役立ちます。

出力サンプル（JSON形式、CycloneDX 1.6）：

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2025-01-15T10:00:00Z",
    "tools": {
      "components": [{
        "type": "application",
        "name": "example-sbom-generator"
      }]
    }
  },
  "components": [{
    "type": "library",
    "bom-ref": "pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1",
    "name": "log4j-core",
    "version": "2.14.1",
    "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1"
  }],
  "vulnerabilities": [{
    "id": "CVE-2021-44228",
    "source": {"name": "NVD"},
    "ratings": [{
      "score": 10.0,
      "severity": "critical",
      "method": "CVSSv31"
    }],
    "affects": [{
      "ref": "pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1"
    }]
  }]
}

この例では、脆弱性情報をBOMの最上位にある vulnerabilities に記述し、affects で対象コンポーネントの bom-ref を参照しています。

SWID (Software Identification) Tags

目的： ISO/IEC 19770-2として標準化されているSWIDタグは、主に商用ソフトウェアの識別とライフサイクル管理を目的としています。インストール状況、パッチ適用状況、ライセンスの使用状況などを追跡し、ソフトウェア資産管理（SAM：Software Asset Management）の文脈で活用されます。

特徴： 他の2つのフォーマットとは異なり、SWIDは「タグ」という概念を用いて、ソフトウェアの各ライフサイクル段階（インストール前、インストール後、パッチ適用後など）を記録します。企業のIT資産管理システムとの親和性が高く、ライセンス監査への対応にも使われます。一方で、SWIDタグはソフトウェアを識別するための仕組みであり、依存関係を含む部品表とは用途が異なります。ファイル形式の変換だけで、元のデータにない部品や依存関係が補完されるわけではない点にも注意が必要です。

ユースケース： 金融機関や政府機関など、ソフトウェア資産の厳密な管理とライセンス監査への対応が求められる環境で有効です。特に、高額な商用ソフトウェアのライセンス管理に役立ちます。ただし、クラウドネイティブアプリケーションやコンテナ環境への対応は限定的です。

結局どれを選ぶべき？目的別・SBOMフォーマットの選び方

完璧なフォーマットは存在しない

重要な結論から申し上げます。「完璧なSBOMフォーマットは存在しません」。各フォーマットには出自に由来する得意領域があります。自社の最優先課題と、SBOMを受け渡す相手が対応している形式・バージョンに合わせて選択することが最も重要です。

あなたに最適なフォーマット選択フローチャート

ステップ1：最優先課題を特定する

あなたの組織が直面している最優先課題は何でしょうか？以下は出自を踏まえた第一候補です。いずれも「その形式でなければ扱えない」という意味ではありません。

  • A: OSSのライセンス違反リスク回避が最優先 → SPDXが第一候補
    • 特に、GPLやAGPLなどのコピーレフトライセンスを含む製品を開発している場合
    • 自動車、医療機器、組み込み機器など、製品リコールリスクが高い業界の場合
    • CycloneDXもSPDXのライセンスIDでライセンス情報を記述できるため、取引先から形式の指定があればそれに合わせます
  • B: 最新の脆弱性への迅速な対応が最優先 → CycloneDXが第一候補
    • Webアプリケーション、SaaSサービスを運営している場合
    • DevSecOpsを推進し、CI/CDパイプラインでの自動化を重視する場合
    • 脆弱性情報やVEXを同じ文書で扱いたい場合。SPDXを使う場合も、採用するバージョンで必要な項目を表現できるかを確認します
  • C: ソフトウェア資産の厳密な管理が最優先 → SWIDも視野に
    • 大規模な商用ソフトウェアを多数利用している場合
    • IT資産管理システムとの連携が必須の場合
    • 依存関係を含む部品表が必要な場合は、SPDXやCycloneDXと併用します

ステップ2：法規制要件を確認する

EUのサイバーレジリエンス法（CRA）が求めているのは「一般的に使用される機械可読な形式」であり、特定のフォーマット名は指定されていません。米国の政府調達要件でも、特定のフォーマットを強制する動きは限定的です。ただし、SPDXやCycloneDXで出力しただけで要件を満たせるわけではありません。必要なデータ項目や依存関係の範囲が含まれているかを、要求元の条件に照らして確認します。

経済産業省が2023年7月に公表し、2024年8月にVer2.0へ改訂した「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引」でも、SPDXやCycloneDXなどが代表的なSBOMフォーマットとして紹介されています。重要なのは、フォーマットの種類よりも「必要なときに正確なSBOMを作成・提示できる体制」を構築することです。

ステップ3：ツールエコシステムを評価する

実は、フォーマット自体よりも「対応ツールの豊富さ」が運用の成否を左右します。SPDXとCycloneDXは、どちらも多くのツールで扱われています。代表的なツールの例は以下のとおりですが、対応する形式や仕様のバージョンはツールごとに異なり、一方の形式だけを扱うツールもあります。

  • SBOM生成ツール： Syft、Trivy、cdxgen、SPDX-Sbom-Generator
  • SBOM管理・分析ツール： OWASP Dependency-Track、Snyk、Mend（旧WhiteSource）
  • 脆弱性スキャナ： Grype、Trivy、Black Duck
  • CI/CD統合： GitHub Actions、GitLab CI、Jenkins（上記のツールを組み込み、SBOMを自動生成する実行基盤）

既存の開発環境やツールチェーンとの親和性を事前に確認しておくと、導入と継続的な運用を進めやすくなります。

ステップ4：小さなサンプルで往復を試す

形式を決める前に、実際のプロジェクトから生成したSBOMを取り込み、部品数や依存関係を確認します。別形式へ変換する場合は、変換前後で必要な情報が残るかも確かめます。構文検証が通ることと、運用に十分な内容があることは別の確認です。

同じ名称のパッケージが複数の配布元に存在する場合もあるため、名前だけで照合するのではなく、パッケージの種類、配布元、バージョン、識別子などを合わせて扱います。受け渡し前には、次の項目を確認しておきましょう。

項目

確認すること

仕様・バージョン

出力側と取り込み側が対応する組み合わせか

対象

製品、リリース、ビルド、イメージを特定できるか

部品情報

名前・バージョン・識別子を照合できるか

依存関係

必要な直接・間接依存を記録しているか

更新・保管

生成日時と差し替え方法、過去版の保管先が決まっているか

まとめ：SBOMフォーマット選択の3つの重要ポイント

本記事では、SBOM標準フォーマットの基本概念、SPDX・CycloneDX・SWIDの比較、そしてEU CRAなどの要件に向けた実効性の高い運用のポイントについて解説しました。最後に、重要なポイントを3つにまとめます。

1. 完璧なフォーマットは存在しない──優先課題と受け渡し先に応じた選択を

SPDXはライセンスコンプライアンスから、CycloneDXはセキュリティ用途から発展し、SWIDはソフトウェア資産管理に適しています。ただし、出自だけで「ライセンス専用」「脆弱性専用」と決めつけず、自社の最優先課題（ライセンス違反回避、脆弱性対応、資産管理）と、受け取り側が利用できる項目を明確にしてフォーマットを選択することが成功の鍵です。

2. 法規制対応は「フォーマット選択」より「運用体制構築」が重要

EUサイバーレジリエンス法（CRA）では、一般的に使用される機械可読な形式でSBOMを作成することが求められますが、特定フォーマットの指定はありません。重要なのは、正確なSBOMを継続的に生成・更新し、必要なときに提示できる体制を構築することです。形式的な対応ではなく、実効性のある運用を目指しましょう。

3. ツールエコシステムの充実度が運用の成否を左右する

フォーマット自体よりも、対応ツールの豊富さとCI/CDパイプラインとの統合のしやすさが実務では重要です。Syft、Trivy、Snykなど、SPDXとCycloneDXの両方を出力できるツールもありますが、対応する仕様のバージョンはツールごとに確認が必要です。既存の開発環境に適合するツールチェーンを構築することで、SBOM運用の自動化と継続性を確保できます。

SBOMは単なる法規制対応のチェックボックスではなく、サプライチェーンリスクを可視化し、組織全体のセキュリティレジリエンスを向上させる戦略的ツールです。本記事が、あなたの組織に合ったSBOMフォーマットの選択と、実効性の高い運用体制構築の一助となれば幸いです。

Securify SBOMは、リポジトリ・コンテナ・クラウドからソフトウェア構成を収集し、コンポーネントとバージョンを脆弱性情報と照合して、問題のある部品を特定します。OSSライセンスやEOL（サポート終了）、禁止パッケージの管理に加え、ASM・CSPMとの連携で脆弱な部品を使う稼働資産も把握できます。取得方法や対応形式はお使いの環境に合わせてご案内しますので、必要な形式とバージョン、取り込み・出力の方向をお知らせください。

ご興味のある方はぜひお問い合わせください。

3. ツールエコシステムの充実度が運用の成否を左右するの説明画像

参考文献

  • SPDX公式サイト： https://spdx.dev/ – SPDX仕様書および最新バージョンの情報
  • CycloneDX公式サイト： https://cyclonedx.org/ – CycloneDX仕様書およびツールエコシステム
  • ISO/IEC 19770-2:2015： Software identification tags (SWID tags) – 国際標準規格
  • EU： Regulation (EU) 2024/2847 “Cyber Resilience Act” (2024) – EU規則本文（EUR-Lex）
  • 米国国家電気通信情報局（NTIA）： “The Minimum Elements For a Software Bill of Materials (SBOM)” (2021) – SBOM最小要素の定義
  • CISA・NSAほか： “2026 Minimum Elements for a Software Bill of Materials (SBOM)” (2026) – NTIAの最小要素を更新したガイダンス
  • 経済産業省： 「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引」(2023年7月、2024年8月にVer2.0へ改訂) – 日本における公式ガイドライン
  • OWASP： “Software Component Verification Standard (SCVS)” – ソフトウェアコンポーネント検証の標準
  • Linux Foundation： “OpenChain Project” – オープンソースコンプライアンスの業界標準
  • CISA： “Software Bill of Materials (SBOM)” – 米国サイバーセキュリティ・インフラストラクチャセキュリティ庁の公式ガイダンス

関連記事

Get Started

OSSの構成と脆弱性を継続管理するなら Securify SBOM。

ご利用規模・診断頻度に合わせて最適なプランをご提案します。

SBOMの収集対象・運用を相談するサービス資料を受け取るSBOMの料金を見る
SBOMの機能を見る

OSSの構成と脆弱性を継続管理するなら Securify SBOM。

SBOMの収集対象・運用を相談するサービス資料を受け取るSBOMの料金を見る