EUサイバー・レジリエンス法（CRA）に初めて取り組む製造業者は、ほぼ例外なく同じ直感に従って動きます。つまり、附属書Iに書かれている「悪用可能な脆弱性が存在しないこと」という要求事項を見て、真っ先にソフトウェア・コンポジション解析（SCA）に手を伸ばすのです。もちろん、SCAも重要であるのは明らかで、オープンソースおよびサードパーティの依存関係に存在する既知の脆弱性を特定し、サプライチェーンの透明性を補強するSBOM要件に対応するもので、成熟した組織のほとんどで既にAppSecツールキットの一部となっています。問題は、SCAだけでは不完全だということです。EU CRAの要求事項は、SCAがカバーする範囲だけにとどまりません。
市場監視当局からの指摘にも耐えうる真の意味での遵守とは、下流の顧客のコンプライアンス対応を支援し、EU CRAが防ごうとしている脆弱性悪用イベントにさらされるリスクを実際に軽減するものですが、それを達成するには多層的なテストのストラテジーが必要です。SCAは依存関係をカバーします。静的アプリケーション・セキュリティ・テスト（SAST）は独自開発のコードをカバーします。そして動的アプリケーション・セキュリティ・テスト（DAST）はサービスをカバーします。それぞれの層によってカバーする領域が異なるため、EU CRAを完全に遵守するにはこれら3つがすべて必要となります。
とはいえ、SCAから始めるのは間違いではありません。その理由はシンプルです。可視化できていないものは管理できないからです。EU CRAの適用対象となるすべての製品には、オープンソース・ライブラリ、商用コンポーネント、サードパーティSDK、上流依存関係などのサプライチェーンが含まれます。そしてEU CRAでは、これらすべてを完全かつ正確に可視化することが要求されます。SBOMは単なる文書で終わるものではありません。組織の脆弱性管理プログラムが機能するための運用基盤となるものです。
しかしEU CRAの枠組みの中でSCAを正しく機能させるには、ソースコード・リポジトリのスキャンにとどまらない、いくつかの具体的な技術課題に対処する必要があります。組み込み製品やファームウェア・ベースの実装では、複雑さは大幅に増大します。Yoctoビルド、商用リアルタイムOS、ファームウェア・イメージには、単純なソース・レベルの解析は通用しません。最新のSCAツールには、ソースコードが入手できない場合でも、コンパイル済みの成果物を検査してコンポーネントのフィンガープリントを特定するバイナリ解析機能や、サプライヤーから支給されたコンポーネント目録を自社の中央監視環境に取り込むことのできるSBOMインポート機能などがあります。
ここで大きな意味を持つのが、統合モデルです。「サプライヤーから受け取ったSBOMに商用ライブラリが含まれる場合でも、これらをインポートして監視できます」と、ブラック・ダックのソフトウェア・サプライチェーン・リスク戦略責任者Tim Mackeyは述べています。
組織のコンプライアンス態勢の強さは、サプライチェーン内の最も弱いコンポーネントの強さによって決まります。つまり、組織のSCAプログラムは、自社で開発していないものも含め、自社製品に含まれるすべてのコンポーネントを対象にする必要があります。
Linuxベースのファームウェア実装では、「Linuxカーネルから独立してコンポーネントをアップデートできるため、コンポーネント・レベルでの詳細度が本当に重要です」とMackeyは述べています。そして、その具体性はEU CRAの2つの要件を同時にサポートします。1つは悪用可能な脆弱性をコンポーネント・レベルで特定する能力、そしてもう1つはシステム全体を更新することなくそれらを修正できる能力です。
コンテナ・ベースのデプロイ環境の場合、これよりもシンプルではあるものの、似たような話があります。「Dockerコンテナでは、どのような脆弱性が存在するかを評価するのは比較的容易です」とMackeyは述べています。「Dockerイメージというのは、いつでもその場でアップデートできるようになっているので、EU CRAの義務の大半を自動化できます」。ここで重要なのは、コンテナのスキャンおよびアップデート・ワークフローを個々の切り離されたプラクティスとして実行するのではなく、EU CRAのコンプライアンス・パイプラインに統合することです。
EU CRAは、規則レベルではSBOMのフォーマット要件を特に指定していませんが、実際には相互運用性を考えて複数のフォーマットに対応できる能力が求められます。サプライチェーン・パートナーは、SBOMをSPDXやCycloneDX、あるいはその他のフォーマットで生成することが考えられます。また、自社の顧客にもそれぞれ希望するフォーマットがあります。元のフォーマットが何であれ、SBOMを自社の脆弱性追跡ワークフローに取り込める必要があります。サプライチェーンのエコシステム全体でSPDX、CycloneDX、CSAF、VEX、VDRをサポートすることは、単なる推奨事項ではありません。拡張可能な形でEU CRAを遵守するには、それが運用上の前提条件となります。
ここで多くの組織は、最初に立てたEU CRAへのコンプライアンス計画が最初の大きな障害にぶつかることになります。附属書Iの「悪用可能な脆弱性を排除する」という要件は、依存関係だけでなく自社のすべてのコードが対象となるためです。この要件を満たすには、使用しているオープンソース・コンポーネントだけに 着目するのではなく、独自開発のソースコードに対してSASTスキャンを実行する必要があります。
サプライチェーンという側面を考えると、多くの製造業者にとってSASTが必須であることは論をまちません。自社のソフトウェアにセキュリティ上の不具合があると、そのソフトウェアをコンポーネントとして使用している他社製品は、EU CRAの遵守において問題に直面します。下流への説明責任の圧力は現実のものであり、それに対処する技術的規律となるのがSASTです。
静的解析は、EU CRAのすべての要求事項の根底にある「セキュア・バイ・デザイン」の義務に対応します。EU CRAが求めているのは、開発が完了した後に製品のセキュリティ対策をとることではありません。開発を進めながら不具合を取り除くことが求められています。この原則を最も直接的に実装したものが、CI/CDパイプラインに統合されたSASTです。こうすると、不具合が発生したその場で修正でき、コード・レベルのセキュリティ上の不具合が本番環境に流れ込んで脆弱性対応の義務が発生するのを防ぐことができます。
SASTは、開発パイプラインに統合するのが現実的です。SASTスキャンは、リリース・ゲートで実行するだけでなく、コード変更のたびに実行することが望まれます。そして、インジェクションの欠陥、認証の弱点、安全でないデータハンドリング、暗号化のエラーなど、EU CRA附属書Iで取り除くことが暗黙的に要求されている種類の不具合を検出できるように設定しておくようにします。SASTの結果は、SCAの結果、SBOM文書、脆弱性管理記録などを保存しているのと同じコンプライアンス文書化システムに入力しておくことが推奨されます。
クラウド・サービス、API、またはネットワーク接続されたバックエンド・システムを利用して機能を提供する製品は、3つ目のテスト階層であるDASTでカバーします。この種の製品アーキテクチャは、特にEU CRAの適用対象としてますます一般的になっています。このような製品では、SCAとSASTを組み合わせてもなお、検査できない重大なアタック・サーフェスが残されます。
「提供されるものの一部にクラウド・サービスそのものが含まれる場合、それは単なる製品ではなくシステムであるため、ペネトレーション・テスト、レッドチーム、DASTのようなソリューションの出番となります」とMackeyは述べています。DASTは動作中のアプリケーションやサービスをテストして、静的解析では検出できない悪用可能な脆弱性を見つけます。ビジネス・ロジックの欠陥、認証バイパスの条件、実行時のインジェクション脆弱性、APIのセキュリティ上の問題などは、システムを実際に動作させないと顕在化しません。
EU CRAの適用対象には、規制を受けるハードウェアおよびソフトウェア製品に付随するクラウド・サービスやリモート・データ処理機能も含まれることが明示されています。EU CRAの適用対象となる自社製品にコネクテッド・サービスのコンポーネントが含まれる場合、DASTの役割は単に補助的なものではなくなります。DASTは、このアーキテクチャ層にとっては必須のテスト手法であり、そのカバレッジはSCAおよびSASTプログラムの場合と同じ厳密さで文書化する必要があります。
EU CRAの脆弱性報告義務には、継続的な期限（最初の報告を24時間以内、確認を72時間以内、包括的な報告を14日以内）が設定されています。2年間にわたって出荷してきたコンポーネントに脆弱性が見つかった場合も、たった今コミットしたばかりのコードに脆弱性が見つかった場合も、発生する義務は同じです。こうした現実を考えると、一定の間隔を置いた単発的なセキュリティ・スキャンはEU CRAの遵守とは根本的に相容れません。製品群全体を対象にした継続的監視が必要です。
悪用までの時間に関するデータを見れば、その緊急性は明らかです。2018年の時点では、脆弱性が見つかってから実際に悪用されるまでの平均期間は約2年でした。2026年現在、この期間は24時間未満にまで短縮しており、2028年には1分になるとの予測もあります。EU CRAが設定したこの短い報告期限は、こうした現実を直接反映したものです。そして自社の監視インフラにも、これと同じスピードが求められます。
ここでは、自動化を避けて通ることはできません。新しいCVEのトリアージ、コンポーネント目録との照合、通知の作成、報告の送信などを手作業で行っていたのでは、EU CRAで要求されるスピードに対応できません。コンプライアンス・プログラムには、新たに公開された脆弱性を特定し、どの製品が影響を受けるかを判断し、通知を開始し、定義済みのプロセスを通じて対応を進めるという一連の作業を、24時間以内に完了できる自動化されたワークフローが必要です。2026年9月の期限を迎えてもまだ手動による脆弱性管理プログラムを実施している組織は、EU CRAの報告義務を構造的に満たすことができません。
実際に本稿で紹介したものすべてを統合しようとすると、セキュリティ・テストの要件を製品ごとに分析する必要があります。すべての製品が、すべてのテスト層に同じだけの投資を必要とするわけではありませんが、EU CRAはそれを考えるための明確な枠組みを確立しています。
文書化という観点も、全体を通じて欠かせません。テストだけでは、遵守への道のりはまだ半ばです。テストを実施したことを実証し、その範囲と方法論を説明し、テスト結果を追跡して修正が完了したことを示す能力が必要です。実施したすべてのテストについて、SBOMやスキャン・レポートからトリアージ記録、修正証跡まで、遵守のストーリーを裏付ける文書等を生成することが求められます。
この段階で組織が最も陥りがちな失敗は、EU CRAの遵守に向けたセキュリティ・テストを単なるコンプライアンスのためのプロジェクトと捉えてしまい、運用への投資と考えないことです。その考え方の違いによって、環境の構築とリソース配分のあり方も大きく変わってきます。
単なるコンプライアンスのためのプロジェクトと考えてしまうと、規制の要求事項を満たすことだけを目的として、その場しのぎのスキャンやSBOMなどによる単発的な成果物しか生まれません。しかし運用への投資であると考えた場合、継続的な監視パイプライン、自動化されたトリアージ・ワークフロー、統合されたSBOM管理、SCA/SAST/DASTツールを埋め込んだ開発プロセスといった基盤を確立できます。EU CRAの継続的な義務を満たすには、後者の考え方が必要です。2026年9月を迎える時点で、自社の基盤が稼働状態になければなりません。計画段階でもパイロット段階でもなく、報告義務の対象となるすべての製品について、本番環境で稼働している必要があります。
製造業者がこの移行を最も効果的に乗り切るには、包括的なSCAによる依存関係の可視化、SASTによるコード・レベルの不具合除去、DASTによるサービス層への対処、そして脆弱性開示から悪用までの期間短縮に対応できる継続的監視基盤など、適切なツール・スタックを用いて環境を構築する必要があります。まずは基盤への投資を優先してください。そうすれば、コンプライアンスという結果は自然についてきます。