2024年12月に制定されたEUのサイバーセキュリティ規制であるサイバーレジリエンス法（Cyber Resilience Act, CRA）は、デジタル要素を備える製品に対し、市場参入の新たな基準を打ち立てつつあります。デバイスメーカー、ソフトウェアサプライヤー、システムインテグレーターへのメッセージは明確です。セキュリティはもはや後付けの付加機能ではなく、製品とそのプロセスの双方における要件です。企業は、設計・開発から運用、脆弱性管理に至るまで、検証可能な形で自社のセキュリティの強さを示す必要があります。

2つの中核要件に注目：セキュア・バイ・デザイン（Secure by Design）と脆弱性対応

CRAは、デジタル要素を備える幅広い製品を対象とし、市場全体のサイバーレジリエンス向上を目的としています。技術要件だけでなく、製造事業者の責任、インシデント報告、アップデート義務も規定しています。要するに、コンプライアンスは一度きりの監査ではなく、継続的なエンジニアリングプロセスになりました。検証可能なセキュリティ能力は、組織のリスクと罰則を抑制することを可能にすると同時に、市場での差別化と顧客信頼の獲得にもつながります。とりわけ重要なのは、次の2つの観点です:

1. 暗号化とパスワードにとどまらない: セキュア・バイ・デザインに基づくセキュリティエンジニアリング

セキュア・バイ・デザインとは、機能一覧にいくつかのセキュリティオプションを付け足すことだけを意味するものではありません。中核となる考え方は、要件定義やアーキテクチャといった開発の上流でセキュリティ上の意思決定を行い、開発ライフサイクル全体に制御メカニズムを組み込むことにあります。CRAのAnnex I Part Iには、この戦略に整合する要件が複数定められています。たとえば、次のとおりです。

• 既知の悪用可能な脆弱性がないこと（Annex I Part I 2(a)）: リリース前に、製品に既知で悪用可能な脆弱性が含まれていてはなりません。そのため、製造業者は脆弱性スキャン、修正、検証を製造プロセスに統合する必要があります。
• セキュアなデフォルトおよびセキュアな構成（Annex I Part I 2(b)）: 製品は出荷時に初期状態で安全な設定（セキュア・バイ・デフォルト）であり、かつ、初期状態を復元できなければなりません。したがって、弱い暗号方式を採用したまま、あるいは高‑リスクなサービスを有効化したまま、製品を出荷すべきではありません。
• アクセス制御および不正アクセスからの保護（Annex I Part I 2(d)）：認証、アクセスおよびID管理、ならびに不正アクセスを報告できる機能を含む、適切な制御メカニズムを実装すること
• データの機密性の保護（Annex I Part I 2(e)）：保存時および転送時のデータに対し、最新技術水準の暗号技術および関連手法など、最先端のメカニズムを適用すること
• データおよびコマンドの完全性の保護（Annex I Part I 2(f)）：データ、コマンド、コード、および構成を不正な変更から保護し、改ざんを報告できるようにすること
• 目的別のデータ最小化（Annex I Part I 2(g)）：製品機能のために必要かつ関連するデータのみを処理すること

これらの条項により、セキュリティ要件は「何を達成したか」から「どのように実施したか」へと重心が移ります。特定のセキュリティ機能を備えるだけでは不十分であり、ライフサイクル全体にわたって、正しい設計・実装・テスト・運用と、そのトレーサビリティを示すエンジニアリング上の証跡を提示することが求められます。

2. 脆弱性対応は、単なるパッチ適用にとどまらず、それは、エンドツーエンドの責任の連鎖である

脆弱性対応は本質的に、受領、分析、是正、通知、更新版のリリースからなる継続的なサイクルであり、インシデント報告と同期させるべきです。CRAでは、Annex I Part II「Vulnerability handling requirements」に位置付けられており、主なポイントは次のとおりです。

• 脆弱性の特定とコンポーネント可視性（Annex I Part II 1）：製造業者は脆弱性とコンポーネントを特定して記録し、一般的に使用される機械可読形式でソフトウェア部品表（SBOM）を提供しなければなりません。
• Coordinated Vulnerability Disclosure（CVD）ポリシーの確立と実施（Annex I Part II 5）：製造業者は公開された脆弱性開示ポリシーを備え、関連する開示に関する仕組みを確保しなければなりません。
• 脆弱性報告の連絡窓口の提供（Annex I Part II 6）：報告窓口の提供を含め、デジタル要素を備える製品およびその第三者コンポーネントに関する潜在的な脆弱性情報の共有を容易にするための措置を講じる必要があります。
• 更新リリースの適時性と透明性（Annex I Part II 8）：特定されたセキュリティ上の問題に対して、セキュリティ更新を迅速に公開することが求められます。あわせて、必要なユーザー通知と、取るべき対応の案内も必要です。

実務上は、標準化された受付窓口の整備、分類と修正までの期限（タイムライン）の設定、回帰テスト、セキュアな配布の仕組みを構築し、顧客への一貫した通知と推奨事項によって支えることを意味します。さらに、脆弱性管理はサプライチェーン全体を包含する必要があります。単一障害点を生まないよう、サードパーティおよびオープンソースのコンポーネントについても、自社の修復対応と足並みをそろえ、対応完了の証跡を確保しなければなりません。

サプライヤーのアップグレード：どのようにプロセス、エビデンス、サプライ‑チェーン・ガバナンスを市場の信頼へと転換するか

CRAが本質的に求めているのは、単に「より安全な製品」を増やすことではなく、「より優れたサプライヤー」であることです。企業は次のことを実行する必要があります。

• 包括的なセキュア開発ライフサイクル（SDL）を確立し、製品ライフサイクル全体にわたってセキュリティ制御を組み込む。具体的には、条項で示された要求事項、脅威モデリング、コード分析、ペネトレーションテストト、およびアップデート管理を実施する。附属書IパートIに準拠した追跡可能な証拠を保持すること。
• 脆弱性やインシデントへの対応において、迅速性、透明性、一貫性を確保するため、Annex I Part IIに整合した、脆弱性の受付から修正、通知、更新リリースまでのエンドツーエンドで一貫した脆弱性管理体制を構築すること。
• サプライチェーンガバナンスを導入し、SBOM（ソフトウェア部品表）の維持、依存関係のリスク分析を実施し、協調的な脆弱性開示（CVD）プロセスを運用することで、サードパーティ製コンポーネントがコンプライアンス不適合の原因とならないようにすること。
• セキュリティアドバイザリ、サポートガイド、バージョンのライフサイクル（保守終了を含む）全体にわたり、明確な方針と監査可能な記録を維持することで顧客コミュニケーション戦略を整備し、技術的な能力を可視化された信頼へと転換する。

セキュリティを「コンプライアンスのチェックリスト」ではなく「エンジニアリング能力」にする

デバイスメーカーにとって重要なのは、監査可能な記録を保持しながら、CRAの条項をSDLおよび脆弱性管理のコントロール全体に実装することです。これにより、セキュリティは受け身のコンプライアンス対応作業から、再現可能で、測定可能で、正当性を説明できる競争優位性へと進化します。

システムインテグレーターは、声明やチェックリストだけに頼るのではなく、エンジニアリング上の実践と客観的な証拠によってサプライヤーのセキュリティを検証する必要があります。重要なシステムの長期的なレジリエンスと信頼性は、セキュリティを中核的なエンジニアリング原則として位置づけるベンダーと協働することによってのみ実現可能となるのです。

CRAに対するMoxaの取り組みについて詳しくは特設サイトをご覧ください。