TR-03183-2で整理するSBOMスキーマ要件-lunaplus.net

TR-03183-2をどう読むか

CRAではSBOMの作成が求められますが、本文ではフォーマットの細部までは規定されていません。実務で困るのは「どの項目を、どの形式で、どこまで埋めるか」です。

その具体化に役立つのが、BSIのTR-03183-2です。法的拘束力はないものの、SPDX/CycloneDXのフィールドに落とし込んだ要件が整理されており、実装ガイドとして使いやすいドキュメントです。

この記事では、TR-03183-2のうちスキーマ観点で重要なポイントだけをまとめます。

必須度の見方

TR-03183-2の用語は次の3段階です。

MUST: 必須
SHOULD: 推奨
MAY: 任意

あわせて、各フォーマットの仕様上のRequired/Optionalが別に存在します。運用では「TR-03183-2の必須度」と「スキーマ必須」を両方満たしているかを確認する必要があります。

1. ドキュメントレベルの要件

まずSBOMファイルそのものに必要な情報です。

観点	SPDX 2.3	CycloneDX 1.6	実務メモ
フォーマット識別	`SPDXVersion`	`bomFormat` + `specVersion`	どちらも必須項目として扱う
文書識別子	`SPDXID` + `DocumentNamespace`	`serialNumber`	一意性を担保する
作成日時	`Created`	`metadata.timestamp`	UTCのISO 8601で統一する
作成者/ツール	`Creator`	`metadata.tools` / `metadata.authors`	再現性と監査性のため必須
対象製品参照	`DESCRIBES`関係で表現	`metadata.component`	製品本体を明示する
データライセンス	`DataLicense: CC0-1.0`	—（相当なし）	SPDX固有の必須項目。値は `CC0-1.0` 固定

とくに監査で見られやすいのは、「このSBOMが、いつ、何のツールで、どの製品向けに作られたか」が追えるかどうかです。

2. コンポーネントレベルの要件

次に、各コンポーネントに付与すべき情報です。

項目	SPDX 2.3	CycloneDX 1.6	ポイント
名称	`PackageName`	`components[].name`	必須
バージョン	`PackageVersion`	`components[].version`	TR-03183-2では必須扱い
タイプ	`PrimaryPackagePurpose`	`components[].type`	CDXでは`type`がスキーマ必須
識別子	`ExternalRef (purl/cpe)`	`purl` / `cpe`	PURLを第一候補にする
依存関係	`Relationship DEPENDS_ON`	`dependencies[]`	CRA最低要件はトップレベル依存
チェックサム	`PackageChecksum`	`hashes[]`	改ざん検知のため推奨
ライセンス	`PackageLicenseDeclared` 等	`licenses[]`	SPDX識別子で管理する

最小構成で始めるなら、「名称・バージョン・タイプ・PURL・依存関係」の5点を先に安定運用するのが現実的です。

3. BSI拡張プロパティ

TR-03183-2では、コンポーネントに対して追加情報を求めています。 CycloneDXの場合はpropertiesにbsi:ネームスペースを付けて表現できます。

bsi:component:executable
bsi:component:archive
bsi:component:structured
bsi:component:effectiveLicence
bsi:component:filename（任意）

SPDXで同等情報を持たせることは可能ですが、標準フィールドへの直接対応が弱い項目はPackageCommentやAnnotationで補完する形になりがちです。そのため、TR-03183-2の拡張要件に寄せる場合はCycloneDXが扱いやすい印象です。

CycloneDXの記述例

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:00000000-0000-4000-8000-000000000001",
  "metadata": {
    "timestamp": "2026-05-23T00:00:00Z",
    "tools": [
      {
        "name": "sample-sbom-tool",
        "version": "1.0.0"
      }
    ],
    "component": {
      "bom-ref": "sample-product-1.0.0",
      "type": "application",
      "name": "sample-product",
      "version": "1.0.0"
    }
  },
  "components": [
    {
      "bom-ref": "openssl-3.0.15",
      "type": "library",
      "name": "openssl",
      "version": "3.0.15",
      "purl": "pkg:generic/openssl@3.0.15",
      "properties": [
        { "name": "bsi:component:executable", "value": "non-executable" },
        { "name": "bsi:component:archive", "value": "no archive" },
        { "name": "bsi:component:structured", "value": "structured" },
        { "name": "bsi:component:effectiveLicence", "value": "Apache-2.0" }
      ]
    }
  ],
  "dependencies": [
    {
      "ref": "sample-product-1.0.0",
      "dependsOn": ["openssl-3.0.15"]
    }
  ]
}

実装時のチェックポイント

SBOM生成ツールがspecVersionやserialNumberを正しく埋めるか
components[].typeが空になっていないか（CDXでは必須）
PURLが実在コンポーネントと一致しているか
依存関係がトップレベルだけでも確実に出力されるか
BSI拡張プロパティの命名ゆれがないか
ライセンス情報の出典と更新責任を決めているか

要件の網羅性は一度で完璧を狙うより、まずは自動生成パイプラインを作り、差分検知と更新運用を回せる状態にする方が継続しやすいです。

TR-03183-2で整理するSBOMスキーマ要件

ToC