FutureVuls Blog

EUサイバーレジリエンス法(CRA)準拠に向けたSBOM対応

はじめに

EUサイバーレジリエンス法(Cyber Resilience Act、以下「CRA」)は、欧州連合が提唱するサイバーセキュリティに関する規制です。
EU市場に売り出すデジタル製品、および販売する製造業者が対象となっており、違反した場合にはEU市場からの排除を含む厳しい措置が取られる可能性があるため、対応は喫緊の課題です。

CRA が要求する重要な要素の一つとして「SBOM対応」が含まれています。
本記事では、CRA における SBOM 対応に焦点を絞って情報をまとめました。
また、CRA には具体的な SBOM フォーマットについては明言されていないため、ドイツの BSI が発行している技術ガイドライン「TR-03183」を参考に、CRA 準拠に向けた具体的な SBOM の形式要件について考察します。

本記事で得られること

  • CRA で求められる SBOM の基本的な要件について理解できます。
  • TR-03183 を参考に、CRA 準拠のために推奨される SBOM の具体的なフォーマットについて実践的に学べます。

CRAの内容から読み解くSBOM要件

現時点の CRA の本文中で「SBOM」という略語は直接的に使用されていないものの、「software bill of materials」として以下の条項や附属書内で明確に SBOM の作成・管理・提供に繋がる要件が規定されています。
具体的には以下の内容です。

附属書I (Annex I) - 脆弱性対処要件

CRA に記載されている必須要件には「サイバーセキュリティ要件」と「脆弱性対処要件」が存在し、脆弱性対処要件の中でSBOM作成が求められています。

1
2
3
4
5
Part II – Vulnerability handling requirements
Manufacturers of products with digital elements shall:
(1) identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products;

デジタル要素を含む製品に含まれる脆弱性およびコンポーネントを特定し、文書化する。これには、少なくとも製品の最上位レベルの依存関係を網羅する、一般的に使用され、機械可読な形式でソフトウェア部品表(SBOM)を作成することを含む。

第13条 (Article 13) - 製造業者の義務と SBOM 提出義務

第13条では、市場監査局に SBOM 提出を求められる可能性があることが記載されています。

1
2
3
22.   Manufacturers shall, upon a reasoned request from a market surveillance authority, provide that authority, in a language which can be easily understood by that authority, with all the information and documentation, in paper or electronic form, necessary to demonstrate the conformity of the product with digital elements and of the processes put in place by the manufacturer with the essential cybersecurity requirements set out in Annex I. 

製造業者は、市場監視当局からの正当な要請があった場合、当該当局が容易に理解できる言語で、紙媒体または電子媒体により、当該製品がデジタル要素を備えていること、および製造業者が実施したプロセスが附属書Iに定める必須のサイバーセキュリティ要件に適合していることを証明するために必要なすべての情報および文書を当該当局に提供しなければならない。

また、SBOM のフォーマットについてはまだ明確化されていませんが、将来的に SBOM 要件が具体的に定められる可能性が示唆されています。

1
2
3
24.   The Commission may, by means of implementing acts taking into account European or international standards and best practices, specify the format and elements of the software bill of materials referred to in Part II, point (1), of Annex I. Those implementing acts shall be adopted in accordance with the examination procedure referred to in Article 62(2).

委員会は、欧州または国際的な基準およびベストプラクティスを考慮した実施法令により、附属書Iの第II部第(1)項に規定するSBOMの形式および要素を規定することができる。これらの実施法令は、第62条第2項に規定する審査手続きに従って採択されるものとする。

第31条 (Article 31) - 技術文書としての SBOM 継続更新義務

第31条では、継続的に SBOM を更新し続ける必要があることが記載されています。
セキュリティアップデート等によってソフトウェアのコンポーネントや依存関係に変更が加わった際には、SBOM への反映も必要になると考えられます。

1
2
3
2.   The technical documentation shall be drawn up before the product with digital elements is placed on the market and shall be continuously updated, where appropriate, at least during the support period.

技術文書は、デジタル要素を含む製品が市場に投入される前に作成され、必要に応じて少なくともサポート期間中は継続的に更新されるものとします。

(補足)技術文書(technical documentation)には SBOM も含まれることが附属書VII (Annex VII)に記載されています。

1
2
3
4
5
6
7
The technical documentation referred to in Article 31 shall contain at least the following information, as applicable to the relevant product with digital elements:
...
2.(b)
necessary information and specifications of the vulnerability handling processes put in place by the manufacturer, including the software bill of materials, the coordinated vulnerability disclosure policy, evidence of the provision of a contact address for the reporting of the vulnerabilities and a description of the technical solutions chosen for the secure distribution of updates;

第31条に規定する技術文書には、デジタル要素を有する関連製品に該当する少なくとも以下の情報を含めるものとする。
2.(b) 製造業者が導入した脆弱性処理プロセスに関する必要な情報と仕様(SBOM、脆弱性開示ポリシーの調整、脆弱性の報告に関する連絡先の提供の証拠、更新プログラムの安全な配布のために選択された技術的ソリューションの説明など)

CRA における SBOM 要件まとめ

以上の内容から、現時点では CRA 準拠に向けて以下のような SBOM 対応が求められていると考えることができます。

  • 将来的に明確化されるフォーマットに沿って SBOM を作成すること
  • 市場監査局から要請があった場合に SBOM を提出できる状態にしておくこと
  • セキュリティアップデート等に合わせて継続的に SBOM を更新すること

BSI TR-03183 が示す「CRA 準拠 SBOM」フォーマットの詳細

以上の通り、CRA で求められる具体的な SBOM の形式要件はまだ明確になっていませんので、分かっている範囲で準備を進めていくことになります。
ドイツの BSI が発行している技術ガイドライン「TR-03183」は、製造業者が CRA 準拠に向けて必要となる具体的な対応を事前に把握できるようにすることを目的として策定されており、現時点から準備を進めるうえで参考となるガイドラインの1つです。

以降では、TR-03183 で推奨されている SBOM の具体的なフォーマットについて解説します。

SBOMフォーマット

CRA の附属書Iの中では「一般的に使用され、機械可読な形式でSBOMを作成すること」という表現が利用されています。
TR-03183 では下記ツールを利用することが推奨されています。

  • SPDX(v2.2.1以上)
  • CycloneDX(v1.5以上)

データフィールド

TR-03183 で推奨されるデータフィールドと、SPDX (v2.2.1) および CycloneDX (v1.5) フォーマットにおける対応項目(または最も近い概念)をマッピングし、以下の表にまとめました。

各データフィールドの具体的な項目値は、それぞれのコミュニティが公開している Examples も参考になります。

注意点

  • SPDXとCycloneDXのバージョンによってフィールド名や構造が若干異なることがあります。ここでは下記バージョンに基づいています
    • SPDX: v2.2.1
    • CycloneDX: v1.5
  • 下記の表は、公開されている下記仕様書や関連情報に基づいて作成しましたが、解釈によっては異なるマッピングも考えられます。
BSI TR-03183 データフィールド SPDX v2.2.1(Tag) CycloneDX v1.5(JSON) 備考
SBOM全体フィールド
SBOM作成者 (Creator of the SBOM) Creator: Tool: {ツール名},
Creator: Organization: {組織名},
Creator: Person: {人物名}
metadata.authors,
metadata.tools
タイムスタンプ (Timestamp) Created: YYYY­MM­DDThh:mm:ssZ metadata.timestamp
SBOM-URI SBOM 自体の URI がある場合に記録
標準的なフォーマットは無し
各コンポーネントのフィールド
コンポーネント作成者 (Component creator) PackageSupplier: Person: {個人名} ({メールアドレス}),
PackageSupplier: Organization: {組織名} ({メールアドレス})
components[].supplier,
components[].author
コンポーネント名 (Component name) PackageName: {パッケージ名},
ファイルの場合は FileName: {ファイルパス}
components[].name
コンポーネントバージョン (Component version) PackageVersion: {パッケージバージョン} components[].version
コンポーネントのファイル名 (Filename of the component) PackageFileName components[].properties
他のコンポーネントへの依存関係 (Dependencies) Relationship: {コンポーネントID} <relationship(依存関係の種類)> {依存先コンポーネントID} dependencies CRA では 「少なくとも最上位レベルの依存関係を網羅する」と表現
関連ライセンス (Associated licences) PackageLicenseConcluded,
(ファイルの場合は) LicenseConcluded
components[].licenses
コンポーネントのハッシュ値 (Hash value) PackageChecksum: SHA512: {ハッシュ値} (ファイルの場合は FileChecksum) components[].hashes TR-03183 では SHA-512 ハッシュ値を推奨
実行可能プロパティ (Executable property) PackageAttributionText components[].properties 実行可能なコンポーネントであるか記録するフィールド。
実行可能なコンポーネントの例としてはバイナリなどの実行ファイルや、プログラムコード、ライブラリなど。
executable もしくは non-executable で表現。
標準フィールドがないため、カスタムフィールド等での表現が必要となる。
ref: TR-03183 5.2.2, 8.1.3
アーカイブプロパティ (Archive property) PackageAttributionText components[].properties アーカイブ済みのコンポーネントであるか記録するフィールド。
archive もしくは no archive で表現。
標準フィールドがないため、カスタムフィールド等での表現が必要となる。
ref: TR-03183 5.2.2, 8.1.4
構造化プロパティ (Structured property) PackageAttributionText components[].properties 構造化されたコンポーネントであるか記録するフィールド。
例としてコンテナイメージや、パッケージ、zipファイルなど。
structured もしくは unstructured で表現。
標準フィールドがないため、カスタムフィールド等での表現が必要となる。
ref: TR-03183 5.2.2, 8.1.5
コンポーネントのURI (URI of deployable form) PackageDownloadLocation components[].externalReferences
ユニーク識別子 (Other unique identifiers) ExternalRef: SECURITY cpe23Type {CPE},
ExternalRef: PACKAGE-MANAGER purl {purl} など
components[].cpe, components[].purl など

SBOM に脆弱性情報を含めない理由

TR-03183 では SBOM に脆弱性情報は含めるべきではないと言及しています。
SBOM は製品を更新をしない限り変更されない静的な情報のみで構成し、時間経過とともに変化する脆弱性情報は CSAF 形式での配布を推奨しています。

最後に

CRA が具体的な SBOM 要件を公開してからの対応開始ではなく、現時点で公開されている情報をもとに、事前に SBOM 作成のフローを確立しておくことが推奨されます。

FutureVuls では SBOM や脆弱性に関する管理を徹底的に自動化することが可能です。
また、CRA で求められる SBOM 要件に合わせて、FutureVuls は継続的に機能アップデートをしていく予定ですので、CRA 準拠に向けた SBOM 管理フローの確立にご興味があれば、ぜひ FutureVuls までお問い合わせください。

お問い合わせはこちら

参考文献

本記事は、2025年5月8日時点で入手可能な下記の情報を元に作成しています。