企業がサイバーレジリエンス法について本当に学んでいること

OmniTrustの「CRAから学んだこと」シリーズへようこそ。

欧州連合のサイバーレジリエンス法（CRA）が初めて発表されたとき、多くの組織はほかの新しい規制と同じように捉えました。最初の質問は予想どおりでした。自社に適用されるのか？ どの製品が対象なのか？ どのような文書が必要になるのか？ コンプライアンスにはどれほどの作業が必要なのか？

企業が計画から実装へ進むにつれ、別の現実が見えてきました。

最も進展している組織は、もはや規制そのものを理解することだけに集中していません。製品ポートフォリオ全体、エンジニアリング組織、サプライチェーン、サポートライフサイクル全体で、規制をどう運用へ落とし込むかに集中しています。

ここからが本当に興味深いところです。

過去1年間、OmniTrustはCRAコンプライアンスに積極的に備える製造業者、ソフトウェアベンダー、産業企業、医療機器企業、コネクテッド製品提供企業と協力する機会を得てきました。また、同じ根本的な問いに答えようとしている業界専門家、製品セキュリティリーダー、コンプライアンス担当者、エンジニアリングチーム、経営幹部とも数え切れないほどの時間を費やしてきました。

CRAコンプライアンスを、規制上の要件から運用上の現実へどう変えるか？

私たちが発見したのは、最大の課題は企業が予想していたものではないことが多い、という点です。

組織は、多くの場合、サイバーセキュリティコントロール、セキュア開発手法、技術文書から取り組み始めます。もちろん、それらは重要です。しかし多くのチームはすぐに、より難しい課題がガバナンス、説明責任、エビデンス管理、ソフトウェアサプライチェーンの可視性、脆弱性対応プロセス、サポートの約束、部門横断の調整にあることに気づきます。

言い換えれば、安全な製品を作ることは重要ですが、それだけでは十分ではありません。

CRAは、サイバーセキュリティの課題であるのと同じくらい、運用上の課題であることが明らかになりつつあります。

このシリーズを作った理由

このブログは「CRAから学んだこと」シリーズの始まりです。目的はシンプルです。CRA対応を実際に進めている組織から得られた、実践的な観察、導入上の教訓、新たなベストプラクティスを共有することです。

規制文言を繰り返したり法律を要約したりするのではなく、理論から実行へ移る中で企業が実際に経験していることに焦点を当てます。

業界を問わず、同じようなパターンが数多く見られます。

製品インベントリは不完全なことがよくあります。ソフトウェア依存関係が十分に把握されていないこともあります。文書は複数のシステムに分散しがちです。コンプライアンス活動の責任者が不明確な場合もあります。長い製品ライフサイクルにわたってエビデンス収集を持続させることは難しくなります。既存のセキュリティプログラムは価値があっても、それだけで規制当局の期待を自動的に満たすわけではないことも分かってきます。

こうした状況は珍しくありません。むしろ、驚くほど一般的になっています。

良い知らせは、組織がそれらに対処する実践的な方法も見つけつつあることです。

シニアリーダーが学んでいること

初期の導入活動から得られている最も重要な教訓の一つは、CRAコンプライアンスを一つの部門だけに任せることはできない、ということです。

セキュリティチームだけでは解決できません。

エンジニアリングチームだけでも解決できません。

法務チームだけでも解決できません。

最も速く進んでいる組織は、CRAを単独のコンプライアンスプロジェクトではなく、事業変革の取り組みとして扱っています。

つまり、経営層のスポンサーシップ、部門横断ガバナンス、明確に定義された説明責任、繰り返し可能なプロセスが、技術的なコントロールと同じくらい重要になります。

議論はすぐにサイバーセキュリティの範囲を超え、製品管理、品質、運用、カスタマーサポート、調達、サプライヤー管理へ広がります。

その結果、組織の考え方も変わります。成功している企業は「CRA評価をどう完了するか？」ではなく、「製品ライフサイクル全体を通じて、コンプライアンスを継続的にどう実証するか？」と問うようになります。

繰り返し見られる一般的な誤り

組織ごとに道のりは異なりますが、いくつかの共通テーマが何度も現れます。

CRAを法務上の作業として扱い、追加ガイダンスを待ってから行動しようとする企業があります。既存の認証や成熟したセキュリティプログラムがCRA要件を自動的に満たすと考える組織もあります。多くの組織は、エビデンス管理にスプレッドシートや分断された文書リポジトリへ大きく依存し、時間の経過とともにコンプライアンス維持がますます難しくなることに後から気づきます。

おそらく最も一般的な誤解は、CRAコンプライアンスを一度きりのプロジェクトとして見ることです。

実際には、規制の最も重要な義務の多くは製品が市場へ出た後に始まります。脆弱性管理、セキュリティ更新、インシデント報告、ソフトウェアコンポーネントのガバナンス、サポートの約束、文書の維持は、すべて製品ライフサイクル全体を通じて続きます。

コンプライアンスはゴールではありません。継続的な規律になります。

企業はどこから始めるべきか

CRAへの取り組みを始めたばかりの組織にとって、最初のステップは見た目ほど複雑ではないことがよくあります。

まず製品ポートフォリオを理解します。明確な責任者を定めます。製品を適切に分類します。ソフトウェアコンポーネントと依存関係を棚卸しします。脆弱性対応手順を定義します。エビデンスがどこで作られ、どこに保存されているかを特定します。

最も重要なのは、これらの活動を時間の経過とともにどう維持するかを最初から考えることです。

最も先行している企業は、必ずしも最大のセキュリティ予算を持つ企業ではありません。多くの場合、繰り返し可能なガバナンスプロセスを確立し、製品ライフサイクル全体にわたって製品サイバーセキュリティ情報を管理する信頼できる記録システムを構築した企業です。

次に取り上げる内容

今後の記事では、初期の導入活動から得られている最も重要な教訓を詳しく掘り下げます。

製品分類が、なぜ組織が最初に直面する大きな障害の一つになっているのかを見ていきます。ソフトウェアサプライチェーンガバナンスとオープンソースソフトウェアの可視性が高まっている理由も取り上げます。CRAがサプライヤーとの関係をどう変えているか、なぜリリース後の義務が多くの企業の想定以上に大きな負担になっているか、なぜ成熟したセキュリティプログラムがそのまま規制対応力につながらないのかについても説明します。

そして何より、製品マネージャー、エンジニアリングリーダー、CISO、コンプライアンス担当者、経営チームがすぐに活用できる実践的な教訓に焦点を当てます。

CRAは今も進化していますが、一つだけすでに明確なことがあります。完璧な明確さを明日まで待つ組織より、今日から運用能力を構築し始める組織の方が、はるかに強い立場に立てます。

道のりを支える仕組み

お客様とのCRAに関するほぼすべての議論で繰り返し出てくるテーマがあります。多くのチームは最初のセキュリティ評価を作成できます。本当に難しいのは、それを常に最新に保つことです。

製品は進化し、ソフトウェアは変わり、脆弱性が見つかり、サプライヤーは変わり、規制も成熟します。組織には、静的な文書や分断されたスプレッドシートに頼るのではなく、製品サイバーリスクの「生きた記録」を維持する方法が必要です。

そのためにOmniTrustはCertifyを開発しました。Certifyは、コンプライアンスをある一時点の評価から継続的なライフサイクルプロセスへ変えることを支援します。製品サイバーリスクの記録システムとして、Certifyは評価、コントロール、エビデンス、SBOM、脆弱性、規制上の義務を一つの環境で管理できるようにします。また、CRA対応を長期にわたって支えるために必要な追跡可能性と説明責任も維持できます。コネクテッド製品のサイバーリスクは一度きりのプロジェクトではなく、ライフサイクルプロセスだからです。

このシリーズの今後の記事の通知を受け取るには、ブログのホームページで購読してください。次回は「ブログ #2：最初の問題はセキュリティではない。スコープだ」です。