CRAにおけるSBOM要件を整理する-lunaplus.net

CRAとSBOMの関係

EUのCRA（Cyber Resilience Act）が発効し、デジタル要素を持つ製品に対して、開発時だけでなく運用段階まで含めたセキュリティ要件が明確になりました。その中でもSBOM（Software Bill of Materials）は、脆弱性対応の基礎情報として扱われています。

今回は、CRA本文と関連ガイダンスを見ながら、「最低限どこまでSBOMを準備すればよいか」を実務目線で整理します。

CRA本文で押さえるポイント

CRAでは、Annex I Part II (1) にて、製造事業者がコンポーネントと脆弱性を識別・文書化することが求められています。ここで重要なのは、SBOMについて次の2点が明示されていることです。

一般的に使用される形式であること
機械可読であること

加えて、最低ラインとして「トップレベル依存関係」を含める必要があります。

なお、SBOMの詳細フォーマットや必須項目は、Article 13(24) に基づく実施法で今後具体化される予定です。

公開義務と提出義務

SBOMは「常に公開しなければならない」ものではありません。 Recital (77) の考え方では、公開は義務ではなく、市場監視当局から要求された場合に提出できる状態で管理しておくことが重要です。

実務としては、次の運用方針が現実的です。

外部公開を前提にせず、内部管理を基本にする
要請時にすぐ提出できるよう、常に最新状態を維持する
製品バージョンとSBOMの対応関係を追跡できるようにする

フォーマットは何を選ぶべきか

CRA本文は特定フォーマットを指定していませんが、現時点では SPDX と CycloneDX が有力候補です。

SPDX: 国際標準化されており、ライセンス情報との親和性が高い
CycloneDX: セキュリティユースケース向けの項目拡張がしやすい

どちらを選ぶ場合でも、依存関係とコンポーネント識別子（例: PURL）を機械的に扱える構造にしておくことが最優先です。

BSI TR-03183-2をどう使うか

ドイツBSIのTR-03183-2は法的拘束力はありませんが、 CRA準拠準備の実装ガイドとしては非常に具体的です。とくに、コンポーネント単位の追加情報（実行可能性、アーカイブ性、実効ライセンスなど）を整理する際の参考になります。

例えばCycloneDXでは、以下のように properties で拡張情報を付与できます。
（コンポーネント部分の抜粋）

{
  "name": "openssl",
  "version": "3.0.15",
  "type": "library",
  "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" }
  ]
}

まず実施しておきたいチェック項目

運用で詰まりやすいポイントを先にチェックリスト化しておくと進めやすいです。

SBOMをSPDXまたはCycloneDXで自動生成できる
生成物に作成日時・作成ツール・文書識別子が含まれる
製品本体とトップレベル依存関係を追跡できる
各コンポーネントに名称・バージョン・PURLを持たせる
脆弱性対応プロセスとSBOM更新手順を紐づける
当局要請時の提出フロー（担当者、保管場所、提出形式）を決める

適用スケジュール（要点）

2024-12-10  CRA 発効
2026-09-11  脆弱性/インシデント報告義務の適用開始
2027-12-11  主要義務（SBOM要件を含む）の適用開始

実施法や調和規格の確定は今後の更新ポイントになるため、「最小要件を先に満たし、差分を後追いで吸収する」進め方が安全です。

CRAにおけるSBOM要件を整理する

ToC