CRA期限が近づく: コンプライアンスを確保するためのソフトウェアインフラストラクチャの将来性を保証する

欧州連合（EU）のサイバー・レジリエンス法（CRA）は、デジタル要素を含むすべての製品にとって時代を定義する規制を示しています。2027年12月11日に完全な規制の展開が予定されており、他の必須要件はそれよりも早く施行されるため、エンジニアリングチームや製品マネージャーはこの法律を理解することが重要です。結局のところ、メーカーは市場に出す前にすべてのデバイスが準拠していることを保証する主要な責任を負っています。

サイバーセキュリティインシデントが発生した場合の完全な責任に加えて、不適合の罰則は厳しいものです：

• 最大1,500万ユーロまたは世界年間売上高の2.5％の罰金が科され、不適合製品はEU市場から禁止、撤回、またはリコールされます。
• CEマーキングの喪失、つまり製品がEUで合法的に販売できなくなることを意味します。
• 多くの提案依頼（RFP）がCRA準拠のソリューションを要求するため、入札やパートナーシップからの自動的な除外の可能性があります。

さらに、準拠していないと判断されたメーカーは、市場の信頼性と信頼を失うリスクがあり、政府、金融、産業用途などの重要なセクターの顧客が包括的なセキュリティ保証を欠く製品を避ける可能性があります。

これらのリスクを考慮すると、システム設計者は設計プロセスの開始時から主要なハードウェアとソフトウェアの選択のセキュリティへの影響を考慮する必要があります。これらは長期的な準拠に影響を与え、市場アクセスにも影響を与えるためです。この記事では、CRAの下でのメーカーの主要なセキュリティコミットメントを定義し、長期的な準拠を維持するための強力な戦略としての無線（OTA）アップデートを強調します。その後、これらのアップデートを安全に提供するための堅牢なソフトウェアフレームワークを概説し、これらの原則に沿った市販のオフ・ザ・シェルフ（COTS）ソリューションの例を提供します。

CRAの下でのセキュリティコミットメント

消費者デバイスから分散インフラストラクチャコンポーネントまで、現代のエッジシステムは増加するセキュリティ脆弱性に苦しんでいます。古いファームウェアの問題や安全でない通信プロトコルは、データ漏洩や不正アクセスを引き起こし、デバイスの整合性を損なう可能性があります。したがって、CRAは最小限の攻撃面を維持するためにいくつかの措置を義務付けています：

まず、メーカーはデバイスを不正な改ざんから保護し、最初の起動からソフトウェアの整合性を確保する必要があります。CRAはこれを達成するための特定のフレームワークを定義していませんが、セキュアブートと信頼の根（RoT）の組み合わせは、この要件を満たすための基本的な基準として機能します。

Secure bootは暗号技術を用いて、真正かつ検証済みのソフトウェアのみがデバイス上で実行されることを保証します。このRoTは、デバイスの完全性を保証するため、bootプロセスの各段階を認証する信頼の連鎖における最初のリンクとなります（図1参照）。例えば、あるソフトウェアコンポーネントのハッシュが、RoT内の公開鍵と一致しない秘密鍵で暗号化されている場合、改ざんまたは破損が原因であるかを問わず、bootプロセスは停止されるか、ネットワークアクセスなどの高度なシステム機能が制限されます。これにより、マルウェアやbotnetの潜在的な拡散を防ぎます。

メーカーは、製品ライフサイクル全体を通じて継続的な脆弱性管理と迅速なセキュリティアップデートによって、完全性を保証しなければなりません。CRAは、少なくとも5年間、または製品の想定寿命がそれより短い場合はその期間に相当する義務的なサポート期間を定義しており、メーカーには市場投入時に具体的なサポート終了日を提示することを求めています。

実際に悪用されている脆弱性が発見された場合、メーカーはそれを自国のComputer Security Incident Response Team（CSIRT）およびEUのサイバーセキュリティ機関であるEuropean Union Agency for Cybersecurity（ENISA）に報告しなければなりません。この報告義務は2026年9月11日に発効し、以下の期限が定められています。

• 24時間：早期警告レポートをENISAおよび各国CSIRTに送信しなければなりません。
• 72時間：脆弱性に関する正式な通知を作成し、exploitの詳細およびそれがシステムに与える影響を説明しなければなりません。
• 14日：セキュリティパッチが利用可能になり次第、最終レポートを提出しなければなりません。

当然ながら、継続的な脆弱性管理には、ある程度のリアルタイム脅威監視が必要です。Common Vulnerabilities and Exposures（CVE）システムのような公開フレームワークは、メーカーがサードパーティ製ソフトウェアコンポーネントにおける新たな脅威を検出し、修正するのに役立ちます。これは、それらが自社デバイス内で実際に悪用される前であっても可能です。

上記を支援するため、CRAはメーカーに対し、各アップデートに関する技術文書の保持も義務付けています。特に、software bill-of-materials（SBOM）は、CycloneDXやSPDXなどの機械判読可能な形式で提供され、少なくともすべてのトップレベル依存関係を網羅している必要があります。この形式により、自動化ツールは各ソフトウェアbuildをCVEデータベースと照合し、新たな脆弱性が報告され次第、それを特定できます。その後、DevSecOpsチームは、サードパーティ製ソフトウェアを導入することなく、社内の問題を修正するパッチを配信できます。

SBOMに加えて、CRAへの適合には、高レベルのセキュリティリスク評価、開発プロセスの説明を含むシステムアーキテクチャ図、脆弱性管理プロセスの説明など、広範な文書化が求められます（図2参照）。これらの要素は、システムがCRAのガイドラインに沿ってsecure-by-designであることを検証するために使用されます。記録された文書は、デバイスのライフサイクル全体を通じて保存され、市場投入後10年間、またはより長いサポート期間が設定されている場合はその期間にわたり、監査人、監視当局、通知機関に提供可能でなければなりません。

最後に、正式な適合宣言（DoC）により、メーカーはEU市場アクセスのためにCEマーキングを使用できるようになります。DoC文書には、メーカーの名称と住所、製品の一意の識別情報、適合性を証明するために使用された標準および技術仕様への参照などが含まれます。CRAの「Important Class I」、「Important Class II」、「Critical」カテゴリに該当する一部のデジタル製品については、適合性を検証する第三者監査人の情報も含める必要があります。これらのデバイスには、産業用制御システム、IoTゲートウェイ、特権アクセス向けソフトウェアなどが含まれ、侵害が発生した場合、より広範なインフラ被害につながる可能性があります。

DoCに署名することで、メーカーはCRAへの適合について全面的な責任を負います。こうした責任の範囲を踏まえると、OTAアップデートは、パッチを迅速に配信し、接続デバイスの完全性を維持するための最も効果的な手段です。ただし、継続的なOTAアップデートには、CRAに準拠したアップデートをサポートするために特別に設計された高度なソフトウェアアーキテクチャが必要です。

定期的なOTAセキュリティパッチのためのソフトウェアインフラ設計

CRAの下では、DevSecOpsチームはセキュリティ問題の発見後、それを特定、分類、解決する際に大きな時間的プレッシャーにさらされます。セキュリティ管理を簡素化するため、組込みデバイスには以下のアーキテクチャ上の調整が有効です。

• Integrated telemetry reporting：デバイスの健全性データを収集してcloudプラットフォームに送信することで、メーカーは接続デバイス全体のbugやexploitを迅速に特定できます。telemetry reportingにより、チームはフリート全体へのrollout前に、限定的な実環境テストで新しいパッチの有効性を検証することもできます。
• 高度にモジュール化され、container化されたソフトウェアアーキテクチャ：脅威の分離は、デバイスが侵害された場合の攻撃対象領域の削減に貢献します。例えば、container化により、ユーザーインターフェースへの攻撃がオペレーティングシステム（OS）のcoreコードにアクセスすることを防ぎます。また、あるソフトウェアコンポーネントをアップデートしている間も、他のコンポーネントを継続稼働させることができ、運用上のdowntimeを削減します。同様に、モジュール型ソフトウェアは、脆弱性の特定を加速し、モノリシックなコードアップデートと比較してOTAデータ要件、ひいてはコストを削減します。
• Rollbackメカニズム：OTAアップデート中の中断や異常は、パッチの正しいインストールを妨げ、デバイスのbrickingを引き起こす可能性があります。rollbackメカニズムにより、アップデートが失敗した場合でもデバイスを常に稼働状態へ戻すことができ、メーカーはCRAに基づく責任を果たしつつ、デバイスの完全性を維持できます。

当然ながら、安全なOTAアップデートには、パッチが転送中に侵害されないこと、また署名および検証済みのfirmwareのみがデバイス上で実行されることを保証するため、end-to-endで暗号化されたトンネルが必要です。公開される各パッチに関する文書化要件を満たすため、メーカーはSBOMの自動生成とloggingを提供するソフトウェア開発フレームワークの恩恵を受けます。

しかし、CRAに準拠したフレームワークを実装することは、特に規制期限が急速に近づく中で、ソフトウェアをゼロから構築する開発者にとって大きな負担となる可能性があります。幸いなことに、COTSソリューションは、チームが所定の期限内にコンプライアンス要件を満たすのに役立ちます。

CRAへの適合に向けたCOTSソフトウェアフレームワークの活用

COTSソフトウェアフレームワークは、CRAにとって特に重要な複数の利点を提供します。第一に、開発を加速し、time-to-marketを短縮できる点です。同様に、コンプライアンスに関する法的責任は引き続きメーカーにありますが、実績のあるサードパーティソリューションは、規制上のblind spotに陥るリスクも低減できます。さらに、商用パートナーと連携することで、メーカーは自社のソフトウェアインフラに対する追加的な長期サポートを受けることができ、開発者の負担をさらに軽減できます。

このようなソリューションの一例が、SECOのClea OSです。Clea OSは、産業グレードの安全なシステム向けに設計されたカスタマイズ可能なソフトウェアアーキテクチャであり、CRAへの適合を簡素化する多くの機能を備えています。オープンソースのYocto ProjectをベースとするClea OSは、CRA監査に向けた再現性とトレーサビリティを提供し、文書化義務を支援するSBOM自動生成機能を備えています。

多くのクローズドなオペレーティングシステムとは異なり、Clea OSは、不要なコンポーネントを最小化し、攻撃対象領域を削減するとともに、全体的なセキュリティとresilienceを向上させる、軽量で管理されたLinux OS基盤として設計されています。container化はDockerによって実現され、脅威を分離し、patching中も24時間365日の運用を可能にします。このアプローチはさらにA/Bパーティショニングによって支えられており、デバイス上に常に動作可能なfirmwareイメージを保持し、アップデート失敗時にはアクティブなfirmwareをrollbackできるようにします。

さらに、Clea OSはsecure boot、デジタル署名付きOTAアップデート、SECOのより広範なCleaエコシステム（図3参照）と組み合わせた継続的なリアルタイムデバイス監視、そしてCyber Security Packageをサポートします。メーカーが脅威検知とpatchingの機会を最大化できるようにすることで、このサポートは、CRAが求める長期サポート期間に関する要件への対応を容易にし、安全なアップデートメカニズム、継続的な脆弱性管理、システムの完全性といった主要要件に直接対応します。

SECOのClea OSを含むCOTSソリューションの存在は、CRAへの適合が当初想定されるほど複雑である必要はないことを示しています。高いレベルのカスタマイズを可能にするready-madeのソフトウェアフレームワークを開発チームが活用することで、メーカーは新たなサイバーセキュリティ環境への移行を簡素化しながら、差別化された製品を市場に投入できます。