.png)
要約
CRA（サイバーレジリエンス法）：EUで販売されるあらゆる「デジタル」製品（アプリ、ファームウェア、IoT、ソフトウェア）に対してセキュリティを義務付けます。
製品のライフサイクル全体にわたり、セキュリティ・バイ・デザイン、パッチ適用、SBOM、脆弱性開示が求められます。
2027年12月に開始。基準を満たさない場合、1,500万ユーロ以上の罰金または市場からの排除が予想されます。
EUサイバーレジリエンス法（CRA）スコアカード概要:
- 開発者の労力: 高い（製品ライフサイクル全体にわたるセキュリティの組み込みが必要：セキュアな設計、セキュアコーディング、厳格なテスト、脆弱性対応プロセスの実装、セキュアなアップデートの提供、SBOMの維持）。
- ツール費用: 中程度から高い（セキュアなSDLCツール、すなわちSAST/SCA/DAST、SBOM生成ツール、脆弱性管理プラットフォームが必要。セキュアなアップデートインフラストラクチャ（OTAプラットフォーム）も必要となる可能性あり）。
- 市場への影響: 非常に高い（EUで販売されるほぼすべてのハードウェア/ソフトウェア製品にとって必須であり、製品サイバーセキュリティの期待に対する新たなグローバルベースラインを設定します。）
- 柔軟性: 中程度（必須要件を定義していますが、製品のリスク分類に基づいて異なる適合性評価ルートを許可しています）。
- 監査の厳格度: 中から高（適合性評価が必要です。標準製品には自己評価、重要製品には第三者評価が必要です。市場監視当局が執行します）。
EUサイバーレジリエンス法（CRA）とは何ですか？
強力なEUサイバーレジリエンス法（CRA）は、欧州連合市場で提供される「デジタル要素を持つ製品」（PDEs）に対する調和されたサイバーセキュリティ要件を確立する規制です。これは、安全でないハードウェアおよびソフトウェア製品の広範な問題と、タイムリーなセキュリティアップデートの不足に対処することを目的としています。
強力なCRAは、他のデバイスやネットワークに直接的または間接的に接続できるほぼすべてのソフトウェアまたはハードウェア製品に広く適用されますが、一部例外があります（例：医療機器、航空、特定の法規制で既にカバーされている自動車、重要でないSaaSなど）。これには、消費者向けIoTデバイス、ネットワーク機器、産業用制御コンポーネント、オペレーティングシステム、モバイルアプリ、デスクトップソフトウェアなどが含まれます。
CRAの主要な柱：
- 必須のサイバーセキュリティ要件（別紙I）: 製造業者は、PDEがライフサイクル全体を通じて特定のセキュリティ目標を満たすことを保証する必要があります。これには以下が含まれます:
- 設計とデフォルトによるセキュリティ: 製品は、適切なレベルのサイバーセキュリティを確保するように設計、開発、製造されなければなりません。それらはセキュアなデフォルト設定で提供されなければなりません。
- 脆弱性管理：製造業者は、製品の予想される寿命期間または最低5年間、脆弱性を特定し修正するためのプロセスを持つ必要があり、「遅滞なく」無料でセキュリティアップデートを提供することを含みます。
- データ保護: 製品によって処理されるデータの機密性、完全性、および可用性を保護します。
- アクセス制御: 不正アクセスの防止。
- レジリエンス: インシデントに耐え、そこから回復する能力。
- 攻撃対象領域の最小化: 攻撃対象領域を制限し、インシデントの影響を軽減します。
- 経済事業者の義務：
- 製造業者: CRAコンプライアンスの確保において主要な責任を負います。これには、安全な設計、適合性評価、技術文書（SBOMを含む）、脆弱性対応、インシデント/脆弱性報告、アップデートと明確な指示の提供が含まれます。これはEU圏外に拠点を置く場合でも適用されます。
- 輸入業者/販売業者: 製品を市場に出す前に、製造業者のコンプライアンス（例: CEマーキング、文書）を検証する義務があります。
- 脆弱性の取り扱いと報告：製造業者は、脆弱性を効果的に処理するためのプロセスを確立し、積極的に悪用されている脆弱性を認識後24時間以内にENISA（欧州サイバーセキュリティ機関）に報告する必要があります。また、修正された脆弱性および利用可能なアップデートについてユーザーに通知しなければなりません。
- 適合性評価とCEマーキング: PDEは、CEマーキングを受け、EU市場に投入される前に、適合性評価プロセス（製品の重要度に応じて製造業者による自己評価から第三者認証まで）を経て、コンプライアンスを実証する必要があります。
- 市場監視: 各国の市場監視当局がCRAを施行し、不遵守を調査し、罰則を課すか、製品の回収/リコールを要求する権限を付与します。
強力なCRAは2024年後半に発効し、ほとんどの義務は36か月後（2027年12月頃）に適用可能となりますが、製造業者の報告義務はそれより早く（2026年9月頃）適用されます。
なぜそれが重要なのか
強力なCRAは、重大な影響を伴う画期的な法律です。
- 責任の移行: 製品セキュリティの責任を主にエンドユーザーに任せるのではなく、製造業者に明確に負わせます。
- ベースラインセキュリティの向上: EUで販売される広範なコネクテッド製品に対し、義務的な最低限のサイバーセキュリティ基準を確立します。
- Software Supply Chain Security: SBOMやライフサイクル全体にわたる脆弱性管理といった要件を通じて、サードパーティコンポーネントに起因する脆弱性に対処します。
- 消費者とビジネスを保護: 攻撃者によってエクスプロイトされる安全でない製品の数を減らすことを目指し、データ漏洩、金銭的損失、安全上のリスクからユーザーを保護します。
- Harmonizes Requirements: 製品サイバーセキュリティに対する断片化された各国のアプローチに代わり、EU全体で単一の規則を確立します。
- Global Impact: EU市場の規模を考慮すると、CRAは事実上グローバルスタンダードを設定し、ヨーロッパで製品を販売したい世界中のメーカーに影響を与えます。
- 他の規制を補完: NIS2（重要サービスの保護）、GDPR（個人データの保護）、DORA（金融レジリエンス）と連携し、より包括的なEUサイバーセキュリティ環境を構築します。
ソフトウェアおよびコネクテッドハードウェアの製造業者にとって、CRAコンプライアンスはEU市場へのアクセスにおける基本的な要件となります。
何を、どのように実装するか (技術的側面とポリシー側面)
CRAの実装には、製品ライフサイクル全体を通じてその必須要件（附属書I）を統合することが求められます。
- セキュアな設計と開発（セキュリティバイデザイン）：
- 脅威モデリング: 潜在的な脅威を特定し、最初からセキュリティ制御を設計します。
- Secure Coding Practices: 開発者をトレーニングし、セキュアコーディング標準（例：OWASP ASVS、CERTコーディング標準）を適用します。SASTツールを使用します。
- 攻撃対象領域の最小化: 機能、オープンポート、および特権を必要最小限に制限します。
- セキュアなデフォルト: 製品がセキュアな設定（例：デフォルトパスワードなし、不要なサービス無効化）で出荷されることを確認します。セキュアなリセット機能を実装します。
- データ保護: 必要に応じて、保存データおよび転送中のデータに暗号化を実装します。データの完全性を保護します。
- アクセス制御: 堅牢な認証および認可メカニズムを実装します。
- 脆弱性管理:
- コンポーネント分析（SBOM）: すべてのコンポーネント（オープンソースライブラリを含む）を特定する正確なソフトウェア部品表（SBOM）を生成および維持します。SCAツールを使用して、依存関係における既知の脆弱性を検出します。
- Security Testing: 開発中およびリリース後全体で、定期的な脆弱性スキャン（SAST、DAST、SCA、IaC）、ファズテスト、およびペネトレーションテストを実装します。
- 脆弱性処理プロセス：脆弱性報告（内部／外部）の受け付け、分析、パッチの開発、および「遅滞なく」アップデートを配布するための明確な手順を確立します。
- パッチ適用/更新：製品の予想されるライフサイクル（最低5年間）の間、セキュリティアップデートを無償で提供します。安全な更新メカニズム（例：整合性チェック付きの安全なOTA更新）を実装してください。
- 透明性とドキュメント：
- 技術文書: 必須要件への準拠を示す詳細な技術文書を維持します。SBOMを含めます。
- ユーザー情報: ユーザーに対し、安全な利用方法、設定、アップデート、および製品のサポート期間について明確な指示を提供します。
- 脆弱性の開示：脆弱性報告を受け付けるためのポリシーと連絡窓口を確立し、修正された脆弱性を公開します。
- 適合性評価:
- リスク分類: 附属書IIIに基づき、製品がデフォルト、「重要」（クラスI）、または「クリティカル」（クラスII）のカテゴリに分類されるかを決定します。
- 評価手順: 必要な手順に従います（例：デフォルトの場合は内部統制/自己評価、重要/クリティカルなクラスの場合は第三者評価/認証）。
- 宣言とCEマーキング: 適合性が実証されたら、EU適合宣言書を作成し、CEマーキングを貼付します。
- 報告義務：
- 活発にエクスプロイトされている脆弱性: 認識後24時間以内にENISAに報告します。
- 重要なインシデント: 製品セキュリティに影響を与えるインシデントをENISAに報告します。
導入には、設計から保守に至るまで、エンジニアリング文化、プロセス、ツールにセキュリティを組み込むことが求められます。
避けるべきよくある間違い
CRAへの準備を進める製造業者は、以下の一般的な間違いを避けるべきです。
- 範囲の過小評価: CRAが複雑なIoTデバイスにのみ適用され、標準的なソフトウェアやデジタル要素を持つシンプルなハードウェアには適用されないと信じていること。その範囲は非常に広いです。
- 対応の遅延: 2027年の期限が迫るまで待ち、設計、開発、テスト、脆弱性管理、および更新プロセスに必要とされる大幅な変更を過小評価すること。
- セキュリティを後回しにすること: 設計段階からセキュリティを統合せず（「Security by Design」）、後から付け加えようとすること。これは効果が低く、よりコストがかかります。
- 不十分な脆弱性管理: 脆弱性を特定するための堅牢なプロセスやツール（SCA、SAST、DAST）が不足している、または必要なライフサイクルに対してタイムリーで無料のセキュリティアップデートを提供できないこと。
- SBOMの不正確さ／怠慢: 完全なSBOMを生成しなかったり、コンポーネントの変更に合わせて更新しなかったりすると、脆弱性管理が妨げられます。
- 安全な更新メカニズムの無視：更新を「遅延なく」提供するための信頼性のある安全な方法（堅牢なOTAプラットフォームなど）がないこと。手動更新では不十分である可能性が高いです。
- 不十分なドキュメント: 市場監視に必要な技術文書、SBOM、および適合性評価の証拠を維持できないこと。
- 開発のみに注力: 製品ライフサイクル全体における脆弱性対応とアップデートに関する、継続的な市場投入後の要件を無視しています。
評価者／当局が尋ねる可能性のあること（開発者向け）
適合性評価機関（重要製品の場合）または市場監視当局は、開発に影響を与えるCRA要件に関連する質問をする可能性があります:
- (Annex I) Secure Design: 「設計フェーズにおいてセキュリティはどのように考慮されましたか？脅威モデルやセキュリティアーキテクチャ文書を示すことはできますか？」
- (付属書I) 脆弱性管理: 「開発中にファーストパーティコードおよびサードパーティコンポーネント（SAST、SCA）の脆弱性を特定するために、どのようなツールとプロセスが使用されていますか？」
- (Annex I) Secure Coding: 「どのようなセキュアコーディング標準が遵守されていますか？コンプライアンスはどのように強制されていますか（例：リンター、コードレビュー、トレーニングなど）？」
- (付属書I) セキュリティテスト: 「リリース前に実施されたセキュリティテスト（例：ペネトレーションテスト、ファズテスト）の証拠を提示してください。」
- (Annex I) Secure Updates: 「セキュリティアップデートを配信するメカニズムについて説明してください。アップデートの完全性と真正性はどのように保証されていますか？」
- (第10条) SBOM: 「この製品バージョンのSoftware Bill of Materials (SBOM) を提供してください。」
- (第10条) 脆弱性対応: 「報告された脆弱性の取り扱いプロセスを、受付からパッチリリースまで説明してください。」
- (Annex I) Secure Default Config: 「製品は、初期設定でセキュアな構成をどのように保証していますか？」
彼らは、設計、開発、テスト、および保守の各フェーズからの証拠を要求します。これには、ドキュメント、ツールレポート、プロセス記述、場合によってはコードレビューへのアクセスが含まれます。
開発チームのためのクイックウィン
完全なCRAコンプライアンスには時間がかかりますが、開発チームは基礎を築き始めることができます。
- SBOM生成の実装: ビルドプロセスの一部として、SBOMを自動的に生成するツールを統合します。
- SCA & SASTの統合: ソフトウェアコンポジション分析と静的アプリケーションセキュリティテストがCI/CDパイプラインで確実に実行されるようにします。
- 基本的な脅威モデリングの採用：新機能や新製品の設計会議中に、潜在的な脅威について議論を開始します。
- デフォルト設定の見直し: 製品出荷前に、デフォルト設定を積極的に評価し、強化します。デフォルトの認証情報を削除します。
- 更新プロセスの文書化: ソフトウェアアップデートの構築とリリースに関する現在のプロセスを、たとえ最初は手動であっても明確に文書化します。
- 脆弱性受付の確立: 内部チームまたは外部研究者が潜在的な脆弱性を報告するための、シンプルで文書化された方法（例：専用のメールアドレスやフォーム）を作成します。
これを無視すると...（非準拠の結果）
CRAへの不遵守は、各国の市場監視当局によって課される重大な結果を招く可能性があります。
- Heavy Fines: 必須要件の不遵守に対する行政罰金は、最大で€1,500万または前会計年度における製造業者の全世界年間総売上高の2.5%のいずれか高い方まで達する可能性があります。軽微な違反の場合、罰金は最大€1,000万/2%または€500万/1%となります。
- 市場からの撤去/リコール: 当局は、不適合製品をEU市場から撤去するか、エンドユーザーからリコールするよう要求できます。
- 販売禁止/制限: 適合しない製品を市場に出すことは、禁止または制限される可能性があります。
- 評判の損害: コンプライアンス違反、リコール、または重大な脆弱性の公表は、ブランドの信頼と市場での認識を損ないます。
- 市場アクセス権の喪失: CRA要件を満たさない場合、対象製品はEU単一市場全体へのアクセスが事実上ブロックされます。
よくあるご質問
CRAの対象となる製品は何ですか？
「デジタル要素を持つ製品」（PDEs）とは、その意図された、または合理的に予見可能な使用が、デバイスまたはネットワークへの直接的または間接的な論理的または物理的なデータ接続を含むものです。これには、ほとんどのソフトウェア（スタンドアロン、モバイル、組み込み）と、接続性を持つハードウェア（IoTデバイス、ルーター、スマート家電、産業用コンポーネントなど）が含まれます。特定の除外事項（例：医療機器、自動車、航空、特定のSaaS）があります。
CRA要件はいつ義務化されますか？
適合性評価や必須要件を含むほとんどの義務は、CRA発効後36ヶ月（2027年12月頃）に適用されます。ただし、積極的にエクスプロイトされた脆弱性やインシデントに関する製造業者の報告義務は、発効後21ヶ月（2026年9月頃）に前倒しで適用されます。
CRAはフリーおよびオープンソースソフトウェア (FOSS) に適用されますか？
商業活動の範囲外で開発または提供されるスタンドアロンのFOSSは、一般的に除外されます。しかし、商業製品に組み込まれたFOSSは対象となり、最終製品の製造業者が責任を負います。正式な組織（例：財団）を持ち、サポートやバージョンを収益化しているFOSSプロジェクトも、CRAの義務の一部に該当する可能性があります（詳細についてはまだ議論中です）。
CRAの文脈におけるCEマーキングとは何ですか？
他のEU製品規制と同様に、製造業者は、PDEをEU市場に投入する前に、CRAの基本要件を満たしていることを示すために、準拠したPDEにCEマーキングを貼付する必要があります。これには、適合性評価の成功が求められます。
SBOMとは何ですか、またなぜ必要ですか？
ソフトウェア部品表（SBOM）は、ソフトウェア構築に使用されるさまざまなコンポーネントの詳細とサプライチェーン関係を含む正式な記録です。CRAは、サプライチェーン全体の透明性を向上させ、脆弱性管理を促進するために、製造業者に対し製品のSBOMを生成および維持することを義務付けています。
CRAに基づき、製造業者はどのくらいの期間セキュリティアップデートを提供する必要がありますか？
製造業者は、製品の予想される寿命、または製品を市場に投入してから最低5年間のいずれか短い期間、セキュリティアップデートを提供しなければなりません。予想される寿命は設計時に考慮する必要があります。アップデートは無料で、迅速に（「遅滞なく」）提供されなければなりません。
CRAはNIS2やGDPRとどのように関連していますか？
- NIS2: 必須/重要なサービスプロバイダーが使用するネットワークとシステムのセキュリティに焦点を当てています。CRAは、それらのプロバイダーまたは消費者が使用する可能性のある製品自体のセキュリティに焦点を当てています。
GDPR: 個人データの保護に焦点を当てています。CRAは製品のサイバーセキュリティに焦点を当てています。CRAに基づくセキュアな製品は、それが処理する個人データを保護するのに役立ち（GDPRをサポート）、CRAの範囲は個人データに限定されません。これらはEUのデジタルセキュリティ戦略の補完的な部分です。
