はじめに

EUのCyber Resilience Act（CRA）は、デジタル要素を有する製品に対して、製品ライフサイクル全体を通じたサイバーセキュリティ対応を求める規制です。欧州市場で製品を提供する企業にとって、CRA対応は今後避けて通れない課題です。

特に注意すべきなのが、CRAにおける脆弱性報告義務です。CRAの主要な義務は2027年12月11日から適用されますが、積極的に悪用されている脆弱性や、製品のセキュリティに影響する重大インシデントに関する報告義務は2026年9月11日から適用されています。

また、CRAには罰則も定められています。たとえば、ANNEX Iに定める必須サイバーセキュリティ要件や製造者の義務に違反した場合、最大1,500万ユーロ（約26億円）、または企業の場合は前会計年度の全世界年間売上高の2.5%のいずれか高い方を上限とする行政罰金の対象となる可能性があります。

CRAの脆弱性ハンドリング要件では、脆弱性処理方針、CVD（協調的脆弱性開示）ポリシー、報告受付体制、リスク評価、是正判断、セキュリティアップデートの配布体制など、幅広い取り組みが必要です。その中でも、製品に含まれるソフトウェアコンポーネントを把握し、脆弱性情報と突き合わせるための基盤として重要になるのがSBOM（Software Bill of Materials：ソフトウェア部品表）です。

本記事では、CRAの脆弱性ハンドリング要件におけるSBOMの位置付けを整理し、SBOM作成・管理を支援するツールを活用することが、CRA対応にどの程度貢献するか解説します。

INDEX

はじめに

ANNEX I Part IIとEN 40000-1-3の関係

SBOMの役割とSBOM作成ツールの活用
┗そもそもSBOMとは何か
┗脆弱性ハンドリングでは「コンポーネント」と「脆弱性情報」を結び付けることが重要
┗SBOM作成ツールを活用する意義

ONEKEYで生成されるSBOMの内容

EN 40000-1-3の要求に対するSBOMの充足
┗SBOMが直接関係する主な要求事項と支援内容
┗ONEKEYで生成したSBOMが要求事項に貢献できるポイント
┗SBOMだけでは満たせない領域も明確にしておく

まとめ：CRA対応に向けた弊社サービス
┗　関連サービスのご紹介

ANNEX I Part IIとEN 40000-1-3の関係

CRAにおける脆弱性ハンドリング要件は、主にANNEX I Part IIに定められています。ANNEX I Part IIでは、SBOMの作成、脆弱性への対処、定期的なテストとレビュー、CVDポリシー、安全なアップデート配布など、製造者が行うべき脆弱性ハンドリングの方向性が示されています。

一方で、ANNEX I Part IIの記載は比較的抽象的です。たとえば「製品に含まれる脆弱性およびコンポーネントを特定し、文書化すること」「SBOMの作成を含む」といった要求はありますが、それだけでは、どの程度の粒度で対応すべきか判然としない場合があります。

そこで重要になるのが、ANNEX I Part IIを具体的な要求事項・推奨事項に落とし込む整合規格候補であるEN 40000-1-3です。

EN 40000-1-3では、まずAPP（Applicability：適用可能性）で、製品のリスクに応じて脆弱性ハン
ドリングの実施内容や厳格さを決定することで基本方針を示しています。
そのうえで、脆弱性ハンドリングに必要な活動が、以下のようなフェーズとして整理されています。

フェーズ	名称	概要
PRE	Preparation（準備）	方針、SBOM、コンポーネント識別、テスト計画、配布の仕組みなどを整備する
RCP	Receipt（受付）	脆弱性情報の受付、監視、影響を受けるコンポーネントの特定を行う
VRF	Verification（検証）	報告された脆弱性の評価、リスク評価、優先順位付けを行う
RMD	Remediation（是正）	是正判断、是正の開発、是正のテストを行う
RLS	Release（リリース）	セキュリティ更新や修正済み脆弱性情報をリリースする
PRA	Post-release（リリース後）	リリース後の保守、是正の監視を行う

これらの規格の関係は、次のように整理できます。

• CRA：全体の法的枠組みを定める
• ANNEX I Part II：脆弱性ハンドリングの必須要件を示す
• EN 40000-1-3：ANNEX I Part IIの要件を、実務レベルのフェーズや要求事項へ落とし込む

SBOMの役割とSBOM作成ツールの活用

そもそもSBOMとは何か

SBOM（Software Bill of Materials）とは、製品に含まれるソフトウェアコンポーネントを一覧化し、コンポーネント名、バージョン、サプライヤー、ライセンス、識別子、依存関係などを整理した「ソフトウェア部品表」です。製造業における部品表が製品を構成する部品を把握するために使われるのと同じように、SBOMはソフトウェア製品やファームウェアに含まれる部品を把握するために使われます。

SBOMの役割は、単にコンポーネントを一覧化することにとどまりません。製品に含まれるコンポーネントを把握できれば、脆弱性データベースと突き合わせることで、その製品が既知の脆弱性の影響を受ける可能性があるか確認することができます。また、製品開発段階からSBOMを作成・更新しておくことで、脆弱性を早期に発見し、リリース直前やリリース後の手戻りを減らすことも期待できます。

ANNEX I Part IIでは、デジタル要素を有する製品に含まれる脆弱性およびコンポーネントを特定し、文書化することが求められています。

また、EN 40000-1-3でも、特にPRE-7「ソフトウェアコンポーネントの識別」において、SBOMに関する要求事項が整理されています。

脆弱性ハンドリングでは「コンポーネント」と「脆弱性情報」を結び付けることが重要

コンポーネントに含まれる脆弱性の把握のためには、コンポーネント名やバージョンだけでなく、PURL（Package URL）やCPE（Common Platform Enumeration）など、脆弱性データベースとの突き合わせに利用できる識別情報が有効です。これらの識別情報を用いることで、NVDやOSVなどの脆弱性情報とコンポーネントを結び付けやすくなり、CVEの確認、影響範囲の整理、優先順位付けのための材料を得やすくなります。

後述する、SBOM管理・脆弱性分析ツールである「ONEKEY」では、検出したソフトウェアコンポーネントに対して、PURLやCPEなどの識別情報を含む形で情報を整理できます。

また、検出されたコンポーネントに関連する脆弱性情報を取得し、コンポーネントごとのCVEや重要度を確認できます。これにより、単にSBOMを作成するだけでなく、SBOMを起点に、脆弱性情報の把握や影響を受けるコンポーネントの特定につなげることができます。

SBOM作成ツールを活用する意義

SBOMは手作業でも作成できますが、製品に含まれるコンポーネントが多い場合や、ファームウェアを含む組込み機器のように、ソフトウェア構成の把握が難しい場合、手作業だけで正確性と継続性を確保することは容易ではありません。
そこで、SBOM作成や脆弱性分析を支援するツールを活用することで、次のような効果が期待できます。

• ソフトウェアコンポーネントの洗い出しを効率化できる
• コンポーネントに紐づくPURLやCPEなどの識別情報を整理しやすくなる
• 機械可読形式のSBOMを出力しやすくなる
• CVEなどの既知の脆弱性情報とコンポーネントを突き合わせやすくなる
• 再スキャンにより、是正対象の脆弱性が解消されたかを確認しやすくなる
• 脆弱性情報の更新や再スキャン、モニタリングによって継続的な脆弱性の確認が容易になる

弊社では、SBOM作成やファームウェア解析を支援するサービスとしてONEKEYを提供しています。
ONEKEYは、バイナリファームウェアをアップロードすることで、製品に含まれるソフトウェアコンポーネントを解析し、関連する既知の脆弱性を確認できるSaaSプラットフォームです。

ONEKEYの特徴は、ソースコードではなく、バイナリファイルやファームウェアイメージを解析対象にできる点です。

IoT機器や組込み機器では、開発委託先やサプライチェーンの事情により、ソースコードや完全な部品表をすぐに用意できないケースがあります。

そのような場合でも、バイナリを起点にSBOMや脆弱性情報を取得することができます。

ONEKEYで生成されるSBOMの内容

ONEKEYではSPDX形式およびCycloneDX形式のSBOMを生成することができ、いずれも機械可読な形式で構成されています。 出力される情報を整理すると、主に次のようになります。

出力される情報	内容	CRA／EN 40000-1-3への貢献
SBOMのメタデータ	SBOMの形式、バージョン、作成者、作成日時など	機械可読なSBOMの作成や、SBOM作成者・バージョン・タイムスタンプの管理に関係する
対象製品・ファームウェアの識別情報	製品名、ファームウェアファイル名、サプライヤー、ファームウェア種別など	製品識別を支援する情報として活用できる
ソフトウェアコンポーネント情報	コンポーネント名、バージョン、種別、ライセンス、関連ファイルなど	製品に含まれるソフトウェアコンポーネントの識別・文書化を支援する
PURL・CPEなどの識別情報	パッケージや製品を識別するための標準的な識別子	NVDやOSVなどの脆弱性情報とコンポーネントを突き合わせる際の手掛かりになる
ハッシュ・検証情報	ファームウェア、ファイル、コンポーネントに関するハッシュ値や検証情報	対象ファイルやコンポーネントの同一性確認、再スキャン時の差分確認、証跡管理に役立つ
依存関係・包含関係	コンポーネント同士の依存関係や、ファームウェア内に含まれるファイルとの関係	ANNEX I Part IIの1で求められる、少なくともトップレベルの依存関係を含むSBOMの作成に関係する
脆弱性情報との紐付け	CVE ID、情報源、深刻度、CVSS等の評価情報、影響を受けるコンポーネントへの参照など	製品およびそのコンポーネントで見つかった脆弱性を把握し、影響を受ける可能性があるソフトウェアコンポーネントの特定に役立つ

このように、ONEKEYで生成されるSBOMには、単なるコンポーネント一覧だけでなく、コンポーネントを一意に識別するための情報や、脆弱性情報と突き合わせるための情報も含まれます。

特にPURLやCPEのような識別情報は、コンポーネント名やバージョンだけでは判断しにくい既知の脆弱性との対応関係を整理するうえで重要です。

EN 40000-1-3の要求に対するSBOMの充足

本記事で参照したEN 40000-1-3のドラフト版には、64件の要求事項（RQ）と14件の推奨事項（RC）が定義されています。ONEKEYを使って生成したSBOMおよびONEKEYの関連機能が、これらの要求／推奨事項に対して、どの程度充足または支援できるか整理しました。

判定基準は次のようになります。

• 可：ONEKEYの機能単体で要求を満たしている
• 部分的：ONEKEYの機能で要求の一部を満たしている
• 不可：ONEKEYの機能だけでは要求の充足が難しい
• 不明：ONEKEYの機能で要求をどの程度満たすことができるのか判断できない

評価結果は以下のとおりです。

判定	要求事項	推奨事項	合計
可	3件（4.68%）	0件（0%）	3件（3.84%）
部分的	24件（37.5%）	2件（14.28%）	26件（33.33%）
不可	35件（54.68%）	12件（85.71%）	47件（60.25%）
不明	2件（3.12%）	0件（0%）	2件（2.56%）
合計	64件	14件	78件

部分的に要求を満たしている項目も合わせると、ONEKEYによって、EN 40000-1-3の要求／推奨事項のうち、おおよそ37%の項目について、何らかの形で充足または支援できているという結果になりました。

この表を見る際に重要なのは、EN 40000-1-3には、SBOM作成やコンポーネント識別だけでなく、CVDポリシーの策定、報告受付、報告者・利用者とのコミュニケーション、リスク評価、是正判断、セキュリティ更新の配布など、組織的な運用プロセスに関する要求が多く含まれるという点です。

そのため、SBOM作成ツール単体で「すべての要求を満たす」ことは想定すべきではありません。一方で、可または部分的に充足できる項目は、SBOM作成、ソフトウェアコンポーネントの識別、CVEとの突き合わせ、是正後確認、リリース後監視など、脆弱性ハンドリングの基礎となる領域に集中しています。

運用プロセスに関する要求を除いて集計した場合、以下のようになります。

判定	要求事項	推奨事項	合計
可	3件（6.38%）	0件（0%）	3件（6.12%）
部分的	24件（51.06%）	2件（100.00%）	26件（53.06%）
不可	18件（38.29%）	0件（0%）	18件（36.73%）
不明	2件（4.25%）	0件（0%）	2件（4.08%）
合計	47件	2件	49件

運用プロセスを除いた場合、EN 40000-1-3の要求／推奨事項のうち、おおよそ59%の項目について、何らかの形で充足または支援できているという結果になります。

SBOMが直接関係する主な要求事項と支援内容

以下は、EN 40000-1-3のうち、ONEKEYによって充足または支援を期待できる主な項目です。

PRE-6	製品の識別	製品は、製造者名・製品名・ハードウェア／ソフトウェア識別子により、構成ごとに識別可能でなければならない
PRE-7	ソフトウェアコンポーネントの識別	製品に含まれるソフトウェアコンポーネントを識別・文書化し、トップレベルの依存関係を最低限含む機械可読なSBOMを、リリースや情報更新に応じて適切に作成・更新しなければならない
PRE-9	定期的なテストとレビューの計画	製品リスクに応じたセキュリティテスト・レビュー計画を策定し、結果および脅威・脆弱性の変化に基づいて継続的に見直すこと
RCP-3	潜在的に影響を受けるソフトウェアコンポーネント	潜在的に影響を受けるソフトウェアコンポーネントを識別しなければならない
RMD-3	是正のテスト	是正後のソフトウェアを再確認し、残存する脆弱性や問題の有無を確認する
PRA-1	リリース後の対応	リリース後も脆弱性の監視や是正状況の確認を継続する

より具体的には、主に以下の要求事項に関係します。

番号	要求	ONEKEYによる支援内容
PRE-6-RQ-01	製品は、少なくとも製造者名、製品名、ハードウェア／ソフトウェア識別子などにより識別可能でなければならない。	SBOM／レポートには製品名、ファームウェアファイル名、ハッシュ、サプライヤー等が含まれるため、ソフトウェア／ファームウェア識別を支援できる。
PRE-7-RQ-01	製品に含まれるすべてのソフトウェアコンポーネントを識別し、文書化しなければならない。	バイナリ／ファームウェア解析からソフトウェアコンポーネント一覧を自動生成できる。
PRE-7-RQ-03	製品に含まれる少なくともトップレベル依存関係を含むSBOMを作成しなければならない。	解析結果を基にSBOMを生成できる。ただし、製品構成によっては依存関係の網羅性確認が別途必要となる。
PRE-7-RQ-04	SBOMは、構造化された機械可読形式で組み立てなければならない。	SPDX形式およびCycloneDX形式でSBOMを生成できる。
PRE-7-RQ-06	SBOMのメタデータには、SBOM作成者、バージョン、タイムスタンプを含めなければならない。	サンプルSBOMには作成者（ONEKEY platform）、作成日時、SPDXバージョン、CycloneDXの仕様バージョンなどのメタデータが含まれている。
PRE-7-RQ-07	SBOMの各コンポーネントについて、コンポーネント名、バージョン、依存関係、一意の識別子などを含めなければならない。	コンポーネント名、バージョン、PURL、CPE、ライセンス情報、関連ファイル、ハッシュ値などを整理できる。
PRE-7-RQ-07-RE	供給者がコンポーネントのハッシュおよび対応するアルゴリズムを提供する場合、それをSBOMに含めなければならない。	ファームウェア全体や関連ファイルについて、SHA-256、SHA-1、MD5などのハッシュ情報を確認できる。
PRE-9-RQ-03	セキュリティレビューでは、製品およびそのコンポーネントで見つかった脆弱性などを考慮しなければならない。	コンポーネントに紐づくCVE、重大度、CVSSなどの情報を確認でき、レビュー時の入力情報として利用できる。
RCP-3-RQ-01	収集された脆弱性情報に基づいて、潜在的に影響を受けるソフトウェアコンポーネントを識別しなければならない。	CVEをコンポーネント別に集計し、CVE一覧にも対象コンポーネントを示すため、影響を受ける可能性があるソフトウェアコンポーネントの識別に利用できる。
RMD-3-RQ-01	脆弱性に関連するリスクが軽減され、製品および利用者への影響が許容可能であることを確認するため、是正をテストしなければならない。	修正後のファームウェアを再解析することで、残存CVEや問題の有無を確認する材料にできる。
PRA-1-RQ-01	リリース後も、脆弱性対応状況の管理や是正状況の監視を実施しなければならない。	モニタリングや再スキャンを通じて、リリース後のソフトウェアに対する継続的な脆弱性確認を支援できる。

ONEKEYで生成したSBOMが要求事項に貢献できるポイント

まとめると、ONEKEYで生成したSBOMおよび関連する脆弱性分析機能は、EN 40000-1-3の要求事項に対して、特に次の点で貢献できます。

第一に、ソフトウェアコンポーネントの識別と文書化です。
CRAの脆弱性ハンドリングでは、製品に含まれるコンポーネントを把握していなければ、脆弱性の影響有無を判断できません。
ONEKEYは、バイナリファームウェアを解析し、ソフトウェアコンポーネント名、バージョン、ライセンス、関連ファイル、ハッシュ値などをSBOMとして整理できます。

第二に、機械可読なSBOMの生成です。
ONEKEYはSPDX形式およびCycloneDX形式のSBOMを出力できます。
これにより、他システムや脆弱性管理プロセスで利用しやすい機械可読な形式でコンポーネント情報を保持できます。

第三に、PURLやCPEを用いた脆弱性情報との突き合わせです。
ONEKEYが生成するSBOMには、検出されたコンポーネントに応じて、PURLやCPEなどの識別情報が記載されます。これらの識別情報は、NVDやOSVなどの脆弱性データベースと照合する際のキーとなります。

第四に、是正後確認やリリース後監視への活用です。
脆弱性対応後のファームウェアを再スキャンすることで、対象コンポーネントに関連する既知の脆弱性が引き続き検出されないか確認できます。
また、脆弱性情報は定期的に更新されるため、定期テストやレビュー計画を見直す際の情報として活用できます。

このように、ONEKEYはCRAの脆弱性ハンドリングの要件全体を単独で満たすツールではありませんが、SBOM作成、コンポーネント識別、脆弱性情報との突き合わせ、是正後確認、リリース後監視といった、脆弱性ハンドリングの土台となる領域に貢献できます。

SBOMだけでは満たせない領域も明確にしておく

SBOM作成は重要ですが、CRAの脆弱性ハンドリングの要件全体を見ると、SBOMだけでは満たせない要求も多くあります。

たとえば、次のような取り組みには、別途対応が必要です。

• 脆弱性処理方針の策定・運用
• CVDポリシーの策定・公開
• 脆弱性報告窓口や報告受付プロセスの整備
• 報告者・利用者との継続的なコミュニケーション
• 非公開脆弱性情報のアクセス制御や運用上のセキュリティ
• 製品リスクプロファイルに基づく最終的なリスク評価
• セキュリティアップデートの安全な配布
• 修正済み脆弱性情報の公開
• ハードウェアコンポーネントの特定

したがって、CRA適合に向けては、SBOM作成ツールを導入するだけでなく、脆弱性管理プロセスやアップデート配布プロセス、CVD対応、リスク評価手法などをあわせて整備する必要があります。

まとめ：CRA対応に向けた弊社サービス

弊社では、CRA対応に向けた支援サービスを提供しています。本サービスは規格理解のトレーニングをはじめ、セキュア開発プロセスの構築支援、リスクアセスメント、サイバーセキュリティ試験、SBOM構築支援、脆弱性管理プロセス（PSIRT）の構築支援、報告体制構築支援（CSIRT）までを提供します。

また、弊社はONEKEYの販売代理店として、ONEKEYの導入をご検討中のお客様に対して、資料請求、課題のヒアリング、デモ画面のご確認や試用アカウントのご提供などにも対応しています。

CRA対応に向けて、まず何から着手すべきか分からない場合や、SBOM作成に課題を感じておられる企業様は、ぜひ弊社サービスの活用をご検討ください。

関連サービスのご紹介

CRA（欧州サイバーレジリエンス法）対策支援サービス

CRA対応を、検討段階から実務まで総合的に支援

CRAへの対応では、規格の理解だけでなく、設計・開発段階からのリスクアセスメント、脆弱性管理、SBOMの整備、インシデントや脆弱性の報告体制など、製品ライフサイクル全体を見据えた準備が求められます。セキュアイノベーションでは、CRAに関するトレーニングをはじめ、セキュア開発プロセスの構築、リスクアセスメント、サイバーセキュリティ試験、SBOM構築、PSIRT・CSIRTの体制構築まで幅広く支援しています。CRA対応をどこから進めるべきかお悩みの方は、ぜひご相談ください。

ONEKEYサービス

CRA対応に向けた製品の脆弱性管理を効率化

CRAへの対応では、製品開発時のセキュリティ対策だけでなく、製品ライフサイクルを通じてソフトウェアコンポーネントや脆弱性を継続的に把握・管理していくことが重要です。ONEKEYは、バイナリファームウェアをアップロードするだけで製品を自動解析し、SBOMの自動生成や脆弱性の検出、最新の脆弱性情報の継続的なモニタリングなどを行えるSaaSプラットフォームです。CRA対応に伴う脆弱性管理やSBOM管理の効率化を検討されている方は、ONEKEYのサービス内容をご覧ください。