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」という略語は直接的に使用されていないものの、「software bill of materials」として以下の条項や附属書内で明確に SBOM の作成・管理・提供に繋がる要件が規定されています。
具体的には以下の内容です。
CRA に記載されている必須要件には「サイバーセキュリティ要件」と「脆弱性対処要件」が存在し、脆弱性対処要件の中でSBOM作成が求められています。
第13条では、市場監査局に SBOM 提出を求められる可能性があることが記載されています。
また、SBOM のフォーマットについてはまだ明確化されていませんが、将来的に SBOM 要件が具体的に定められる可能性が示唆されています。
第31条では、継続的に SBOM を更新し続ける必要があることが記載されています。
セキュリティアップデート等によってソフトウェアのコンポーネントや依存関係に変更が加わった際には、SBOM への反映も必要になると考えられます。
（補足）技術文書（technical documentation）には SBOM も含まれることが附属書VII (Annex VII)に記載されています。
以上の内容から、現時点では CRA 準拠に向けて以下のような SBOM 対応が求められていると考えることができます。
以上の通り、CRA で求められる具体的な SBOM の形式要件はまだ明確になっていませんので、分かっている範囲で準備を進めていくことになります。
ドイツの BSI が発行している技術ガイドライン「TR-03183」は、製造業者が CRA 準拠に向けて必要となる具体的な対応を事前に把握できるようにすることを目的として策定されており、現時点から準備を進めるうえで参考となるガイドラインの1つです。
以降では、TR-03183 で推奨されている SBOM の具体的なフォーマットについて解説します。
CRA の附属書Iの中では「一般的に使用され、機械可読な形式でSBOMを作成すること」という表現が利用されています。
TR-03183 では下記ツールを利用することが推奨されています。
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: YYYYMMDDThh: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 など |
TR-03183 では SBOM に脆弱性情報は含めるべきではないと言及しています。
SBOM は製品を更新をしない限り変更されない静的な情報のみで構成し、時間経過とともに変化する脆弱性情報は CSAF 形式での配布を推奨しています。
CRA が具体的な SBOM 要件を公開してからの対応開始ではなく、現時点で公開されている情報をもとに、事前に SBOM 作成のフローを確立しておくことが推奨されます。
FutureVuls では SBOM や脆弱性に関する管理を徹底的に自動化することが可能です。
また、CRA で求められる SBOM 要件に合わせて、FutureVuls は継続的に機能アップデートをしていく予定ですので、CRA 準拠に向けた SBOM 管理フローの確立にご興味があれば、ぜひ FutureVuls までお問い合わせください。
本記事は、2025年5月8日時点で入手可能な下記の情報を元に作成しています。