セキュリティコラム
- IoT機器
- セキュリティ基準・ガイドライン
- ネットワーク
公開:2026.08.13 11:14 ｜ 更新: 2026.08.13 02:14
CRA適合に必要な脆弱性ハンドリングとは？ ANNEX I Part IIとEN 40000-1-3の関係を解説
はじめに
EUのCyber Resilience Act（CRA）は、デジタル要素を有する製品に対して、製品ライフサイクル全体を通じたサイバーセキュリティ要件への対応を求める規則です。
EU市場へデジタル要素を有する製品を提供するメーカーや、その製品を開発・製造する企業にとって、CRAへの対応は重要な課題となっています。
その中でも特に押さえておくべきテーマの一つが、脆弱性ハンドリングです。
あわせて読みたい
脆弱性ハンドリングとは、製品やその構成部品に存在する脆弱性を収集・ 評価、是正し、利用者へ必要な情報やアップデートを提供する一連の活動を指します。CRAでは、この活動を単発の対応ではなく、製造者が継続的に運用すべきプロセスとして位置付けています。
CRAの主要な義務は2027年12月11日から適用されますが、脆弱性や重大なインシデントに関する報告義務は2026年9月11日から適用されるため、脆弱性ハンドリング体制の整備は早期に着手することが重要です。
本記事では、CRAで求められる脆弱性ハンドリングの全体像と、ANNEX I Part II、さらにその要求を具体化する整合規格候補であるprEN 40000-1-3（以下、EN 40000-1-3）との関係を整理します。
注記 ：EN 40000-1-3については、本記事執筆時点（2026/07/28）でドラフト版を扱っています。実際のCRA対応では、必ず最新の規格文書・公的情報を確認してください。
INDEX
はじめに
ANNEX I Part IIで求められる脆弱性ハンドリング要件
ANNEX I Part IIを具体化するEN 40000-1-3
フェーズの細分化
┗ [PRE] Preparation 準備
┗ [RCP] Receipt 受付
┗ [VRF] Verification 検証
┗ [RMD] Remediation 是正
┗ [RLS] Release リリース
┗ [PRA] Post-release リリース後
ANNEX I Part IIとEN 40000-1-3のマッピング
ANNEX I Part IIで求められる脆弱性ハンドリング要件
CRAでは、デジタル要素を有する製品について、製品そのもののセキュリティだけでなく、製造者が実施するプロセスにもサイバーセキュリティ要件への適合が求められます。
特に脆弱性ハンドリングについては、CRAの附属書であるANNEX I Part IIに必須要件が定められています。
ANNEX I Part II では、8つの項目にわたって、デジタル要素を有する製品の製造者が行わなければならない脆弱性ハンドリングの内容が記載されています。
- デジタル要素を有する製品に含まれる脆弱性およびコンポーネントを特定し、文書化すること。少なくとも製品のトップレベルの依存関係を含む、SBOM（Software Bill of Materials）の作成を含む。
- デジタル要素を有する製品の脆弱性に遅滞なく対処し修正すること（セキュリティアップデートの提供を含む）。技術的に可能な場合、新しいセキュリティアップデートは機能アップデートとは別に提供されなければならない。
- デジタル要素を有する製品に対し、効果的かつ定期的なテストとレビューを実施する。
- セキュリティアップデートが利用可能になった場合、製造者は、修正済みの脆弱性に関する情報（脆弱性の説明、影響を受けるデジタル要素を有する製品を特定できる情報、脆弱性の影響、その深刻度、並びに利用者が当該脆弱性への対応を行うために役立つ明確かつ入手容易な情報を含む）を共有し、公表しなければならない。
- 協調的脆弱性開示（CVD）に関するポリシーを策定し、実施すること。
- デジタル要素を有する製品および当該製品に含まれるサードパーティ製コンポーネントの潜在的な脆弱性に関する情報共有を容易にするための措置を講じること。
- 脆弱性を適時に修正または軽減できるように、デジタル要素を有する製品のアップデートを安全に配布する仕組みを備えること。セキュリティアップデートは必要に応じて自動的に行われること。
- セキュリティアップデートが利用可能な場合、遅滞なく配布されなければならない。また、デジタル要素を有する特注品について製造者と事業者の間で別途合意がある場合を除き、当該アップデートは無償で提供され、利用者に必要な情報（利用者が取るべき可能性のある対応を含む）を提供する勧告メッセージを添付しなければならない。
これらの要件によって、ハンドリングの方向性が示される一方で、実際に脆弱性ハンドリングを行うとなると具体的な要件が見えてこず、何をどの程度対応すればよいのかわかりにくいという問題が浮上します。 そこで重要になるのが、ANNEX I Part IIの要求を、より具体的なプロセスに落とし込むための規格です。
ANNEX I Part IIを具体化するEN 40000-1-3
EN 40000-1-3は、CRA標準化要求に基づき作成が進められている規格案であり、ANNEX I Part IIの脆弱性ハンドリング要求に対応する整合規格候補として位置付けられます。
EN 40000-1-3では、脆弱性ハンドリングに必要な活動が製品ライフサイクルに沿って複数の「フェーズ」として整理されており、フェーズごとに要求事項（RQ：Requirements）と推奨事項（RC：Recommendations）が定義されます。
たとえばANNEX I Part IIの1では、次のように要件が記載されています。
ソフトウェア部品表（SBOM）の作成を含む。
一方、EN 40000-1-3では、以下のように要求事項が定義されています。
SBOMのメタデータには、次を含めなければならない。
— SBOM作成者
— バージョン
— タイムスタンプ
このように、ANNEX I Part IIの抽象的な要求を、EN 40000-1-3の要求事項を参照することで、具体的な対応策へ変換できます。
EN 40000-1-3で定義される6つのフェーズ
EN 40000-1-3では、まずAPP（Applicability：適用可能性）として、脆弱性ハンドリングは製品のリスクに応じて実施内容や厳格さを決定するという基本方針を示しています。
そのうえで、脆弱性ハンドリングの活動を製品ライフサイクルに沿った以下の6つのフェーズに整理しています。
| フェーズ | 名称 | 主な内容 |
|---|---|---|
| PRE | Preparation（準備） | 後続フェーズを支援するための脆弱性の処理および開示のプロセスならびに方針を確立するための基礎を築くことを求める。ソフトウェアおよびハードウェアコンポーネントの識別、SBOMの作成、脆弱性情報の開示および脆弱性処理の方針の確立など |
| RCP | Receipt（受付） | 脆弱性情報の報告を監視し、報告された脆弱性情報に基づき、影響を受けるコンポーネントの識別をすること、および定期的なレビューを実施することを求める |
| VRF | Verification（検証） | 報告された脆弱性のリスク評価を求める。脆弱性に対する優先順位の割り当てなど |
| RMD | Remediation（是正） | 検証済みの脆弱性に対する是正措置を求める。 |
| RLS | Release（リリース） | 是正されたソフトウェアの配布方法や、修正済みの脆弱性の公開を求める |
| PRA | Post-release（リリース後） | リリース後の対応を求める |
フェーズの細分化
さらに、各フェーズは以下のように細分化されます。これらの細分化されたフェーズに、1つ以上の要求事項（RQ）と、0個以上の推奨事項（RC）がそれぞれ定義されています。
[PRE] Preparation 準備
| フェーズ | 概要 | 内容 |
|---|---|---|
| PRE-1 | 脆弱性処理に関する方針 | 脆弱性処理方針を定め、役割・責任・開示防止・修復期限・関係者連携を含む運用体制を構築し、その有効性を継続的に監視すること |
| PRE-2 | 協調的脆弱性開示（CVD）に関する方針 |
CVDの方針を策定・公開し、報告窓口・連絡方法・開示手順を明確化すること |
| PRE-3 | 運用上のセキュリティ | 非公開の脆弱性情報は、必要最小限の関係者に限定して安全に取り扱う |
| PRE-4 | 継続的なコミュニケーション | 報告者・利用者等とのコミュニケーション手段を整備・維持する |
| PRE-5 | セキュアなコミュニケーション | 脆弱性情報の報告対応において、機密性・完全性・匿名性・アクセシビリティを考慮したセキュアなコミュニケーション手段を提供・周知すること |
| PRE-6 | 製品の識別 | 製品は、製造者名・製品名・ハードウェア／ソフトウェア識別子により、構成ごとに識別可能でなければならない |
| PRE-7 | ソフトウェアコンポーネントの識別 | 製品に含まれるソフトウェアコンポーネントを識別・文書化し、トップレベルの依存関係を最低限含む機械可読なSBOMを、リリースや情報更新に応じて適切に作成・更新しなければならない |
| PRE-8 | ハードウェアコンポーネントの識別 | 製品に含まれるハードウェアコンポーネントを特定し、製造者・名称・識別子・ファームウェアバージョンを記録する |
| PRE-9 | 定期的なテストとレビューの計画 | 製品リスクに応じたセキュリティテスト・レビュー計画を策定し、結果および脅威・脆弱性の変化に基づいて継続的に見直すこと |
| PRE-10 | 配布のための仕組み | セキュリティ更新および関連情報を、安全かつ必要に応じて自動的に配布できる仕組みを提供すること |
[RCP] Receipt 受付
| フェーズ | 概要 | 内容 |
|---|---|---|
| RCP-1 | 報告を受け取る能力 | CVDに基づいて脆弱性の報告を受け付け、追跡できる仕組みを整備すること |
| RCP-2 | 監視 |
内外の脆弱性情報源および第三者コンポーネントの状態を継続的に監視すること |
| RCP-3 | 潜在的に影響を受けるソフトウェアコンポーネント | 潜在的に影響を受けるソフトウェアコンポーネントを識別しなければならない |
| RCP-4 | 潜在的に影響を受けるハードウェアコンポーネント | 潜在的に影響を受けるハードウェアコンポーネントを識別しなければならない |
| RCP-5 | コーディネータの関与 | コーディネータを割り当て、脆弱性処理プロセスに関与させることが望ましい |
| RCP-6 | 定期的なテストの実施 | セキュリティテストは、セキュリティテストおよびレビュー計画に従って実施しなければならない |
| RCP-7 | 定期的なレビューの実施 | セキュリティテスト・レビュー計画に基づき、リスク評価の前提や入力情報を少なくとも年1回見直す |
[VRF] Verification 検証
| フェーズ | 概要 | 内容 |
|---|---|---|
| VRF-1 | 初期評価および検証 | EN ISO/IEC 30111:2020に基づき、十分な情報の基、脆弱性の評価を実施する |
| VRF-2 | 脆弱性リスク評価 |
脆弱性について、製品リスクプロファイルに基づきリスク評価・優先順位付けを行い、重大なものは迅速に対応し、CVD由来の場合は報告者へ検証結果を通知する |
[RMD] Remediation 是正
| フェーズ | 概要 | 内容 |
|---|---|---|
| RMD-1 | 是正判断 | EN ISO/IEC 30111:2020, 7.1.5 a に基づき、脆弱性の是正の判断を下し、後続の措置を計画する |
| RMD-2 | 是正の開発 |
脆弱性を是正し、技術的に実現可能な場合、セキュリティ更新は機能更新とは別に提供しなければならない |
| RMD-3 | 是正のテスト |
脆弱性に関連するリスクが軽減され、製品および利用者への影響が許容可能であることを確実にするため、是正をテストしなければならない |
[RLS] Release リリース
| フェーズ | 概要 | 内容 |
|---|---|---|
| RLS-1 | セキュリティ更新のリリース | セキュリティ更新は、原則無償で、真正性・完全性を確保した安全な方法により、適時かつ利用者が適用可能な形で提供しなければならない |
| RLS-2 | リリース情報 |
修正済みの脆弱性情報は、CVD方針に従い、人間・機械可読な形式で、利用者が是正の対応を行える内容として公開する必要がある |
[PRA] Post-release リリース後
| フェーズ | 概要 | 内容 |
|---|---|---|
| PRA-1 | リリース後の対応 | リリース後は保守、是正の監視を行わなければならない |
ANNEX I Part IIとEN 40000-1-3のマッピング
EN 40000-1-3の各フェーズは、ANNEX I Part IIの各要件に対応する形で整理できます。
たとえば、EN 40000-1-3のPRE-5、RCP-1で定義される要求事項／推奨事項を参照することで、ANNEX I Part IIの6で求められる情報共有の仕組みを、具体的な対応項目として整理できます。
| ANNEX I Part II | EN 40000-1-3 |
|---|---|
| ANNEX I Part II (1) | PRE-6、PRE-7、PRE-8、RCP-2、RCP-3、RCP-4 |
| ANNEX I Part II (2) |
PRE-1、PRE-3、PRE-4、RCP-5、VRF-1、VRF-2、RMD-1、RMD-2、RMD-3、RLS-1、PRA-1 |
| ANNEX I Part II (3) | PRE-9、RCP-2、RCP-6、RCP-7、PRA-1 |
| ANNEX I Part II (4) | PRE-6、RLS-2 |
| ANNEX I Part II (5) | PRE-2 |
| ANNEX I Part II (6) | PRE-5、RCP-1 |
| ANNEX I Part II (7) | PRE-10、VRF-2、RLS-1、PRA-1 |
| ANNEX I Part II (8) | PRE-10、RLS-1、RLS-2 |
※ EN 40000-1-3 Table ZA.1 — Correspondence between this European Standard and Annex I of the Cyber Resilience Act を基に作成
まとめ
本記事では、CRAにおける脆弱性ハンドリング要件であるANNEX I Part IIと、これを具体的なプロセスに落とし込むための整合規格候補であるEN 40000-1-3の関係を整理しました。
ANNEX I Part IIは、SBOMの作成、脆弱性への対処、定期的なテストとレビュー、CVDポリシーの策定、安全なアップデート配布など、製造者が継続的に運用すべき脆弱性ハンドリングの枠組みを定めています。一方、EN 40000-1-3を参照することで、これらの抽象的な要件を、準備、受付、検証、是正、リリース、リリース後対応といった具体的なフェーズに分解して整理できます。
弊社では、CRAへの対応を支援する「CRA対策支援サービス」を提供しております。
CRA対応に課題を感じている企業様や、具体的な対応方針の整理にお困りの企業様は、ぜひサービスの活用をご検討ください。→関連サービス紹介へ
また、弊社では脆弱性管理ツール「ONEKEY」も提供しております。
SBOMの作成・管理や脆弱性の検出に加え、自動脆弱性監視により、新たに公開された脆弱性の影響を継続的に把握できます。
CRAで求められる脆弱性ハンドリングの運用を効率化し、CRA対策支援サービスとあわせてご活用いただくことで、CRA対応をより効率的に進めることが可能です。→関連サービス紹介へ
参考資料
参考規格：BS EN 40000-1-3 Draft Cybersecurity requirements for products with digital elements. Part 1-3: Vulnerability Handling.
関連サービスのご紹介
CRA（欧州サイバーレジリエンス法）対策支援サービス
CRA対応を、検討段階から実務まで総合的に支援
CRAへの対応では、規格の理解だけでなく、設計・開発段階からのリスクアセスメント、脆弱性管理、SBOMの整備、インシデントや脆弱性の報告体制など、製品ライフサイクル全体を見据えた準備が求められます。セキュアイノベーションでは、CRAに関するトレーニングをはじめ、セキュア開発プロセスの構築、リスクアセスメント、サイバーセキュリティ試験、SBOM構築、PSIRT・CSIRTの体制構築まで幅広く支援しています。CRA対応をどこから進めるべきかお悩みの方は、ぜひご相談ください。
ONEKEYサービス
CRA対応に向けた製品の脆弱性管理を効率化
CRAへの対応では、製品開発時のセキュリティ対策だけでなく、製品ライフサイクルを通じてソフトウェアコンポーネントや脆弱性を継続的に把握・管理していくことが重要です。ONEKEYは、バイナリファームウェアをアップロードするだけで製品を自動解析し、SBOMの自動生成や脆弱性の検出、最新の脆弱性情報の継続的なモニタリングなどを行えるSaaSプラットフォームです。CRA対応に伴う脆弱性管理やSBOM管理の効率化を検討されている方は、ONEKEYのサービス内容をご覧ください。
最新のコラム記事
LOADING...
セキュアイノベーション サービス一覧
