EUサイバー・レジリエンス法（CRA）の脆弱性報告義務は、コンプライアンス上の理論と運用の現実が衝突する場所です。そして、対応準備が完了している組織とそうでない組織の差がほとんど一瞬にして露呈する部分でもあります。
EU市場に上市した製品に、実際に悪用が確認されている脆弱性があることを認識した瞬間から、一連の報告義務の流れが始まります。これらの義務は、組織の複雑さや、セキュリティ・チームのリソース不足、あるいは旧来型の脆弱性管理プロセスによる運用上の摩擦などは一切考慮してくれません。時計の針は止まることはなく、刻々と進みます。
本稿では、EU CRAの脆弱性管理における3つの互いに関連し合った柱について説明します。
製造業者は、EU CRAの適用対象製品に実際に悪用が確認されている脆弱性を認識した場合、明確なコンプライアンスの手続きに従う必要があります。
認識してから最初の報告までが24時間です。修正から24時間でもなければ、最終的な根本原因分析から24時間でもありません。脆弱性が存在し、それが悪用可能であることを知った時点から24時間です。これが意味するところは明らかで、脆弱性管理ワークフローの中に、この報告期限内に完了できないような手動のプロセスが存在すると、それがコンプライアンス上のリスクとなるということです。コンポーネントを完全に可視化できておらず、新たに公開された脆弱性を速やかに認識できない場合もコンプライアンス上のリスクとなります。組織内で通知プロセスを開始する責任者が誰なのかがあいまいな場合も、それがコンプライアンス上のリスクとなり得ます。
これらの報告期限には時間的な余裕がほとんどありませんが、それは規制当局が意味もなく過度に厳しい要求をしているのではありません。これは、実際のデータでも裏付けられているように、攻撃のスピードが高まっている現実を反映したものです。2018年の時点では、脆弱性が見つかってから実際に悪用されるまでの平均期間は約2年でした。2026年現在、この期間は20時間にまで短縮しており、2028年には1分になるとの予測もあります。EU CRAの報告義務の枠組みはこの現実を踏まえて設定されたものであり、組織の運用プロセスもこれに合わせることが求められます。
24時間の報告義務を確実に満たすには自動化が必要です。現在のソフトウェア・サプライチェーンにおけるCVE公開件数の多さに対応し、24時間の期限を確実に守り、新たに公開された脆弱性情報を自社の全製品群に照らし合わせて確認するのは、手作業によるワークフローでは不可能です。EU CRAの脆弱性報告を手作業によるプロセスで実行しようとしても、構造的に、作業の量とスピードの増大に対処できません。
必要なのは、以下の3つの機能要素を緊密に連携させた自動化アーキテクチャです。
外部への報告義務と並行して、外部からの報告の受け付けに関する義務もあります。EU CRA附属書Iの第2部では、製造業者が脆弱性報告の受け付けを目的とした単一の連絡窓口を設置することが義務付けられています。セキュリティ研究者、顧客、サプライチェーン上のパートナーなど、自社製品に脆弱性を発見した関係者が、その脆弱性を報告できるアクセス可能な窓口を明記する必要があります。これは単なるベスト・プラクティスではなく法的な義務であり、2026年9月までに目立つ形で表示し、運用可能な状態にしていなければなりません。
法律上、製造業者は脆弱性の報告を受け取ってから一定の合理的な期間内に対処できる能力を備えていることが求められます。つまり、単一の連絡窓口とは単なる開示フォームやメール・アドレスでは不十分で、プロセスでなければなりません。つまり、誰かがその窓口に責任を持って監視し、受け取った報告をトリアージし、しかるべき報告に対しては定義済みの対応手順を開始する必要があります。そのプロセス、すなわち責任者、エスカレーション・パス、対応SLAを文書化したものは、SBOMの文書等やセキュリティ・テスト報告書と併せてEU CRAのコンプライアンス記録の一部となります。
これは、EU CRAの要求事項の中で最も影響の大きいものの1つであり、運用面でも慎重な対応を迫られます。製造業者は、EU市場に上市するすべての製品について自らサポート期間を定義して宣言し、これを遵守する必要があります。この宣言したサポート期間中は、EU CRAのすべての脆弱性対応義務が全面的に適用されます。なお、EU CRAの3つの水平規格（複数の製品カテゴリーに横串で適用される規格）のうち2つでラポーター（取りまとめ役）を務めるAngelo D’Amato氏によると、その重大性は明らかです。「サポート期間中は、脆弱性を修正する必要があります。サポート期間中に脆弱性を修正しない場合、罰金を科されるか、製品がリコールされます（リコールには自主的に行われる場合と、当局がリコールを発令する場合がある）」。
EU CRAでは、適切なサポート期間の決定について、製造業者に意図的に柔軟性を与えています。とはいえ、製造業者が何の制約もなしに自由に決定できるわけではありません。「コンポーネントによっては、何が合理的なサポート期間なのかについての事前知識を誰も持ち合わせていないことがあります」とD’Amato氏は認めています。「その分析は、製造業者が行います。ただし、市場監視当局が最新の技術水準に照らし合わせて各社製品を比較し、不一致がないかをチェックします」。
ここで重要な原則となるのが、想定される用途との整合性です。予想されるライフサイクルが3～5年の消費者向けIoT機器の場合、それに応じたサポート期間が要求されます。これに対し、重要インフラで使用され、15年間の稼働が予想される産業制御システムの場合は、まったく異なるサポート期間が求められます。サポート期間は、自社の製品ロードマップの都合で決めるのではなく、その製品が市場で実際にどのように使用されるかを考慮して、適切に決定する必要があります。
実務上の指針としては、まず自社製品の想定されるユースケースを分析し、その市場セグメントの同等製品を調査した上で、最新の技術水準で期待されるサポート期間を把握します。そして具体的な分析結果を文書化し、実際に遵守できるサポート期間を宣言するようにします。判断内容そのものと同じくらいに重要なのが、文書化の規律です。「特定の市場や業界でのサポート期間といったパラメーターを定義する際には、デューデリジェンスを実施してその内容を文書化する必要があります」とD’Amato氏は述べています。根拠を文書化しておけば、市場監視当局が自社の判断に異議を唱えた場合の防御となります。
既に積極的な開発は行われていないものの、まだサポート期間中にある製品は、メンテナンス・モードであると見なされます。開発への投資が減少していても、コンプライアンスの義務が軽減されるわけではありません。脆弱性管理の義務は、宣言したサポート期間が終了するまでは全面的に有効なままです。そのことを念頭に、メンテナンス・モードの運用予算を確保する必要があります。
EU CRAでは、宣言したサポート期間の終了前と後では明確な違いが定義されています。宣言したサポート期間が終了した後も、製造業者は製品のメンテナンスやサポートを任意継続できますが、新たに発見された脆弱性を修正する法的義務はなくなります。
この規制体系は、製品群の管理に戦略的な影響を与えます。製品がサポート終了ステータスになるか、間もなくサポート終了ステータスになる場合は、明確なライフサイクル通知を顧客に伝える必要があります。これにより、顧客は製品の継続利用、アップグレード・スケジュール、およびリスクの受容について情報に基づいた判断を下すことができます。サポート期間の終了を宣言しておけば、今後は継続的な保護を前提にできないことを顧客は理解できます。これは透明性に関する義務であり、その通知は最初の宣言と同じくらい慎重に行う必要があります。
EU CRAでは、まったく新しい脆弱性修正義務が導入されます。自社製品が依存している上流のオープンソース・コンポーネントに脆弱性を発見した製造業者は、これらのオープンソース・コミュニティと協力して上流での脆弱性修正に取り組むことが求められます。
「第13条では、上流のオープンソースに脆弱性が見つかった場合、[製造業者も]協力して修正に当たることが義務の1つとなっています」とD’Amato氏は述べています。「これにより、オープンソース[・プロジェクト]と製造業者の間にパートナーシップが生まれます」。つまり、自社製品の脆弱性にパッチを適用したら終わり、というのではなく、修正を貢献し、プロジェクトの開示プロセスを通じて問題を報告し、コミュニティ・レベルでの修正に参加するなど、上流プロジェクトに積極的に関与することが求められます
現在、ほとんどの製造業者はオープンソースを受け身の姿勢で使用しています。自社で必要なコンポーネントを特定して組み込み、既知の脆弱性を監視して、修正が利用可能になると自社製品にパッチを適用します。EU CRA第13条では、こうした受動的な利用者から積極的な参加者への転換が強制されます。自社がどのオープンソース・コンポーネントに依存しているかだけでなく、それらを誰が保守しているのか、その開示および貢献プロセスはどうなっているのか、そして報告すべき脆弱性や貢献すべき修正がある場合の効果的な関与方法についても理解しておく必要があります。
「組織は、自社が依存しているオープンソースについて、本当の意味で十分に理解する必要があります」とD’Amato氏は述べています。「何か問題が見つかったら、誰と協力すべきなのかを知っておくことが必要です」。
ここでは、非対称性が重要な意味を持ちます。上流のオープンソース・メンテナーは、自分たちのコンポーネントがどの組織でどのように使用されているかを把握していません。脆弱性が自社製品および顧客に与える影響について完全な文脈を持っているのは、製造業者の側です。このため、第13条では、協力作業を開始する義務を悪用可能な状態を発見した製造業者の側に置いています。
第13条の義務を満たすには、単なる脆弱性スキャンを超えた運用基盤が必要です。重要なオープンソースの個々の依存関係について、上流のオープンソース・プロジェクトの健全性、ガバナンス、そして貢献プロセスを明確に理解する必要があります。そして上流への脆弱性開示を開始し、そのプロセスを通じて自社の貢献を調整するための内部ワークフローを定義する必要があります。そして、仮に市場監視当局からの精査を受けることになった場合にコンプライアンスを実証できるような形で、協力活動を文書化する必要があります。
これは、自社が依存するオープンソース・コミュニティに対して、脆弱性が表面化した時の事後対処的な関与ではなく、積極的な関与を促す具体的な契機となります。製造業者が、自社の依存している重要なオープンソース・プロジェクトのメンテナーと事前に関係を築いていれば、脆弱性対応の時になって初めてメンテナーの名前やプロセスを調べるよりも、第13条の義務が発生した場合の対応は根本的に有利になります。
EU CRAの脆弱性報告義務、サポート期間の要件、そして第13条の協力義務は、どれ1つをとっても運用面で相当な投資を必要とします。しかしこれら全体を組み合わせることにより、継続的に動作してあらゆるものを文書化し、依存関係を離れた場所から監視するのではなく、オープンソース・エコシステムをパートナーとして扱うような、EU CRA遵守のための成熟した脆弱性管理プログラムの形が定義されます。
必要な統合アーキテクチャには、以下のものが含まれます。
2026年9月の報告義務の開始日は目前に迫っています。その日に運用しているインフラこそが、EU市場に出荷した製品に最初の悪用可能な脆弱性が表面化した時に使用するインフラとなります。これは仮定の話ではなく、実際のソフトウェア・サプライチェーンでは、近い将来ほぼ確実に起きることです。
今すぐ取り組むべき優先事項は、以下のとおりです。
製造業者がEU CRAの要求事項を大規模な環境で迅速に満たすには、これらの義務を「期限までに一通り満たせばよいコンプライアンス上のチェックリスト」としてではなく、「運用基盤への投資」と捉えることが重要です。脆弱性が見つかってから数カ月後ではなく数時間後に悪用が開始される世界では、もはやセキュリティを後付けで考えることはできません。今ここで構築する報告基盤こそが、明日のEU市場で自社の競争優位を決定付ける差別化要因となります。