2026年に報告されたCVEは、1日あたり前年比131%増加しています。

SBOM

SBOMの例

SBOMを理解する一番の近道は、実際に読んでみることです。同じ小さなアプリケーションをCycloneDXとSPDXで記述した例を、各フィールドの意味、不十分なSBOMの特徴、自社のSBOMの確認方法とあわせて紹介します。

更新日

この例で扱うアプリケーション

どちらのファイルも、説明用のNode.jsサービスexample-api 2.4.0を記述しています。直接の依存関係はexpressの1つだけです。Expressはさらにacceptsに依存しているため、この例には推移的依存関係も1つ含まれます。実際のExpressアプリケーションのSBOMにはもっと多くのコンポーネントが記載されますが、構造は同じです。

CycloneDX SBOMの例

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2026-10-30T09:00:00Z",
    "lifecycles": [{ "phase": "build" }],
    "tools": {
      "components": [
        { "type": "application", "name": "example-sbom-tool", "version": "1.0.0" }
      ]
    },
    "component": {
      "type": "application",
      "bom-ref": "example-api",
      "name": "example-api",
      "version": "2.4.0"
    }
  },
  "components": [
    {
      "type": "library",
      "bom-ref": "pkg:npm/[email protected]",
      "name": "express",
      "version": "4.21.2",
      "purl": "pkg:npm/[email protected]",
      "licenses": [{ "license": { "id": "MIT" } }]
    },
    {
      "type": "library",
      "bom-ref": "pkg:npm/[email protected]",
      "name": "accepts",
      "version": "1.3.8",
      "purl": "pkg:npm/[email protected]",
      "licenses": [{ "license": { "id": "MIT" } }]
    }
  ],
  "dependencies": [
    { "ref": "example-api", "dependsOn": ["pkg:npm/[email protected]"] },
    { "ref": "pkg:npm/[email protected]", "dependsOn": ["pkg:npm/[email protected]"] }
  ]
}
フィールド わかること
specVersion ファイルが使用するフォーマットのバージョン。ツールが解析できるようにするためのものです。
serialNumber、version どのSBOMで、そのどの改訂版か。
metadata.lifecycles SBOMが作成された時点。この例ではビルド中です。
metadata.tools SBOMを生成したツール。2つのツールが同じコミットを異なる内容で報告することもあります。
metadata.component SBOMが記述する製品。
purl パッケージURL。ツールがコンポーネントをアドバイザリと照合するための識別子です。
licenses コンポーネントの宣言ライセンス。
dependencies どれがどれを取り込んでいるか。これによりacceptsが推移的依存関係として見えるようになります。

SPDX SBOMの例

{
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "example-api-2.4.0",
  "documentNamespace": "https://example.com/spdx/example-api-2.4.0",
  "creationInfo": {
    "created": "2026-10-30T09:00:00Z",
    "creators": ["Tool: example-sbom-tool-1.0.0"]
  },
  "packages": [
    {
      "name": "example-api",
      "SPDXID": "SPDXRef-Package-example-api",
      "versionInfo": "2.4.0",
      "downloadLocation": "NOASSERTION"
    },
    {
      "name": "express",
      "SPDXID": "SPDXRef-Package-express",
      "versionInfo": "4.21.2",
      "downloadLocation": "NOASSERTION",
      "licenseDeclared": "MIT",
      "externalRefs": [
        {
          "referenceCategory": "PACKAGE-MANAGER",
          "referenceType": "purl",
          "referenceLocator": "pkg:npm/[email protected]"
        }
      ]
    },
    {
      "name": "accepts",
      "SPDXID": "SPDXRef-Package-accepts",
      "versionInfo": "1.3.8",
      "downloadLocation": "NOASSERTION",
      "licenseDeclared": "MIT",
      "externalRefs": [
        {
          "referenceCategory": "PACKAGE-MANAGER",
          "referenceType": "purl",
          "referenceLocator": "pkg:npm/[email protected]"
        }
      ]
    }
  ],
  "relationships": [
    {
      "spdxElementId": "SPDXRef-DOCUMENT",
      "relationshipType": "DESCRIBES",
      "relatedSpdxElement": "SPDXRef-Package-example-api"
    },
    {
      "spdxElementId": "SPDXRef-Package-example-api",
      "relationshipType": "DEPENDS_ON",
      "relatedSpdxElement": "SPDXRef-Package-express"
    },
    {
      "spdxElementId": "SPDXRef-Package-express",
      "relationshipType": "DEPENDS_ON",
      "relatedSpdxElement": "SPDXRef-Package-accepts"
    }
  ]
}

情報は同じで、並べ方が異なります。SPDXはpackagesのリストを持ち、項目間のすべてのつながりをrelationshipsに記述します。licenseDeclaredはパッケージ自身が宣言している内容で、downloadLocationはツールが把握していない場合にNOASSERTIONとなることがあります。レイアウト以外での2つのフォーマットの違いについては、CycloneDXとSPDXの比較をご覧ください。

不十分なSBOMの特徴

ファイルとしては有効でも、ほとんど役に立たないことがあります。次の点に注意してください。

  • 依存関係のつながりがない。フラットなリストでは、パッケージが存在することはわかっても、何がそれを取り込んだかはわかりません。推移的依存関係を修正するにはその情報が必要です。
  • パッケージURLがない。purlのような識別子がないと、コンポーネントとアドバイザリの照合は名前からの推測に頼ることになります。
  • ライセンスが欠けている。多くのフィールドがNOASSERTIONのままでは、SBOMはライセンスに関する質問に答えられません。
  • コンポーネントが不自然に少ない。大規模なアプリケーションなのにコンポーネントがわずかしかない場合、通常は直接の依存関係だけ、あるいは1つのロックファイルが宣言したものだけしか含まれていません。
  • いつ、どのように作成されたかの記載がない。ツールと生成のコンテキストがなければ、SBOMがどこまでを網羅していると信頼できるか判断できません。
  • 欠落について何も示さない。良いSBOMは、見えなかったものを明示します。ほとんどのファイルはただ記載が終わるだけで、読み手は完全なものだと思い込んでしまいます。

自社のSBOMを確認する方法

  1. フォーマットを検証する。そのフォーマットとバージョンに対応したスキーマバリデーターにかけます。ファイルを解析できないツールは、そのファイルを利用できないためです。
  2. フィールドを確認する。2026 Minimum Elementsや、顧客から求められた項目リストと比較します。
  3. 既知のものを検索する。推移的依存関係、ベースイメージのパッケージ、ビルドツールをそれぞれ1つ選び、どれが記載されているかを確認します。
  4. 2つの情報源を比較する。別の方法で2つ目のSBOMを生成し、差分を確認します。一方のファイルにだけあるコンポーネントは、もう一方のファイルに対する疑問点になります。

NTIA、CISA、BSIのフィールドリストに対応づけたすべてのチェックについては、SBOM品質チェックリストをご覧ください。

CRACIのビルド時SBOM

CRACIも同じフォーマットでエクスポートします。違うのは内容の情報源です。CRACIは各GitHub Actionsジョブが取得したものを記録するため、SBOMのすべてのコンポーネントは実際にビルドに取り込まれたものであり、CIキャッシュから復元されたパッケージにはその旨が示されます。ワークフローが実行したGitHub Actionsも、使用されたコミットに固定されたコンポーネントとして記載されます。各ジョブのSBOMには完全性の状態も付くため、欠落を自分で探す必要はなく、明示されます。ビルド時SBOM生成やSBOMツールの比較をご覧ください。

SBOMの例に関するよくあるご質問

SBOMはどのようなものですか？

通常はJSONファイルで、XMLの場合もあります。まずツールやタイムスタンプなどSBOM自体に関するデータがあり、次に各コンポーネントの名前、バージョン、識別子、ライセンスが並び、最後にコンポーネント同士の依存関係が記述されます。

SBOMはJSONファイルですか？

多くの場合はそうです。JSONはCycloneDXとSPDXの両方で最も広く使われているエンコーディングだからです。どちらのフォーマットにも他のエンコーディングがあり、SPDXにはtag-value形式のテキストもあります。

SBOMのpurlとは何ですか？

purl（パッケージURL）は、pkg:npm/[email protected]のようにパッケージを表す標準の識別子です。エコシステム、パッケージ、バージョンを1つの文字列で示すため、ツールがコンポーネントを脆弱性データと確実に照合できます。

SBOMにはいくつのコンポーネントが含まれるべきですか？

正しい数というものはありませんが、推移的依存関係は含まれているべきで、通常は直接の依存関係よりはるかに多くなります。大規模なアプリケーションなのにコンポーネントがごくわずかな場合、ツールが一部しか見ていないことがほとんどです。

オープンソースプロジェクトのSBOMは見られますか？

場合によります。リリースとともにSBOMを公開しているプロジェクトもあり、GitHubはリポジトリの依存関係グラフからSBOMをエクスポートできます。ただしそのエクスポートは、特定のビルドが使用したものではなく、リポジトリが宣言している内容を反映したものです。

自社のSBOMを記録されたSBOMと比較

GitHub Actionsのワークフローを1つCRACIで実行し、現在のSBOMに記載されていないコンポーネントを確認してください。

デモを予約