Cyber Resilience Actで最も難しい要件はサイバーセキュリティではない

このページの内容は、サードパーティサービスによって自動翻訳されています。

EUサイバーレジリエンス法（CRA）について書かれている内容の多くは、これをエンジニアリング上のセキュリティ課題として捉えています。セキュア・バイ・デザインの原則、脆弱性開示の期限、そして必要に応じてCycloneDXまたはSPDX形式で生成できるソフトウェア部品表（SBOM）などです。

この考え方が魅力的なのは理解できます。セキュリティチームはコンプライアンス要件への対応を担うことに慣れており、SBOMの生成はツールで解決できる問題のように見えます。ビルドパイプラインをスキャンし、機械可読形式の出力を取得して保存する。それで済むように思えます。

しかし、SBOMは部品表についての情報です。部品表そのものに代わるものではありません。

より難しいのは、問題が発生したときです。新たに特定された脆弱性を、影響を受けるコンポーネントやソフトウェアまで追跡し、さらにそれを使用している構成や製品バリエーションまでたどる必要があります。サプライヤーによる判断や変更も関係します。すでに市場に出ている製品も対象になります。

そうなると、SBOMの生成は簡単な部分に思えてきます。

CRAは製品セキュリティを発売時のチェック項目ではなく、継続的な義務として扱う

サイバーレジリエンス法（規則（EU）2024/2847）は、EU市場におけるハードウェア、ソフトウェア、およびその両方を組み合わせた製品を含む「デジタル要素を備えた製品」を対象とするEU法です。2024年12月10日に発効しました。

CRAは大まかに言えば、メーカーに対して、設計段階からサイバーセキュリティに対応し、製品のコンポーネントや脆弱性に関する情報を維持し、製品出荷後も脆弱性に対応し、特定のセキュリティ問題が発生した場合には報告義務を果たすことを求めています。

すべての義務が同時に適用されるわけではありません。報告要件は2026年9月11日から適用されます。CEマーキングを含む完全なコンプライアンス要件は、2027年12月11日から適用されます。

違反した場合、多額の罰則が科される可能性があります。

しかし、運用上の課題はそれよりはるかに早く始まります。メーカーは製品に何が含まれているかを把握し、セキュリティ問題が発生した際に対応できるよう、その情報を十分に最新の状態に保つ必要があります。

この観点から見ると、CRAは製品データとトレーサビリティの課題でもあります。

時計が動き始めるのは2027年ではなく、今月

CEマーキングや適合性評価を含むCRAへの完全準拠の期限は2027年12月11日です。多くの人が覚えているのはこの日付であり、そのため規制への対応はまだ先のことのように感じられます。

しかし、報告義務は2026年9月11日から始まります。

積極的に悪用されている特定の脆弱性や重大なインシデントについては、24時間以内の早期警告と、72時間以内のより詳細な通知が求められます。

その72時間の間に何をしなければならないか考えてみてください。影響を受けたコンポーネントはどこから来たのか。どの構成で使用されているのか。サプライヤーが変更したのか。すでにリリースされたどの製品が影響を受けるのか。

その答えを探し始めるには、あまり時間がありません。

CRAを主にSBOMの問題として捉えると、この違いが見落とされがちだと私は考えています。SBOMは、システムが製品に含まれていると認識しているものを示します。しかし、脆弱性が見つかれば、その周囲にある製品定義も同じくらい重要になります。

影響を受けるコンポーネントやソフトウェア依存関係を、正しいリリースに結び付けられるでしょうか。正しい構成はどうでしょうか。その背景にあるサプライヤーの判断はどうでしょうか。そして、実際に市場に出た製品を特定できるでしょうか。

ここでトレーサビリティは、理論ではなく実務上のものになります。

SBOMの正確性は、それを支える製品定義の正確性に左右される

ソフトウェア部品表は、何らかの情報をもとに生成する必要があります。

部品表があるシステムで管理され、製造BOMが別のシステムで変化している場合、状況はすぐに複雑になります。サプライヤー情報がメールに残っていることもあります。変更の一部が、管理された製品記録に適切に反映されていない場合もあります。

SBOMはこうしたギャップも引き継ぎます。機械可読だからといって、必ずしも完全であるとは限りません。

電子機器製造では、この問題が特にわかりやすく現れます。PCBAデータは今でも、部品番号と製造ファイル一式という形で後工程に渡されることが多く、その一方で設計意図、承認済みの調達先、代替部品、製造上の判断などは別の場所で管理されている場合があります。

そして現実には、さまざまなことが起こります。

コンポーネントが入手できなくなる。代替品が認定される。生産を継続するためにサプライヤーが別の判断をする。

後になって問題になるのは、何が起きたのかを誰かが追跡できるかどうかです。代替品への変更は製品記録に反映されたでしょうか。エンジニアリング、製造、コンプライアンス、セキュリティの各チームは、その判断を確認し、どこに適用されるのかを把握できるでしょうか。

ソフトウェアにも、形は違っても同じ問題があります。ファームウェアのバージョンは変わります。オープンソースの依存関係も進化します。構成は分岐します。サプライヤー提供のソフトウェアは、機械または電気の定義とは別に変更されることがあります。

時間が経つにつれて、市場にある製品は、企業が把握していると思っている製品定義とは大きく異なるものになる可能性があります。

ここで役立つテストがあります。あるコンポーネントまたはソフトウェア依存関係に脆弱性があると仮定し、影響を受けるすべての製品、構成、バリエーションを72時間以内に特定してみてください。そして、その回答を証明してみてください。

多くのメーカーにとって、このテストで明らかになるのは、脆弱性スキャンとはほとんど関係のない問題でしょう。

リリース時に組み立てるコンプライアンスでは、インシデント発生時の時間制限に対応できない

規制対象となる製造業では、リリースゲートが近づいてからコンプライアンス状況を再構築するというパターンがよく見られます。誰かがエンジニアリングシステム、サプライヤーの申告書、スプレッドシート、メール、ERPシステムから情報を集めます。証拠をまとめてレビューし、製品を次の段階へ進めます。

手間はかかります。しかし、企業側で期限をコントロールできる場合には機能します。

インシデントの場合は違います。

脆弱性が明日の朝に公表されるかもしれません。製品出荷から数か月後にサプライヤーが問題を特定する可能性もあります。

その時点では、すでに時計は動き始めています。

製品、コンポーネント、ソフトウェア、構成、変更、サプライヤーの証拠の間にある関係を、すぐに利用できる状態にしておく必要があります。プレッシャーの中でそれらを再構築することは、戦略とは言えません。

CRAはここで、メーカーが長年抱えてきた問題を浮き彫りにします。分断された製品データは、手戻りを生み、意思決定を遅らせ、変更管理を複雑にし、コンプライアンス対応を難しくします。

今では、そこにもう一つのリスクが加わります。期限が社外から課される可能性があるのです。

迅速な対応を可能にするのが、ライフサイクル全体のトレーサビリティです。SBOMは、何が存在するはずなのかを示します。トレーサビリティは、その周囲で何が起きたのかを明らかにするのに役立ちます。どこで使用されたのか、何が変更されたのか、どの構成がリリースされたのか、どのサプライヤーの証拠がその判断を裏付けていたのか、といったことです。

報告期限の時計が動き始めたとき、こうしたつながりが重要になります。

ここでデジタルスレッドが実用的なものになる

デジタルスレッドは長年、エンジニアリングの効率、コラボレーション、より良い意思決定という観点から語られてきました。CRAは、デジタルスレッドにもっと差し迫った役割を与えます。

製品について難しい質問をされたとき、その履歴を一から再構築することなく、ライフサイクル全体を通じて答えをたどれる必要があります。

だからといって、すべてを一つの巨大なシステムに入れる必要があるわけではありません。ほとんどの企業にとって、それは現実的でも必要でもありません。

必要なのは、つながりを維持することです。ハードウェアの変更が構成に影響する場合があります。サプライヤーの判断によって承認済みの調達先が変わることもあります。ソフトウェアは独立して進化しながらも、特定のリリース済み製品に属している場合があります。こうした判断の根拠となる証拠も、つながった状態を維持する必要があります。

PLM、MBSE、MBE、ソフトウェアライフサイクル管理、ERP、サプライヤーシステム、セキュリティツールには、それぞれ役割があります。より大きな問題は、それらの間で何が起きるかです。

製品が変化しても、それらの関係は維持されるでしょうか。

CRAは、それを確かめるためのかなり容赦のない方法を提供します。

CRAが本当に求めている取り組み

ここで述べている内容は、法的助言またはコンプライアンスに関する助言ではありません。分類に関する判断、適合性評価の方法、具体的な報告義務については、ベンダーのブログ記事ではなく、資格を持つ法律およびコンプライアンスの専門家に相談する必要があります。

しかし、エンジニアリング組織にとってCRAは一つの実務的な問いを投げかけます。厳しい期限の中で、製品データを使って迅速に答えを出せるでしょうか。

CRAに関するコンテンツの多くは、規制が何を要求しているかに焦点を当てています。しかし、期限が来る前の今だからこそ、考える価値のある別の問いがあります。

その対応を可能にするために、エンジニアリングデータはどのような状態である必要があるのでしょうか。

その違いによって、72時間以内の通知を管理された情報から作成できるか、それともメール、スプレッドシート、電話、そして人の記憶に頼る緊急対応になるかが決まるかもしれません。

注目を集めるのはセキュリティツールです。しかし、そのツールを役立つものにするのは、管理された製品定義と、それを取り巻くトレーサビリティです。

推奨されるアクション

これらを始めるために、CRAコンプライアンスプログラム全体が完成している必要はありません。次の期限が来てからではなく、その前に答えておくべき問いです。

• 実際に対象となるものを洗い出す。CRAにおける「デジタル要素を備えた製品」に該当し、適切に維持されたSBOMが必要となる製品ラインを特定します。これはエンジニアリングだけで判断するものではなく、コンプライアンスおよび法務の専門家が関与すべき分類作業です。
• 部品表が実際にどこに存在するのかを確認する。コンプライアンスデータやサプライヤーデータにつながった、一つの管理されたBOMがあるでしょうか。それともECAD、ERP、スプレッドシートに複数のバージョンが存在し、最近誰も整合性を確認していない状態でしょうか。
• 記録されていない代替品を探す。コンポーネントの代替が変更管理プロセスを経ているのか、それともそのまま出荷されたのかを、サプライヤーや製造委託先に直接確認してください。安心できる答えよりも、正直な答えのほうが役に立ちます。
• 実際のインシデントというプレッシャーがない今、72時間テストを実施する。一つの製品を選び、特定のコンポーネントまたはソフトウェア依存関係から、影響を受けるすべての製品、構成、バリエーションを追跡するまでにどれくらい時間がかかるか確認します。その後、その回答を裏付ける証拠を確認してください。追跡が誰かの受信トレイ、スプレッドシート、記憶に依存しているなら、それこそがこのテストで明らかにすべき問題の一部です。
• コンプライアンスデータとサプライヤーデータを製品記録の一部として扱う。エンジニアリングデータを保持するプラットフォームが何であれ、製品定義、承認済みの調達先、コンプライアンス状況、サプライヤーの証拠、変更、リリース済み構成の関係を維持する必要があります。そうすることで、文書化の履歴は通常業務の副産物となり、リリースやインシデント対応のたびに誰かが再構築しなければならないプロジェクトではなくなります。

供給の変動、領域をまたぐ変更、証拠に対する要求の高まりが、ハイテクおよびエレクトロニクスメーカーにどのような影響を及ぼしているのか、またデジタルプロダクトパスポート（DPP）やCRAについてさらに詳しく知りたい方は、関連記事分断されたデータからハイテク・レジリエンスへをご覧ください。