EUサイバーレジリエンス法：概要、要件、およびスケジュール

EUサイバーレジリエンス法（CRA）は、高まるサイバー攻撃の脅威に直面してEUの基本的価値観を保護するために、2018年12月10 2024に正式に導入されました。デジタル要素を含む製品を標的としたサイバー攻撃が頻繁かつ高額化するにつれ、この規制は欧州で販売されるすべてのハードウェアおよびソフトウェア製品を対象とした、初の包括的なサイバーセキュリティ基準を確立するものである。Omdiaの2026ソフトウェアサプライチェーンセキュリティレポートによると、 77 %の組織が過去1年間にサプライチェーンインシデントを経験したと報告しており、緊急性は現実のものとなっている。

この規制は12月11 、 2027に完全に施行されますが、脆弱性報告義務は9月11 、 2026に施行されます。コンテナ化されたソフトウェアを開発・出荷するチームにとって、CRA（コンテナ規制法）は、SBOM（ソフトウェア部品表）の生成、脆弱性の開示、イメージの強化といった行為を、自主的なベストプラクティスから法的要件へと変更する。

このガイドでは、EU CRAが要求する内容、適用対象者、SBOM義務がコンテナ構築ワークフローとどのように関連しているか、そしてコンプライアンス期限までにチームが行うべきことについて説明します。

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

CRA（サイバーセキュリティ規制法）が施行される以前、EUにはデジタル要素を含む製品のサイバーセキュリティ基準を定める、分野横断的な統一規制が存在しなかった。スマートサーモスタット、エンタープライズデータベース、コンテナランタイムは、それぞれ異なる（あるいは全くない）サイバーセキュリティ義務の対象となっていた。EU市場で発売されたデジタル要素を含む製品については、脆弱性を修正したり、セキュリティインシデントを開示したり、ソフトウェアを文書化したりする一般的な義務はなかった。CRAは、複数の業界に適用される横断的な規制によってそのギャップを埋め、製造業者に主な負担を課している。

この規制では、デジタル要素を含む製品とは、ソフトウェアまたはハードウェア製品全般を指し、これにはリモートデータ処理ソリューションや、個別に市場に出回るあらゆる構成要素が含まれると定義されている。その範囲は意図的に広く設定されており、消費者向けIoTデバイスから企業向けソフトウェアプラットフォーム、レジストリを通じて配布されるコンテナイメージまで、あらゆるものを網羅している。製造業者は、製品を安全に設計し、製品ライフサイクル全体を通して脆弱性に対処し、ソフトウェアの構成に関する透明性を提供しなければならない。

CRAとNISの関係2

CRAは、NIS 2やDORAなどの他の規制枠組みを含む、より広範なEUサイバーセキュリティ戦略の一部です。CRAとNIS 2はどちらもサイバーセキュリティの義務を扱っているため混同されやすいが、対象は異なる。CRAはデジタル要素を含む製品のサイバーセキュリティに適用され、 NIS 2は重要かつ不可欠な組織のサイバーセキュリティに適用されます。

CRAの前文12では、SaaS、PaaS、またはIaaSソリューションがNIS 2の対象となることを断言しており、原則としてそれらをその適用範囲から除外しています。しかし、クラウドインフラに依存する製品に関しては、その境界線は曖昧である。

欧州委員会の3月2026ガイダンス草案では、クラウドコンポーネントがCRAの対象となるかどうかを判断するための3つのテストが導入されました。

1. 処理はリモートで行われますか？
2. それがなければ、製品の重要な機能が失われてしまうだろうか？
3. 製造元は、その遠隔部品を設計、開発、または管理する責任を負っているのでしょうか？

上記3つの質問すべてに「はい」と答えた場合、クラウドコンポーネントはCRA（カナダ歳入庁）の目的においては製品の一部とみなされます。そのテストでクラウドコンポーネントが対象範囲に含まれ、そのコンポーネントが個人データを処理する場合、GDPRはCRAに取って代わるのではなく、CRAの上に適用されるため、管理者と処理者の役割を割り当て、法的根拠を確認する必要があります。

CRAの適用対象者

カナダ歳入庁（CRA）は、製品を市場に投入する際のあなたの役割に基づいて義務を割り当てます。

EU CRAの主要要件

CRAは、その要件を2つの主要な分野に分類しており、どちらも規則の付属書Iで定義されている。すなわち、製品特性に関する必須のサイバーセキュリティ要件と、製品ライフサイクルにおける脆弱性処理義務である。

設計段階からのセキュリティ

製品は、リスク評価に基づき、適切なレベルのサイバーセキュリティを確保するように設計、開発、製造されなければならない。実際には、これは安全なデフォルト設定で出荷すること、不要なコンポーネントを削除して攻撃対象領域を最小限に抑えること、保存および送信されるデータの機密性と完全性を保護すること、そして安全なアップデートのためのメカニズムを提供することを意味します。

コンテナイメージの場合、設計段階からのセキュリティ要件は、イメージの強化に直接対応します。

• 最小限のベースレイヤー
• 不要なシェルやパッケージマネージャーは使用しない。
• 初期設定でセキュリティが確保されています。

必須要件には、データ最小化も含まれます。製品は、その意図された目的に必要な範囲で、適切かつ関連性のある個人データまたはその他のデータのみを処理する必要があります。

脆弱性への対応

製造業者は、各製品について定めたサポート期間を通じて、脆弱性を特定、文書化、および修復するためのプロセスを維持しなければならない。これには、連携した脆弱性開示ポリシー、タイムリーなセキュリティアップデート、およびユーザーが影響を評価し、対策を講じるのに十分な詳細情報を含む、修正済み脆弱性の公開が含まれます。

セキュリティアップデートは、サポート期間中は無償で提供されなければならない。公開情報は、利用者が必要とする技術的な詳細に限定されるべきであり、報告者や影響を受ける利用者の身元などの個人データを開示してはならない。これは、情報公開によってリスクが増大することを避けるというカナダ歳入庁（CRA）の期待、および個人データの公開に関するGDPRの制限に合致するものである。

透明性とSBOM

CRAはまた、製造業者に対し、デジタル要素を含むすべての製品の技術文書にソフトウェア部品表を含めることを義務付けている。SBOMは、一般的に使用されている機械可読形式でなければならず、少なくとも製品の最上位依存関係を含んでいなければなりません。ただし、この規制では特定のフォーマットは義務付けられていないが、実際には通常、SPDXまたはCycloneDXを意味する。生成されるSBOMの範囲をパッケージと依存関係のメタデータに限定し、埋め込まれた機密情報や個人データは成果物から除外します。

重要なニュアンス：CRAは、製造業者にSBOM（部品表）を公表することを義務付けていません。SBOM（部品表）は技術文書に含め、市場監視当局からの要請に応じて提供しなければならない。また、当該文書は、製品が市場に投入されてから10年間、またはサポート期間のいずれか長い方の期間、保管しなければなりません。

インシデントおよび脆弱性の報告

製造業者は、実際に悪用された脆弱性および重大なセキュリティインシデントを、関連する国のコンピュータセキュリティインシデント対応チーム（CSIRT）およびENISAに、単一の報告プラットフォームを通じて報告しなければならない。報告期限は以下のとおりです。

プライバシーに関する注意：これらの報告書には、報告者の身元や影響を受けたユーザーの詳細などの個人データが含まれる可能性があるため、各報告書はCSIRTとENISAが実際に必要とする技術情報に限定し、個人データはGDPRに準拠して取り扱ってください。通知では、ユーザーへのリスクを高めるような情報の開示は避けるべきである。

適合性評価

製品をEU市場に投入する前に、製造業者は、必須のサイバーセキュリティ要件への準拠を確認するための適合性評価を完了しなければならない。評価の種類は、製品がカナダ歳入庁（CRA）の下でどのように分類されるかによって異なります。

製品カテゴリーと適合性評価

CRAは、サイバーセキュリティリスクに基づいて製品を3つのティアに分類しており、各ティアはより厳格な適合性評価手続きの対象となる。

コンテナランタイムを出荷している場合、おそらく重要クラスIIのカテゴリに該当し、第三者機関による評価が必要になります。適合性評価に合格した製品にはCEマークが付与され、これはCRA（欧州共同体規制）への適合性を示し、EU市場での販売を可能にする。不具合が見つかった製品、または販売後に規格違反が判明した製品は、各国の市場監視当局によって回収またはリコールを命じられる可能性がある。

CRAタイムライン： 3重要な期限

CRAは12月10 、 2024に発効したが、その義務は3年かけて段階的に導入される。各マイルストーンには、それぞれ異なる一連の要件が設けられています。

多くのチームが見落としている重要な点：9月の2026報告義務は、既に市場に出回っている製品にも適用される。この規制は、新製品だけでなく、既にEU市場に出回っている製品にも遡及的に適用される。現在、EUの顧客にコンテナイメージを販売している場合、 24時間ごとの報告期限は数ヶ月単位で始まり、数年単位ではありません。

不遵守に対する罰則

CRA第64条は、不遵守に対する3段階の罰則を定めており、罰金は加盟国レベルで設定されるが、規則によって上限が定められている。

• 必須のサイバーセキュリティ要件およびその他のコア義務（第 1 条）を遵守しなかった場合、最大15百万ユーロまたは世界年間売上高の2 . 5 %（いずれか高い方）の罰金が科せられます。64 ( 2 )) 
• 最大10百万ユーロまたは世界年間売上高の2 ％ （いずれか高い方）またはその他のCRA義務の不履行（第1条）64 ( 3 ))
• 当局に不正確、不完全、または誤解を招く情報を提供した場合、最大5百万ユーロまたは世界年間売上高の1 ％ （いずれか高い方）の罰金が科せられます（第1条）。64 ( 4 ))

罰金以外にも、市場監視当局は製品の回収、リコール、あるいはEU市場からの全面的な販売禁止を命じることができる。EUにソフトウェア製品を販売する企業にとって、市場アクセスを失うことは、罰金そのものよりも深刻な結果を招くことが多い。

オープンソースソフトウェアとCRA

カナダ歳入庁（CRA）によるオープンソースの扱いは、立法過程において最も議論を呼んだ点の1つだった。最終稿では、商業活動に基づいて明確な線引きがなされている。

直接的またはサポートを通じて商業活動に使用されていないフリーソフトウェアおよびオープンソースソフトウェアは、カナダ歳入庁（CRA）の管轄外です。個人開発者やボランティアの保守担当者は、商業活動を行っていない限り、規制上は製造業者とはみなされない。また、CRAは、商業活動の範囲外で配布するために提供されるオープンソースソフトウェアには明示的に適用されない。

しかし、この規制は新たな役割、すなわちオープンソースソフトウェアスチュワードを導入する。 

「スチュワード」とは、商業活動を目的としたオープンソースソフトウェアの開発を体系的に支援する法人（個人ではなく、企業または財団）のことである。カナダ歳入庁（CRA）は、義務が限定された審判員に対して、緩やかな規制制度を適用している。彼らは主に以下のことを行う必要がある：

1. サイバーセキュリティポリシーを維持する。
2. 実際に悪用された脆弱性を報告する。
3. 市場監視当局に協力する。 

重要な点として、審判員はカナダ歳入庁（CRA）の規定違反に対して金銭的な罰則を受けることはありません。

有料サポートや商用コンテナイメージレジストリなどを通じて、商用モデルでオープンソースソフトウェアを配布する組織は、管理者ではなく製造業者として分類される。この区別が重要なのは、製造業者が適合性評価やCEマーキングを含むCRA（消費者規制当局）の義務を全面的に負うからである。

CRAがコンテナチームに意味すること

上記すべては、デジタル製品全般に当てはまります。ここからが具体的な話になります。EU域内で商業的に流通されるコンテナイメージおよびランタイムは、CRA（消費者権利法）の下でデジタル要素を含む製品として分類されます。貴社がEUの顧客が利用できるレジストリにコンテナイメージを公開しており、それらのイメージが商用製品の一部である場合、CRA（コンテナ再編法）が適用され、貴社は製造業者とみなされる可能性があります。これは、組織の本社所在地に関係なく当てはまります。

実務上の影響は、コンテナのライフサイクル全体に及ぶ。

• 画像構成の透明性：すべての画像には、少なくとも最上位レベルの依存関係を文書化した、機械可読なSBOMが必要です。ビルド時に生成されるイメージレイヤーSBOMは、OSパッケージ、ランタイムライブラリ、推移的依存関係を網羅しており、CRAの最低限の要件を超えています。
• 脆弱性管理：組織は、自社のイメージに含まれるコンポーネントの脆弱性を追跡、修復、報告するためのプロセスを確立する必要があります。2026年9月より、 14条に記載されているすべての脆弱性およびインシデント報告義務が発効します。
• 設計段階からのセキュリティ：イメージは、攻撃対象領域を最小限に抑え、安全なデフォルト設定を行い、不要なコンポーネントを含まないように出荷されるべきである。シェル、パッケージマネージャ、デバッグツールなどが削除された強化版ベースイメージは、標準的なコミュニティイメージよりもこの要件をより直接的に満たします。
• 出所と完全性： CRAの必須要件には、製品の完全性を保護し、構成部品が改ざんされていないことを検証することが含まれます。暗号署名と出所証明は、この問題に直接対処するものです。
• サポート期間：製造業者は、脆弱性に対応するサポート期間を定義し、周知しなければならない。コンテナイメージの場合、これは、サポートされている各イメージタグのライフサイクル全体にわたって、パッチ適用と再構築のサイクルを遵守することを意味します。

コンプライアンスはイメージレイヤーから始まります

CRAは、EUにソフトウェアを出荷するすべての組織にとっての基準を引き上げるものです。コンテナチームにとって、これらの要件は、業界が進めている慣行、すなわち、強化されたイメージ、ビルド時のSBOM、来歴証明、脆弱性監視、および明確に定義されたサポートライフサイクルに直接対応しています。違いは、これらの慣行がもはや選択肢ではなく義務になったという点だ。

ありがたいことに、 Docker Hardened Imagesには、CRA が要求する成果物、つまり完全な SBOM、改ざん不可能な証明付きの SLSA ビルド レベル3の来歴、OpenVEX の悪用可能性データ、および暗号署名が同梱されています。イメージはデフォルトでは最小限の構成で、アップストリームの修正に基づいて継続的に再構築され、定義されたサポート期間によって裏付けられています。これに、パッケージとコンポーネントのメタデータに限定され、個人データと埋め込まれた秘密情報を除くSBOMデータに対する継続的な脆弱性監視を組み合わせると、CRAの24時間報告クロックは、手動トリアージではなく、既知の爆発半径から始まります。

• Dockerの強化イメージを使い始めよう →
• Docker Scoutで脆弱性監視を体験しよう →

よくある質問

出典

Omdia、 「ソフトウェアサプライチェーンのセキュリティ確保：AI導入による開発規模拡大を支援する戦略的アプローチ」 、5月2026 。