TL;DR

CRA（サイバー・レジリエンス法）は、EUで販売されるアプリ、ファームウェア、IoT、ソフトウェアなど、「デジタル」なものすべてにセキュリティを義務付けるものだ。

製品のライフサイクル全体にわたって、セ キュリティ・バイ・デザイン、パッチ適用、SBOM、 脆弱性の開示が必要である。

2027年12月スタート。マークを外した場合1,500万ユーロ以上の罰金か市場追放が予想される。

EUサイバーレジリエンス法（CRA）スコアカード概要：

• 開発者の労力：高い（製品のライフサイクル全体を通じてセキュリティを組み込むことが必要：安全な設計、安全なコーディング、厳格なテスト、脆弱性対応プロセスの実装、安全な更新プログラムの提供、SBOM の維持）。
• ツールコスト：中程度から高い（安全な SDLC ツール - SAST/SCA/DAST、SBOM 生成ツール、脆弱性管理プラットフォーム、潜在的に安全な更新インフラ - OTA プラットフォームを必要とする）。
• 市場への影響：非常に高い（EU域内で販売されるほぼすべてのハードウェア／ソフトウェア製品に義務付けられ、製品に期待されるサイバーセキュリティの新たな世界的基準となる）。
• 柔軟性：中程度（必須要件を定義しているが、製品リスク分類に基づく様々な適合性評価ルートを認めている）。
• 監査の強度：中～高（適合性評価が必要-標準的な製品については自己評価、重要な製品については第三者評価。）

EUサイバーレジリエンス法（CRA）とは？

EUサイバーレジリエンス法（CRA）は、欧州連合（EU）市場で販売される「デジタル要素を持つ製品」（PDEs）に対する調和のとれたサイバーセキュリティ要件を定める規則である。これは、安全でないハードウェアやソフトウェア製品、タイムリーなセキュリティアップデートの欠如という広範な問題に取り組むことを目的としている。

CRAは、他のデバイスやネットワークに直接または間接的に接続できるほぼすべてのソフトウェアまたはハードウェア製品に広く適用されますが、一部例外があります（医療機器、航空、特定の法律ですでにカバーされている自動車、重要でない限りSaaSなど）。これには、消費者向けIoTデバイス、ネットワーク機器、産業用制御コンポーネント、オペレーティングシステム、モバイルアプリ、デスクトップソフトウェアなどが含まれる。

CRAの主要な柱：

1. 必須サイバーセキュリティ要件（付属書 I）： 製造者は、PDE がそのライフサイクルを通じて特定のセキュリティ目標を満たすことを保証しなければならない。その対象は以下の通りである：
   
   • デザインとデフォルトによるセキュリティ：製品は、適切なレベルのサイバーセキュリティを確保するように設計、開発、製造されなければならない。製品は、安全なデフォルト設定で提供されなければならない。
   • 脆弱性管理：製造者は、製品の期待耐用年数または最低5年間を通じて、脆弱性を特定し、是正するプロセスを持たなければならない。これには、セキュリティ更新プログラムを「遅滞なく」無償で提供することも含まれる。
   • データ保護：製品によって処理されるデータの機密性、完全性、可用性の保護。
   • アクセス・コントロール：不正アクセスの防止。
   • 回復力：インシデントに耐え、そこから回復する能力。
   • アタックサーフェスの最小化攻撃対象領域を限定し、インシデントの影響を軽減する。
2. 経済事業者の義務：
   
   • 製造者：安全な設計、適合性評価、技術文書化（SBOMを含む）、脆弱性対応、インシデント／脆弱性報告、アップデートの提供、明確な指示など、CRAへの準拠を確保するための第一義的な責任を負うこと。これは、EU域外に拠点を置く場合にも適用される。
   • 輸入業者／販売業者製品を上市する前に、製造者のコンプライアンス（CEマーキング、文書化など）を確認する義務がある。
3. 脆弱性の取り扱いと報告：製造業者は、脆弱性を効果的に処理するプロセスを確立し、積極的に悪用された脆弱性を認知後24時間以内にENISA（EUサイバーセキュリティ機関）に報告しなければならない。また、修正された脆弱性と利用可能なアップデートについてユーザーに通知しなければならない。
4. 適合性評価とCEマーキング：PDEは、CEマーキングを受けてEU市場に出荷される前に、適合性を証明するために適合性評価プロセス（製品の重要性に応じて、メーカーの自己評価から第三者認証まで）を受けなければならない。
5. 市場監視：CRAを実施し、コンプライアンス違反を調査し、罰則を課したり、製品の撤去／回収を要求したりするために、各国の市場監視当局を指定する。

CRAは2024年後半に発効し、ほとんどの義務は36ヵ月後（2027年12月頃）に適用されるが、製造業者の報告義務はそれ以前（2026年9月頃）に適用される。

なぜ重要なのか？

CRAは重要な意味を持つ画期的な法律である：

• 責任の転換：製品セキュリティの責任は、エンドユーザーに委ねるのではなく、メーカーにある。
• ベースライン・セキュリティの向上EUで販売される膨大な種類のコネクテッド製品に対し、サイバーセキュリティの最低基準を義務付ける。
• ソフトウェア・サプライチェーンのセキュリティ：SBOMのような要求事項やライフサイクルにわたる脆弱性管理を通じて、サードパーティコンポーネントに起因する脆弱性に対処する。
• 消費者と企業を守る：攻撃者に悪用される安全でない製品の数を減らし、データ漏洩、金銭的損失、安全上のリスクからユーザーを守ることを目指す。
• 要件の調和：製品のサイバーセキュリティに対する各国の断片的なアプローチに代わって、EU全体で単一の規則を策定する。
• グローバルな影響：EUの市場規模を考えると、CRAは事実上グローバルスタンダードを設定し、欧州での製品販売を希望する世界中のメーカーに影響を与える。
• 他の規制の補完NIS2（重要なサービスの安全確保）、GDPR（個人データの保護）、DORA（金融レジリエンス）と連携し、より包括的なEUのサイバーセキュリティ環境を構築する。

ソフトウェアや接続されたハードウェアの製造業者にとって、CRAへの準拠はEUでの市場参入のための基本的な要件となるだろう。

何をどのように実施するか（技術・政策）

CRAを実施するには、その必須要件（付属書I）を製品ライフサイクル全体を通じて統合する必要がある：

1. セキュアな設計と開発（セキュリティ・バイ・デザイン）：
   
   • 脅威モデリング：潜在的な脅威を特定し、当初からセキュリティ対策を設計する。
   • 安全なコーディングの実践：開発者を訓練し、安全なコーディング標準（例えば、OWASP ASVS、CERT コー ディング標準）を実施する。SAST ツールを使用する。
   • 攻撃対象領域を最小化する：機能、オープンポート、権限を必要最小限に制限する。
   • 安全なデフォルト設定：製品が安全な設定で出荷されるようにする（デフォルトのパスワードがない、不要なサービスが無効になっているなど）。安全なリセット機能を実装する。
   • データ保護：必要に応じて、静止時および転送時のデータの暗号化を実施する。データの完全性を保護する。
   • アクセス制御：強固な認証と承認の仕組みを導入する。
2. 脆弱性管理：
   
   • コンポーネント分析（SBOM）：すべてのコンポーネント（オープンソースライブラリを含む）を特定する正確なソフトウェア部品表（SBOM）を作成し、維持する。SCA ツールを使用して、依存関係の既知の脆弱性を見つける。
   • セキュリティテスト：開発からリリース後まで、定期的な脆弱性スキャン（SAST、DAST、SCA、IaC）、ファズテスト、侵入テストを実施する。
   • 脆弱性対応プロセス：脆弱性の報告（内部／外部）を受け、それを分析し、パッチを開発し、アップデートを "遅滞なく "配布するための明確な手順を確立する。
   • パッチ／アップデート：製品の期待ライフサイクル（最低5年間）にわたり、セキュ リティアップデートを無償で提供する。安全なアップデートの仕組みを導入する（完全性チェックを伴う安全な OTA アップデートなど）。
3. 透明性と文書化：
   
   • 技術文書：必須要件への適合を示す詳細な技術文書を維持すること。SBOMを含む。
   • ユーザー情報：安全な使用、設定、更新、製品のサポート期間について、ユーザーに明確な指示を与える。
   • 脆弱性の公表：脆弱性の報告を受けるための方針と窓口を確立し、修正された脆弱性を公表する。
4. 適合性評価：
   
   • リスク分類：附属書Ⅲに基づき、製品がデフォルト、「重要」（クラスⅠ）、「重要」（クラスⅡ）のいずれに該当するかを決定する。
   • 評価手順：必要な手順（例えば、デフォルトの場合は内部統制／自己評価、重要／クリティカルクラスの場合は第三者評価／認証）に従う。
   • 適合宣言書とCEマーキングEU適合宣言書を作成し、適合が証明されたらCEマーキングを貼付する。
5. 報告義務：
   
   • 積極的に悪用される脆弱性：認知後24時間以内にENISAに報告すること。
   • 重大なインシデント製品のセキュリティに影響を及ぼすインシデントをENISAに報告する。

実装では、設計から保守に至るまで、エンジニアリング文化、プロセス、ツールにセキュリティを組み込むことが求められる。

避けるべき一般的な間違い

CRAに備えるメーカーは、これらのよくある間違いを避けるべきである：

1. 適用範囲の過小評価：CRAは複雑なIoTデバイスにのみ適用され、標準的なソフトウェアやデジタル要素を持つより単純なハードウェアには適用されないと考えている。適用範囲は非常に広い。
2. 行動の遅延：2027年の期限近くまで待ち、設計、開発、テスト、脆弱性管理、更新プロセスに必要な大幅な変更を過小評価する。
3. セキュリティを後回しにすること：設計段階からセキュリティを統合することを怠り（「セキュリティ・バイ・デザイン」）、後からセキュリティを追加しようとする。
4. 脆弱性管理の不備：脆弱性を特定するための強固なプロセスやツール（SCA、SAST、DAST）が欠如している、あるいは、必要なライフサイクルにおいてタイムリーかつ無償のセキュリティ更新プログラムを提供できていない。
5. SBOMの不正確さ/怠慢：完全なSBOMを生成しなかったり、コンポーネントの変更に応じてSBOMを更新しなかったりすることで、脆弱性管理の妨げとなる。
6. 安全なアップデートメカニズムの無視：アップデートを "遅滞なく "配信する信頼できる安全な方法（堅牢なOTAプラットフォームなど）を持っていない。手動アップデートでは十分でない可能性が高い。
7. 不十分な文書：市場サーベイランスに必要な技術文書、SBOM、適合性評価証拠を保持しないこと。
8. 開発だけに集中すること：製品ライフサイクルを通じた脆弱性ハンドリングとアップデートに関する市販後の継続的な要件を軽視。

評価者／当局が尋ねそうなこと（デベロッパー・フォーカス）

適合性評価機関（重要製品の場合）や市場監視当局は、開発に影響を与えるCRA要件に関連した質問をするかもしれない：

• (付属文書I）安全な設計「設計段階でセキュリティはどのように考慮されましたか？脅威モデルやセキュリティ・アーキテクチャー文書を示せますか？"
• (附属書 I）脆弱性管理："開発中にファーストパーティーのコードやサードパーティーのコンポーネント（SAST、SCA）の脆弱性を特定するために、どのようなツールやプロセスを使用していますか？"
• (附属書Ⅰ）安全なコーディング：「どのようなセキュアコーディング標準に従っているか？コンプライアンスはどのように実施されているか（リンター、コードレビュー、トレーニングなど）"
• (付属文書 I）セキュリティテスト「リリース前に実施したセキュリティテスト（侵入テスト、ファズテストなど）の証拠を示す。
• (付属文書 I）セキュアアップデート「セキュリティ更新を配信する仕組みについて記述すること。アップデートの完全性と真正性はどのように確保されているか。"
• (Art. 10) SBOM:"この製品バージョンのソフトウェア部品表(SBOM)を提供すること"。
• (第10条）脆弱性の取り扱い："報告された脆弱性の取り扱いについて、取り込みからパッチリリースまでのプロセスを記述する。"
• (附属書I）セキュアなデフォルト設定："その製品は、出荷時に安全なコンフィグレーションをどのように確保しているか？"

設計、開発、テスト、メンテナンスの各段階における証拠（文書、ツールレポート、プロセス記述、コードレビューへのアクセスなど）が要求される。

開発チームのクイックウィン

CRAに完全に準拠するには時間がかかるが、開発チームは基礎固めを始めることができる：

1. SBOM生成の実装：ビルドプロセスの一部としてSBOMを自動的に生成するツールを統合する。
2. SCAとSASTの統合：ソフトウェア構成分析と静的アプリケーション・セキュリティ・テストがCI/CDパイプラインで確実に実行されるようにする。
3. 基本的な脅威モデリングを採用する：新機能や新製品の設計会議において、潜在的な脅威について議論を開始する。
4. デフォルト設定の見直し：出荷前の製品のデフォルト設定を積極的に評価し、強化する。デフォルトの認証情報を削除する。
5. アップデートプロセスの文書化：ソフトウェアのアップデートを構築し、リリースするための現在のプロセスを、最初は手動であっても、明確に文書化する。
6. 脆弱性インテークを確立する：社内のチームや外部の研究者が潜在的な脆弱性を報告するための、シンプルで文書化された方法（専用の電子メールアドレスやフォームなど）を作成する。

これを無視すれば...（コンプライアンス違反の結果）

CRAへの不遵守は、各国の市場監視当局によって厳しい結果を招きかねない：

• 重い罰金行政罰は、必須要件に違反した場合、最高1,500万ユーロ、または前会計年度の製造業者の全世界における年間総売上高の2.5％のいずれか高い方に達する可能性がある。それ以下の違反の場合、最高1,000万ユーロ/2％または500万ユーロ/1％の罰金が科される。
• 市場撤去／回収：当局は、非準拠製品のEU市場からの撤退、またはエンドユーザーからの回収を要求できる。
• 販売禁止／制限：非準拠の製品を市場に出すことを禁止または制限することができる。
• 風評被害：コンプライアンス違反、リコール、重大な脆弱性の公表は、ブランドの信頼と市場の認識を損なう。
• 市場アクセスの喪失：CRAの要件を満たさない場合、対象製品のEU単一市場全体へのアクセスが事実上遮断される。

よくあるご質問

CRAの対象となる製品は？

意図的または合理的に予見可能な使用が、デバイスまたはネットワークへの直接的または間接的な論理的または物理的データ接続を含む「デジタル要素を含む製品」（PDE）。これには、ほとんどのソフトウェア（スタンドアロン、モバイル、組み込み）および接続機能を持つハードウェア（IoTデバイス、ルーター、スマート家電、産業用コンポーネントなど）が含まれる。特定の除外項目もある（医療機器、自動車、航空、特定のSaaSなど）。

CRAの要件はいつから義務化されるのか？

適合性評価や必須要件を含むほとんどの義務は、CRA発効から36ヶ月後（2027年12月頃）に適用される。ただし、積極的に悪用された脆弱性やインシデントに関する製造者の報告義務は、発効から21ヵ月後（2026年9月頃）と、より早い時期に適用される。

CRAはフリー・オープンソース・ソフトウェア（FOSS）にも適用されるのか？

商業活動外で開発または提供されたスタンドアロンFOSSは一般的に除外されます。しかし、商業製品に統合されたFOSSは対象となり、最終製品の製造者は責任を負います。サポートやバージョンを収益化する正式な構造（例えば財団）を持つFOSSプロジェクトも、CRAの義務の一部に該当するかもしれません（具体的な内容はまだ議論中です）。

CRAにおけるCEマーキングとは？

他のEU製品規制と同様、製造者は適合PDEにCEマークを貼付し、CRAの必須要件を満たしていることを示した上で、EU市場に投入しなければならない。そのためには、適合性評価に合格する必要がある。

SBOMとは何か、なぜ必要なのか？

ソフトウェア部品表（SBOM）は、ソフトウェアを構築する際に使用される様々なコンポーネントの詳細とサプライチェーン上の関係を含む正式な記録である。CRAは、透明性を向上させ、サプライチェーン全体の脆弱性管理を促進するため、製造業者に対し、製品のSBOMを作成し、維持することを要求している。

CRAでは、メーカーはどれくらいの期間、セキュリティ・アップデートを提供しなければならないのですか？

製造者は、製品の予想耐用年数、または製品を市場に出してから最低5年間のいずれか短い期間、セキュリティ・アップデートを提供しなければならない。予想される耐用年数については、設計時に考慮する必要がある。アップデートは無償で適時に（「遅延なく」）提供されなければならない。

CRAとNIS2やGDPRとの関係は？

• NIS2：不可欠／重要なサービス・プロバイダーが使用するネットワークとシステムのセキュリティに重点を置く。CRAは、これらのプロバイダーや消費者が使用する可能性のある製品自体のセキュリティに重点を置く。

GDPR： 個人データ保護に注力。CRAは製品のサイバーセキュリティに重点を置く。CRAに基づく安全な製品は、それによって処理される個人データの保護に役立つ（GDPRをサポート）が、CRAの範囲は個人データよりも広い。両者はEUのデジタル・セキュリティ戦略の補完的な部分である。