SBOMの最小構成要素が増えた

{
  "components": [
    {
      "type": "library",
      "name": "libssl",
      "version": "3.0.13",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "b4c2a1e9f7d3..."
        }
      ]
    }
  ]
}

アルゴリズムの命名はIANAのHash Function Textual Namesに従う

Component License

[既存主要フォーマットでのサポート]
SPDX 2.x: 必須だが値で回避できるので実質任意　SPDX 3.x: 任意　CycloneDX: 任意

コンポーネントが依拠するライセンス識別子

識別子がない場合はURLで詳細への導線を示すか、「unknown」と明記

プロプライエタリライセンスの存在有無もここに含めろとあるので、社内ライブラリを混ぜていると手間が増えそう

{
  "name": "libssl",
  "version": "3.0.13",
  "licenses": [
    { "license": { "id": "Apache-2.0" } }
  ]
}

SBOM Author Signature

[既存主要フォーマットでのサポート]
SPDX 2.x: 仕様外　SPDX 3.x: 仕様外　CycloneDX: 任意

SBOM自体に対するデジタル署名

CycloneDXならJSF(JSON Signature Format)を使った署名ブロックを付与する

{
  "signature": {
    "algorithm": "ES256",
    "value": "MEUCIQDx...",
    "publicKey": {
      "kty": "EC",
      "crv": "P-256",
      "x": "f83OJ3D2...",
      "y": "x_FEzRu9..."
    }
  }
}

SBOM Data Format Name / SBOM Data Format Version

[既存主要フォーマットでのサポート]
SPDX 2.x: 必須(一体化"spdxVersion": "SPDX-2.3")　SPDX 3.x: 必須(一体化)　CycloneDX: 必須

SBOM自体のフォーマットとバージョンを記載

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6"
}

非推奨バージョンのSBOMは受け取り拒否していい、というルールも合わせて明記された

SBOM Generation Context

[既存主要フォーマットでのサポート]
SPDX 2.x: 非対応　SPDX 3.x: 非対応　CycloneDX: 任意

SBOMがソフトウェアライフサイクルのどの段階で生成されたかを示す項目

SBOMはどの段階で生成したかで依存網羅性が変わる

リポジトリからは開発者の意図した依存を
イメージからは本番デプロイの全容を
ランタイム生成では実際に呼び出され、到達可能性のあるものを映す

リファレンスには

この要素には、「ビルド前」「ビルド中」「ビルド後」といった一般的なソフトウェアライフサイクルの参照だけでなく、より具体的な識別子も使用できます

とあるが、任意の値でOKでいいのだろうか

{
  "metadata": {
    "lifecycles": [
      { "phase": "post-build" }
    ]
  }
}

SBOM Tool Name / SBOM Tool Version

[既存主要フォーマットでのサポート]
SPDX 2.x: 任意　SPDX 3.x: 任意　CycloneDX: 任意

SBOMの生成に使ったツール名とそのバージョン

{
  "metadata": {
    "tools": {
      "components": [
        { "type": "application", "name": "cyclonedx-npm", "version": "3.4.1" }
      ]
    }
  }
}

SBOM Version

[既存主要フォーマットでのサポート]
SPDX 2.x: 非対応　SPDX 3.x: 非対応　CycloneDX: 任意

SBOMドキュメントそのもののバージョン, SemVer

SBOMは一度作って終わりではなく、SDLCに伴って更新され続ける
VEXや推移依存関係の更新によりアプリバージョンとはタイミングがことなることに注意

{
  "metadata": {
    "properties": [
      { "name": "sbom:version", "value": "1.2.0" }
    ]
  }
}

CycloneDXはSemVerを表現できないのでpropertiesにカスタムフィールドとして持たせることになる

ついでに既存フィールドの用語も変わった

新設フィールドとは別に、既存フィールドの名称・定義変更もいくつかある

Supplier Name → Component Producer に改称
「サプライヤー」という語が流通業者と製造元の区別で混乱を招いていたための変更
Other Unique Identifiers → Component Identifiers に改称
CPEやPURLなど、共通識別子を最低1つ含めることが必須になった
Depth → Coverage に改称
「深さ」ではなく「網羅性」という考え方に変わり、推移的依存も対象に含むことが明記された
Access Controls は廃止
内容は Distribution and Delivery に統合された

命名の話だけに見えて、実際はSBOM管理システム側のフィールドマッピングに直結する変更
パーサー自前のプロジェクトでは面倒になりそう

所感

SBOMの運用はただ収集して保管することから変わった
サプライチェーン攻撃の激化もあり、鮮度と生成時点、網羅性が運用に重要なことが明らかになった
今回の変更はこの状況を反映していると思っている

管理ツール側での対応が進むかには言及しないが、普及したら運用はより良くなると思った

個人的に整理するなら、SBOM運用は3つの軸を改善しながら実態のマッピングを進める必要がある

依存・コンポーネント間・時間

「依存」は推移的関係を含めた網羅性と実際の呼び出しの依存性が追跡できているか

「コンポーネント間」は識別の正確性, コンポーネントをまたいだ共通依存が整理できているか

「時間」はSDLCのどのフェーズで生成されたのか、そしてアプリ更新とは非同期に回る運用フローがあるか

依存性を追うことが主目的だった線の運用から
面のつながりへと強化するために今回の改訂が後押しになればいいんじゃなかろうか

RiiiM

Author: RiiiM

Backend Developer

SBOMの最小構成要素が増えた

SBOM最小要素の変更

変わったよ

新要素たち

Component Hash Value / Component Hash Algorithm