SBOM フォーマット完全解説

2025.11.12

近年、Log4jの脆弱性やSolarWindsへの攻撃など、サプライチェーンを標的とした攻撃が増加しています。これらの教訓から、世界各国の政府や規制当局は、ソフトウェアの構成要素を透明化する取り組みを推進しています。特に注目すべきは、2024年に採択され、2027年から段階的に適用されるEUサイバーレジリエンス法（CRA）です。この法律では、機械可読なSBOMフォーマットによる情報提供が法的義務として明確に規定されています。

しかし、「規定のSBOM形式でデータを出力すれば十分」と考えるのは誤解です。

この記事では、SBOM標準フォーマットの基本概念、主要フォーマットの詳細な比較、EU CRA対応の現状について解説します。さらに、形式的な対応にとどまらない実効性の高いSBOM運用戦略についても提案します。

SBOMフォーマットとは？

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

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

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

米国NTIA（National Telecommunications and Information Administration：国家電気通信情報局）の「Minimum Elements for SBOM」およびEU CRAでは、有効なSBOMに以下の要件を定めています。

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

  1. Author（作成者名） – SBOMを作成した組織または個人
  2. Timestamp（タイムスタンプ） – SBOM作成日時
  3. Supplier Name（供給者名） – コンポーネントの提供元
  4. Component Name（コンポーネント名） – ライブラリやパッケージの名称
  5. Version（バージョン） – コンポーネントのバージョン情報
  6. Component Hash（ハッシュ値） – コンポーネントの整合性検証用
  7. Dependency Relationship（依存関係） – 直接依存と推移的依存（transitive dependencies）の関係

SBOMフォーマットに求められる3つの特性：

  1. 機械可読（Machine-readable） – 人間が読むPDFやExcelではなく、ツールが自動で解析・処理可能な形式（例：JSON、XML）であること
  2. 一般的に使用されている（Commonly used） – 業界標準として広く採用されているフォーマットであること
  3. 推移的依存関係を含む（Including transitive dependencies） – 直接依存しているコンポーネントだけでなく、その下位依存も含むこと

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

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

現在、業界で広く採用されているSBOMフォーマットは主に3種類あります。以下では、それぞれのSBOM標準フォーマットとしての適合性と実用性を比較します。

項目SPDXCycloneDXSWID
主導団体Linux Foundation / ISO（国際標準化）OWASP（セキュリティコミュニティ主導）ISO/IEC（エンタープライズソフトウェア向け）
対応フォーマットJSON, XML, RDF, YAMLJSON, XML, Protocol BuffersXML（主に）
OSS対応△（ライセンス・コンプライアンス重視）◎（開発者・セキュリティチーム向け）△（商用ソフトウェアのインベントリ管理）
脆弱性メタデータ限定的（外部連携前提）組み込み可能（VEX対応、脆弱性除外情報も記述可）なし
EU CRA適合性高（ISO/IEC標準）高（セキュリティ特化設計）限定的（SAM用途向け）
CI/CD統合性○（ビルド後処理向け）◎（SBOM自動生成に最適）✕（静的インベントリ用途）
ライセンス情報詳細（SPDX License List対応）標準（SPDX ID互換）限定的

SPDX

出自と目的： Linux Foundationが主導するSPDXは、もともとOSSのライセンスコンプライアンス管理を目的として開発されました。2021年にISO/IEC 5962:2021として国際標準化され、業界標準としての地位を確立しています。

特徴： SPDXの最大の強みは、ライセンス情報の詳細な記述能力です。350種類以上の標準ライセンス識別子を持ち、複雑なライセンス条件や例外事項も正確に表現できます。また、著作権情報、パッケージのダウンロードURL、チェックサムなど、ソフトウェアの出所を証明する情報を網羅的に記録できます。

ユースケース： 組み込み機器メーカーや自動車業界など、OSSライセンス違反が製品リコールや訴訟リスクに直結する業界で特に採用されています。GPLv3などのコピーレフトライセンスを含む製品開発において、ライセンス義務の履行状況を厳密に管理したい企業に最適です。

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

{
  "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-react",
    "name": "react",
    "versionInfo": "18.2.0",
    "downloadLocation": "https://registry.npmjs.org/react/-/react-18.2.0.tgz",
    "filesAnalyzed": true,
    "licenseConcluded": "MIT",
    "licenseDeclared": "MIT",
    "copyrightText": "Copyright (c) Meta Platforms, Inc."
  }]
}

 

CycloneDX

出自と目的： OWASPコミュニティが主導するCycloneDXは、最初からセキュリティと脆弱性管理に特化して設計されたフォーマットです。「サイバーサプライチェーンの可視化」を目的とし、SBOMだけでなくVEX（Vulnerability Exploitability eXchange：脆弱性悪用可能性交換情報）やBOV（Bill of Vulnerabilities：脆弱性一覧表）といった関連仕様も包括的に開発しています。

特徴： CycloneDXの強みは、コンポーネントの依存関係グラフと脆弱性情報を統合的に管理できる点です。各コンポーネントに対して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",
    "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"
      }]
    }]
  }]
}

 

SWID (Software Identification) Tags

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

特徴： 他の2つのフォーマットとは異なり、SWIDは「タグ」という概念を用いて、ソフトウェアの各ライフサイクル段階（インストール前、インストール後、パッチ適用後など）を記録します。企業のIT資産管理システムとの親和性が高く、ライセンス監査への対応も容易です。

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

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

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

重要な結論から申し上げます。「完璧なSBOMフォーマットは存在しません」。各フォーマットには得意領域があり、自社の最優先課題に合わせて選択することが最も重要です。

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

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

あなたの組織が直面している最優先課題は何でしょうか？

  • A: OSSのライセンス違反リスク回避が最優先 → SPDXが第一候補
    • 特に、GPLやAGPLなどのコピーレフトライセンスを含む製品を開発している場合
    • 自動車、医療機器、組み込み機器など、製品リコールリスクが高い業界の場合
  • B: 最新の脆弱性への迅速な対応が最優先 → CycloneDXが第一候補
    • Webアプリケーション、SaaSサービスを運営している場合
    • DevSecOpsを推進し、CI/CDパイプラインでの自動化を重視する場合
  • C: ソフトウェア資産の厳密な管理が最優先 → SWIDも視野に
    • 大規模な商用ソフトウェアを多数利用している場合
    • IT資産管理システムとの連携が必須の場合

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

EUのサイバーレジリエンス法（CRA）や米国の政府調達要件では、特定のフォーマットを強制する動きは限定的です。SPDXやCycloneDXなど、国際的に認知された標準フォーマットであれば、ほとんどの法規制要件を満たせます。

経済産業省が2023年7月に発表した「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引」でも、SPDXとCycloneDXの両方が推奨フォーマットとして挙げられています。重要なのは、フォーマットの種類よりも「正確な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フォーマット選択の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機能ではSBOMの適切な管理だけではなく、脆弱性管理や統合的なセキュリティ評価が可能となっております。SBOM機能についてはこちらで解説しております。

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

 

参考文献

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

 

 

ブログ一覧へ戻る

貴社の利用状況に合わせた見積もりを作成します。

見積もりを希望する
資料ダウンロード

料金プランを詳しく見る