CRA (EU サイバー レジリエンス法) 対応をどう乗り切るか ～ JFrog Platform で「証跡付きリリース」を仕組みにする

はじめに: 2027 年 12 月 11 日、CE マークのない製品は EU 市場から消える

本対策の詳細について、エクセルソフトもしくは本書作者 Alex Wang (王 子龍) へお気軽に問い合わせください (日本語、英語の両方に対応)。

「EU サイバー レジリエンス法 (EU Cyber Resilience Act、(以下、CRA))」という言葉を、ここ 1 年で何度も耳にされたのではないでしょうか。GDPR のときと同じように、「EU の規制だから自社には関係ない」と考えたくなる方もいるかもしれません。しかし CRA は、デジタル要素を含む製品を EU 市場に出荷するすべての製造者を対象とします。これは組込み機器、産業機械、コネクテッド家電、業務アプリケーションなどの製品/システムに加え、それらに搭載/利用されるソフトウェアも含まれます。日本のメーカーやソフトウェア ベンダーにとって、これは「他人事」ではありません。

そして最も重要なのはここです。CRA は、対象製品の準拠状況を CE マークに統合して管理します。つまり、CE マークを取得できない製品は、2027 年 12 月 11 日以降、EU 市場で販売できなくなります。セキュリティ対応が「やったほうがよいこと」から「売るための必須条件」に変わる、というのが CRA の本質です。

背景には、3 つの力の衝突があります。

• スピードの要求: リリース速度への圧力が、ソフトウェア サプライ チェーンを複雑化させ、攻撃対象領域 (アタック サーフェス) を急拡大させました。
• 新たな脅威の最前線: ソフトウェア サプライ チェーン攻撃は、近年で 3 倍規模に増加したと報告されています。
• 規制による義務化: CRA や NIST SSDF といった規制が、責任の所在を「利用者」から「製造者」へと移し、製品ライフサイクル全体にわたる監査可能なセキュリティの証明を要求しはじめました。

本記事では、CRA が具体的に何を求めているのかを整理し、そのうえで JFrog Platform を使って「証跡 (Evidence) を伴うリリース」をどう仕組みとして作るのかを解説します。

CRA とは何か: 施行スケジュールを正しく押さえる

CRA は、デジタル要素を含む製品の消費者を保護し、製品のサイバー セキュリティ確保を製造者に義務付ける欧州の規制です。ガイドラインではなく、法的拘束力を持つ規制 (Regulation) である点が重要です。

施行スケジュールは次のように段階的です。

時期	内容
2024 年 10 月 10 日	法案成立
2024 年 12 月 10 日	EU 官報掲載を経て発効
2026 年 9 月 11 日	脆弱性、インシデントの報告義務に関する部分が適用開始
2027 年 12 月 11 日	CRA が全面適用。CE マーク未取得の製品は EU 市場で販売不可

注目すべきは、報告義務が先に来ることです。2026 年 9 月 11 日以降、「悪用されている脆弱性を把握してから 24 時間以内に当局へ通知する」といった運用が現実に求められます。全面適用の 2027 年 12 月を目標に据えると、報告義務のフェーズを取りこぼします。

そしてもう一つ、実務上の重大なポイントがあります。適合性評価を担う通知機関 (Notified Body) が、本記事執筆時点でまだ一つも指定されていません。通知当局 (notifying authorities) は評価機関の評価、指定、通知に必要な手続を整備、公表する義務を負っていますが、現状として第三者評価が必要な製品カテゴリの製造者は、評価してくれる相手がまだ決まっていない状態で準備を進めることになります。後述するように第三者評価は通常 3 〜 12 か月を要します。指定が始まってから駆け込むと、確実に間に合いません。

自社製品はどのクラスに入るのか

CRA は製品を 4 つの区分に分け、区分ごとに適合性評価の厳しさを変えています。まず自社製品がどこに位置するかを確定させないと、必要な準備量が見積もれません。

区分 (Tier)	定義	例	適合性評価
デフォルト (Default) 製品の約 90%	附属書 (Annex) IIIまたは IV に記載されていない、デジタル要素を含むすべての製品	スマート TV、一般消費者向け IoT 機器、基本アプリ、コネクテッド家電	自己評価 (モジュールA): 製造者が EU 適合宣言書に署名し CE マークを表示。通知機関は不要
重要: クラス I (Annex III パート I)	サイバー セキュリティに不可欠な機能を果たす製品、または侵害された場合に重大な障害リスクをもたらす製品。分類は組込みコンポーネントではなくコア機能に基づく	ID 管理/PAM システム、パスワード マネージャー、Web ブラウザー、スマートホーム セキュリティ製品 (スマート ロック、カメラ、アラーム)、VPN、ルーター、ネットワーク スイッチ、OS (汎用以外)、SIEM	整合規格を完全に適用していれば自己評価 (モジュール A)。それ以外は第三者の通知機関が必要。整合規格を順守する製造者は適合の推定を得られる
重要: クラス II (Annex III パート II)	侵害された場合に重大な影響や連鎖的な影響を及ぼしうる高リスク製品。規格の適用有無に関わらず第三者評価が必須	ハイパーバイザー、コンテナー ランタイム、産業用ファイアウォール、IDS/IPS、耐タンパー性マイクロ プロセッサ、産業用自動化/制御システム	第三者の通知機関が必須（モジュール B+C または モジュール H）。自己評価ルートは利用不可。評価期間は通常 3 〜 12 か月
クリティカル (Critical) (Annex IV)	EU の重要インフラが依存しうる最高リスク製品、またはその不具合がクリティカルなサプライ チェーンを混乱させうる製品	HSM (ハードウェア セキュリティ モジュール)、スマートメーター ゲートウェイ、スマートカード/セキュア エレメント、セキュア クリプト プロセッサ	「実質的 (substantial)」保証レベル以上の欧州サイバーセキュリティ認証 (EUCC)。※欧州委員会がスキームを義務付けるまではクラス II と同じルート (B+C または H)

実務的な示唆は 2 点です。

第一に、製品の約 90% はデフォルト区分、つまり自己評価で対応できます。ここで求められるのは第三者監査ではなく、「附属書 I (Annex I) の必須要件を満たしていることを自分で示せる技術文書と SBOM、リスク評価、そして署名された適合宣言書」です。裏を返せば、文書と証跡を出せるかどうかがすべてということになります。

第二に、クラス I 以上の製品を持つ企業は、整合規格を完全に適用できるかどうかが自己評価ルートに残れるかの分岐点になります。ここは早めに規格側の動きを追う価値があります。

適合性評価モジュール A / B / C / H

区分が決まると、次は「どのモジュールで評価を受けるか」です。

モジュール	内容
Module A: Internal production control (内部生産管理)	自己適合宣言のみ。製造者は附属書 I (Annex I) の必須要件への適合性を独立して評価し、技術文書 (附属書 VII) を作成し、SBOM を準備し、サイバーセキュリティ リスク評価を実施し、EU 適合宣言書に署名して CE マークを表示する
Module B: EU type examination (EU 型式審査)	通知機関が設計を評価。製品の技術設計および脆弱性対応プロセスを附属書Iの要件に照らして審査し、EU 型式審査証明書を発行。製造段階については常にモジュール C と組み合わせて適用される
Module C: Conformity to type (型式への適合)	製造者主導の生産管理。量産されるすべてのユニットがモジュール B で承認された型式に適合していることを保証し、技術ファイルおよび適合宣言書 (DoC) を維持、管理する
Module H: Full quality assurance (完全品質保証)	通知機関が品質管理システム全体を審査 (設計、開発、製造、脆弱性対応を網羅)。新しい製品を追加する場合は同じ機関による更新文書の提出と再評価が必要。クラス II、クリティカル製品における B+C の代替手段

Module H に注目してください。「品質管理システム全体を審査し、新製品追加のたびに再評価が必要」という要件は、プロセスが人手と属人的な運用に依存していると成立しないことを意味します。逆に、パイプラインとポリシーがコード化され、証跡が自動的に残る仕組みができていれば、H は繰り返し可能な運用になります。ここが、CRA 対応をツールで解く価値が最も大きい部分です。

CRA が求める 4 つのキー ポイント

法文は膨大ですが、製造者の義務は次の 4 点に集約できます。

1. 安全な設計 (Security by Design): 最初からセキュリティを考慮して製品を作る。
2. 部品表の作成 (SBOM): 使うソフトウェアの構成を管理する。
3. 脆弱性の修正: 売った後もアップデートや修正を続ける。
4. 報告の義務: 問題が起きたら 24 時間以内に当局へ知らせる。

さらに、これらを裏づける保管義務があります。技術文書と適合宣言書は 10 年間保持し、当局に提示できる状態を保つ必要があります。また、サポート期間中は無償のセキュリティ アップデートを提供し、リリースごとに最低 5 年間の脆弱性追跡を継続することが求められます。

「一度リリースして終わり」ではなく、リリースしたすべてのバージョンについて、数年単位で構成情報と脆弱性状況を答えられる状態を維持する、これが CRA の実質的な要求です。手作業の Excel 台帳では破綻します。

報告義務のタイムライン: そして「脆弱性の判断に固定値はない」

2026 年 9 月 11 日から適用される報告義務は、次の 3 段階です。

段階	報告期限	報告内容
早期警告通知	製造者が認識後 24 時間以内	当該デジタル製品が供給されたと製造者が認識している EU 加盟国 (提示可能な場合)
脆弱性通知	製造者が認識後 72 時間以内	当該デジタル製品の一般的情報、悪用手段や脆弱性の性質、実施した是正措置/緩和措置、ユーザーが利用できる是正措置緩和措置、通知する情報を製造者がどの程度機密性があると考えるか (提示可能な場合)
最終報告	是正措置、緩和措置が利用可能になった後 14 日以内	重大性と影響を含む脆弱性の説明、脆弱性を悪用した/悪用している悪意ある行為者に関する情報 (可能な場合)/脆弱性を修正するためのセキュリティ更新プログラムまたはその他の修正措置の詳細

補足: 上表は「積極的に悪用されている脆弱性」に対するトラックです。重大なインシデントについても 24 時間の早期警告と 72 時間の通知が求められ、最終報告の期限はインシデント側では 1 か月とされています。自社のどの事象がどちらのトラックに乗るのかは、報告フローを設計する段階で整理しておくべきポイントです。

ここで、多くの現場が見落とす重要な論点があります。脆弱性について、一律の固定値 (しきい値) はありません。

CRA の要件では、CVE の有無や CVSS スコアの確認だけでは足りません。実際に悪用可能か (exploitable)、積極的に悪用されているか (actively exploited) という実態ベースの判断が求められ、近年は SSVC (Stakeholder-Specific Vulnerability Categorization) への移行も注目されています。

これは運用への直撃です。「CVSS 7.0 以上を全部直す」という機械的なルールでは、報告すべき事象を取りこぼす一方で、悪用不可能な脆弱性の山に開発者の時間を溶かすことになります。CRA 対応の実務では、「その脆弱性が自社製品の文脈で実際に到達可能、悪用可能か」を判定できる仕組みが前提条件になります。

CRA 対応は「ドキュメント作業」では終わらない

CRA の要件を、ソフトウェア サプライ チェーンの各工程 (Design → Create → Package → Promote → Distribute → Deploy → Run) に当てはめてみると、その要件が特定の工程だけでなく、ライフサイクル全体にわたって求められていることがわかります。

• Design (設計): サイバーセキュリティ リスク評価、セキュリティ バイ デザイン要件 (Annex I) への対応、製品分類の確定 (Annex III、IV)
• Create (開発): セキュアな開発プラクティスの実施、脆弱性対応プロセスの確立、技術文書の作成開始 (Annex VII)
• Package (パッケージ化): SBOM の生成
• Promote (市場投入準備): 技術文書および DoC の確定、EU 適合宣言書への署名、CE マークの表示。クラス I 以上では、この段階で通知機関による型式審査 (Module B) や QMS 監査 (Module H) が関
• Distribute (流通、提供): 技術ファイルおよび関連文書の 10 年間保管、当局への SBOM 提供
• Deploy / Run (導入、運用): サポート期間中の無償セキュリティ アップデートの提供、脆弱性報告 (24 時間以内の早期警告/72 時間以内の正式通知)

つまり、CR A対応を「認証取得プロジェクト」として法務、品質保証部門に閉じ込めると、必ず失敗します。要件の大半は、日々の開発とリリースのパイプラインの中で満たされなければならないものです。

そして、そのパイプラインの中心にあるのは何でしょうか。ソースコードではありません。実際に出荷されるバイナリ (成果物) です。SBOM が記述する対象も、脆弱性を追跡する対象も、10 年間保管する証跡が指し示す対象も、すべて「あのとき出荷したあのバイナリ」です。ここが、JFrog Platform が CRA 対応の基盤として機能する理由です。

JFrog Platform でどう対応するか

JFrog Platform は、Artifactory を Single Source of Truth (単一の信頼できる情報源) として、各言語のパッケージ、バイナリ、コンテナー イメージ、そして AI モデルまでをメタデータ付きで一元管理します。外部の OSS リポジトリをキャッシュし、CI/CD ツールをネイティブにサポートし、マルチクラウド/データセンター/IoT デバイスへの配布まで一本の流れで扱います。

このアーキテクチャの上に、CRA の要件を 3 つのレイヤーで実装していきます。

入口を固める: JFrog Curation / Catalog / IDE プラグイン

CRA は製造者に厳格な法的責任を負わせます。自社が書いていない OSS コンポーネントに起因する脆弱性であっても、製品として出荷した責任は製造者にあります。だからこそ、入口でブロックすることが最も費用対効果の高い対策になります。

• Secure by Design の強制: 不安全なパッケージや深刻な脆弱性を持つオープンソース パッケージが、ソフトウェア サプライ チェーンに進入する前に、入口で自動的にブロックします。「取り込んでから直す」のではなく「取り込ませない」ため、後工程の手戻りが消えます。
• サードパーティのデューデリジェンス: サードパーティ製コンポーネントが製品のサイバーセキュリティを侵害しないことを保証する「クリーンなパイプライン」環境を構築し、CRAの厳格な責任リスクを軽減します。
• シフトレフトによる解決: IDE プラグインにより、開発者が自席で直接脆弱性を特定、解決できます。リリース速度を落とさずに継続的なコンプライアンスを維持できる点が、規制対応を「開発の足かせ」にしないための鍵になります。

検出と証明を自動化する: JFrog Xray / Advanced Security / Runtime

• 自動化された SBOM & VEX: VEX (Vulnerability Exploitability eXchange) データを付与した、マシンリーダブルな必須 SBOM を生成します。CRA の厳格な製品ドキュメント要件と、リリースごとに最低 5 年間の脆弱性追跡義務を、成果物単位で満たせます。SBOM を「リリース時に手作業で作る成果物」から「パイプラインの副産物」に変えることが、5 年、10 年の保持義務に耐える唯一の現実的な方法です。
• コンテキスト分析 (Contextual Analysis): 前述の「一律の固定値はない」という論点への直接的な答えです。実際に到達可能/悪用可能な CVE を特定することで、優先順位付けのパラドックスを解決します。さらに、CRAのENISA への報告期限 (24 時間の早期警戒/72 時間の詳細通知/最終報告) を守れるよう、自動アラートを提供します。報告義務が 2026 年 9 月に先行適用されることを踏まえれば、ここは最優先で整備すべき領域です。
• Secure by Design インフラ: Infrastructure-as-Code (IaC) を継続的にスキャンし、デプロイが CRA の「Security by Design」構成義務を満たしていることを保証します。
• Runtime: コンテナーの実行環境をスキャン/モニタリングし、「出荷後の世界」で新たに見つかった CVE を追跡します。CRA が求めるサポート期間中の継続的な脆弱性対応は、ランタイムの可視性なしには成立しません。

証跡でリリースを裏づける: JFrog AppTrust

CRA 対応で最後に残る、そして最も厄介な課題が「証明」です。「セキュアに作りました」と主張することと、当局や通知機関に対して監査可能な形で証明することの間には、深い溝があります。JFrog AppTrust は、法的根拠のある記録システム (System of Record) によって手動のボトルネックを排除し、CRA コンプライアンスと継続的なガバナンスを自動化します。

• リリース ライフサイクル管理: 不変 (イミュータブル) なアプリケーション バンドルを、定義されたステージ (DEV → QA → PROD) に従って物理的に移動させる構造化されたプロモーション フローを提供します。各ステージには Entry / Exit のゲートがあり、監査によって検証されたリリースのみが本番環境に到達します。「テスト済みのものとは違うバイナリが本番に出た」という事故が構造的に起こらなくなります。
• エビデンスの自動収集: セキュリティ、品質、パフォーマンス、リリースの証跡を単一の信頼できる情報源に統合し、バイナリに暗号学的に結合します。これにより、改ざん防止可能な保管チェーン (Chain of Custody) が確保されます。10 年後に「このバージョンの技術文書を見せてください」と言われたとき、当時のバイナリと証跡が結びついた状態で取り出せる、これが CRA の保持義務に対する答えです。
• Policy as Code (PaC): 複雑な CRA 規制を、実行可能な Open Policy Agent (OPA) コードに変換します。非準拠のソフトウェアを予防的にブロックする自動リリース ゲートを適用でき、規制の解釈をレビュー可能、テスト可能、バージョン管理可能な資産に変えられます。Module H の「品質管理システム全体の審査と、新製品追加時の再評価」に耐えるのは、こうしたコード化されたプロセスです。

JFrog AppTrust が実現する「Application Risk Governance」

AppTrust の位置づけをもう少し補足します。AppTrust は、証跡ベースの制御と文脈化されたインサイトによって、ソフトウェアのセキュリティを信頼し、コンプライアンスに準拠したリリースを推進するためのレイヤーです。GRC/コンプライアンス、リリース/エンジニアリング管理、DevOps、DevSecOps/AppSec という、CRA 対応で必ず衝突する複数の部門を、同じデータの上に載せます。

信頼はこう作られます。

1. 明確なアプリケーション エンティティと全体像: 「製品」という単位が、成果物/バージョン/依存関係とともに一意に定義される。
2. SDLC 全体を横断する戦略的ゲートとしての、証跡ベースのポリシー: 各ゲートの通過条件が証跡で裏づけられる。
3. 定義済みポリシーに準拠したアプリケーション バージョンに「Trusted」の印が付く: 適合宣言の根拠が機械的に確定する。
4. リリース後の新規 CVE モニタリングによる継続的な信頼の担保: 出荷後に発見された脆弱性が、24 時間/72 時間の報告フローに直結する。

CRA が求めているのは、まさにこの 4 点の運用化です。

今日から始める 3 つのステップ

期限まで逆算すると、着手すべき順序は明確です。

ステップ 1: 製品分類の確定 (今すぐ)

自社の EU 向け製品が、デフォルト/重要クラス I/重要クラス II/クリティカルのどこに入るかを確定させます。分類は組込みコンポーネントではなくコア機能に基づく点に注意してください。クラス II 以上が含まれる場合、第三者評価に 3 〜 12 か月かかり、かつ通知機関はまだ指定されていません。準備の開始時期が決定的に重要になります。

ステップ 2: 報告義務の体制整備 (2026 年 9 月 11 日に向けて)

全面適用より先に来るのが報告義務です。「悪用されている脆弱性を認識してから 24 時間」という時間制限に対して、自社製品のどのバージョンが EU のどの加盟国に供給されているかを即答できる状態が必要です。ここは、成果物と SBOM が一元管理されていなければ物理的に不可能です。JFrog Xray のコンテキスト分析と自動アラートで、検知から報告までの導線を先に作ってしまうのが最短ルートです。

ステップ3: 証跡の自動化 (2027 年 12 月 11 日に向けて)

技術文書、SBOM、リスク評価、テスト結果、例外管理、定期レビューなど、CRA が求める成果物は多岐にわたりますが、これらを人手で集めていては、リリースごとに破綻します。JFrog AppTrust のエビデンス自動収集と Policy as Code で、リリースすれば証跡が揃っている状態を作ります。これが、CE マークを継続的に維持するための土台になります。

まとめ

CRA は、セキュリティを「努力目標」から「市場アクセスの条件」に変えました。そして要求されているのは、セキュリティ製品を導入したという事実ではなく、製品ライフサイクル全体にわたる監査可能な証明です。

• 期限は 2 段階。2026 年 9 月 11 日に報告義務、2027 年 12 月 11 日に全面適用。
• 製品の約 90% は自己評価 (モジュール A) で対応可能。ただし技術文書と SBOM、リスク評価、署名された適合宣言書を出せることが前提。
• クラス II 以上は第三者評価が必須。通知機関はまだ未指定、評価には 3 〜 12 か月。
• 脆弱性判断に一律のしきい値はない。悪用可能性ベースの判断 (SSVC 等) が必要。
• 技術文書は 10 年保持、脆弱性追跡はリリースごとに最低 5 年。

JFrog Platform は、Curation で入口を固め、Xray、Advanced Security、Runtime で検出と SBOM/VEXの生成を自動化し、AppTrust で改ざん防止可能な証跡とポリシーゲートを提供します。CRA 対応を「監査の前に慌てて資料を集めるプロジェクト」から、「リリースするたびに証跡が積み上がる仕組み」へ。それが、期限に間に合わせるための最も現実的なアプローチです。

CRA 対応の進め方について具体的なご相談は、お気軽にお問い合わせください。

世界の人気ソフトウェアを提供するエクセルソフトのメールニュース登録はこちらから。

---

本記事は JFrog 社の許可を得て作成、公開しています。

参考: EU サイバー レジリエンス法 (CRA) とは