サイバーレジリエンス法（CRA）対策の新ガイドライン：準備不足はもう言い訳できない

EU委員会がCRA対応を徹底的にサポート

Featured Snippet: Cyber Resilience Act（CRA）の新ガイドラインは、デジタル製品メーカーにリスク評価、依存関係の棚卸し、脆弱性報告の3つの義務を課す。2025年からの段階的施行に備え、今から準備を始めるべきだ。

EU委員会が発表したCyber Resilience Act（CRA）のガイドライン。これで「何をすればいいのか分からない」という言い訳は通用しなくなる。まるで税金の申告書を前に「書き方が難しすぎる」とぼやくのと同じで、ガイドラインが示された以上、あとは実行するだけだ。

評価から報告まで：リアルな負荷をシミュレーションする

中小企業には特に「評価」という単語が重くのしかかる。だが、ガイドラインは製品のリスクを段階的に評価する手法を具体例と共に示している。例えば、IoTデバイスの通信プロトコルに潜む脆弱性を特定する手順など、現場の技術者が迷わない粒度だ。

また、依存関係の管理では、サプライチェーン全体のソフトウェア部品表（SBOM）の作成が必須となる。これは「自分が使っている部品がどこから来ているか」を把握する作業で、まるで料理の材料を全て産地まで調べるようなもの。面倒だが、食中毒（＝脆弱性）を防ぐには不可欠だ。

オープンソースの扱い：もう「ただで済む」は通じない

オープンソースソフトウェア（OSS）にもCRAの義務が及ぶ。これまで「無料だから責任はない」とタダ乗りしていた企業には痛手だ。ガイドラインでは、OSSを商用製品に組み込んだ場合、メンテナーへの依存を前提としたリスク管理を求めている。例えば、脆弱性が見つかった場合の修正手順を事前に契約で決めておくなどの対策が必要だ。

「でもOSSってコミュニティ主導でしょ？」と反論する声が聞こえてくる。確かにその通りだが、CRAは「製品を市場に出す者の責任」を問う。レモン果汁を搾る機械を売るのに、レモン農家と何の契約も結ばないのは無謀だ――それと同じことだ。

「実質的な変更」とは？製品寿命の途中で気を付けるポイント

ソフトウェアアップデートが「実質的な変更」に該当するかどうかで、再評価が必要かが分かれる。ガイドラインでは、APIの変更や新機能の追加がセキュリティに影響を与える場合を例示している。例えば、スマートロックのアプリが顔認証を追加する場合、それは単なる機能追加ではなく、新たなリスク評価が必要な変更となる。

この判断基準は、自動車の改造と似ている。タイヤを替えるだけなら簡単だが、エンジンをチューンアップすれば安全性の再確認が必要。製品も同様で、「少しだけ」の積み重ねが大きな脆弱性を招く。

FAQ