SBOM

SBOM とは

SBOM (Software Bill of Materials) は、ソフトウェアに含まれるすべてのコンポーネント (オープンソースライブラリ、フレームワーク) とそのバージョン、ライセンス情報を記録した部品表である。製造業の BOM (部品表) をソフトウェアに適用した概念である。広く知られるようになった契機は、2021 年 5 月 12 日に米国で発令された大統領令 14028「Improving the Nation's Cybersecurity」で、この指示を受けた NTIA が同年 7 月 12 日に SBOM の最小要素をまとめた報告書を公開した。何をどこまで書けば足りるのかが示されたことで、以後は形式とツールの整備が進んだ。

なぜ SBOM が必要か

2021 年 12 月 10 日に公開された Log4Shell (CVE-2021-44228) は、部品表がないと何に困るかを示した例である。Log4j は自分で書いた依存として現れることが少なく、フレームワークやライブラリの依存の依存として入り込む。そのため pom.xml や build.gradle を見ても含有の有無が判断できず、成果物を 1 つずつ展開して確認する作業に追われた組織があった。

SBOM は推移的な依存まで版付きで記録するので、脆弱性が公開された日に検索するだけで影響範囲の候補を絞れる。逆に、生成が古いままの SBOM は誤った安心を与える。ビルドごとに作り直し、成果物と対応づけて保管することが前提になる。

SBOM の標準フォーマット

実務で選ぶのは SPDX か CycloneDX のどちらかで、SWID はソフトウェア資産管理の側から来た識別タグである。

フォーマット	策定元	特徴
SPDX	Linux Foundation	ISO/IEC 5962:2021 として国際規格化。2026 年 8 月時点の最新版は 3.0 で、ライセンス表記の厳密さが強み
CycloneDX	OWASP	ECMA-424 として標準化 (2025 年 12 月の第 2 版が 1.7 に対応)。脆弱性や依存関係も同じ文書に書ける
SWID	ISO/IEC	ISO/IEC 19770-2:2015 で定義された識別タグ。導入済みソフトウェアの棚卸しが出発点

生成ツールの対応が広いのは CycloneDX で、SPDX も syft のように両形式を出せるものがある。片方に決め打ちせず、受け取り側が読める形式を先に確認する。

SBOM の生成

生成はロックファイルやコンテナイメージから機械的に行う。手で一覧を書き起こすものではない。

# npm: package-lock.json から CycloneDX 形式で生成
npx @cyclonedx/cyclonedx-npm --output-file sbom.json

# syft: コンテナイメージから SBOM を生成
syft myapp:latest -o cyclonedx-json > sbom.json

# trivy: SBOM 生成 + 脆弱性スキャン
trivy image --format cyclonedx myapp:latest > sbom.json

SBOM の内容

CycloneDX 形式の最小構成に近い例である。bomFormat と specVersion は必須で、これが無いと受け取り側のツールが形式と版を判定できない。

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [
    {
      "type": "library",
      "name": "express",
      "version": "4.18.2",
      "purl": "pkg:npm/express@4.18.2",
      "licenses": [{ "license": { "id": "MIT" } }]
    },
    {
      "type": "library",
      "name": "zod",
      "version": "3.22.4",
      "purl": "pkg:npm/zod@3.22.4"
    }
  ]
}

突合の鍵になるのは purl である。エコシステム、名前、版を 1 つの文字列で表すため、脆弱性情報の側と機械的に照合できる。逆に、ロックファイルが無く版範囲のままの部品は生成ツールが版を確定できず、記録が粗くなる。

CI/CD での活用

要点は、リリースする成果物と同じタイミングで SBOM を作り、その SBOM に対して脆弱性照合をかけることである。別々に走らせると、照合した対象と出荷した対象が一致しなくなる。

# GitHub Actions: ビルド時に SBOM を生成し、脆弱性をスキャン
- name: Generate SBOM
  run: npx @cyclonedx/cyclonedx-npm --output-file sbom.json
- name: Scan vulnerabilities
  run: trivy sbom sbom.json --exit-code 1 --severity HIGH,CRITICAL
- name: Upload SBOM
  uses: actions/upload-artifact@v4
  with:
    name: sbom
    path: sbom.json

AWS での SBOM

• Amazon Inspector: 監視対象のリソースについて SBOM を生成し、CycloneDX 1.4 または SPDX 2.3 互換の JSON として指定した S3 バケットへ書き出せる
• AWS CodeBuild: buildspec に生成コマンドを入れ、ビルド成果物と同じ場所に SBOM を残す

運用でつまずくのは、生成を自動化した後の保管と突合である。どの成果物に対する SBOM なのかを紐づけずに置くと、脆弱性が公開された日に「本番で動いているのはどれか」が分からなくなる。成果物のダイジェストを鍵にして保存し、保存期間はそのバージョンのサポート期間に合わせて決めておく。