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

2026.08.12 JFrog記事

Japanese poster about using JFrog Platform for compliant releases, with a white right-side infographic titled Software Lifecycle & Evidence Collection over a dark blue background. (Informative)

本対策の詳細について、お問い合わせフォームもしくは本書作者Alex Wang(王　子龍) wanga@jfrog.comへお気軽に問い合わせいただけたら幸いです。（日本語、英語の両方に対応）

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

「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）を伴うリリース」をどう仕組みとして作るのかを解説します。

目次非表示

はじめに：2027年12月11日、CEマークのない製品はEU市場から消える
1. CRAとは何か — 施行スケジュールを正しく押さえる
2. 自社製品はどのクラスに入るのか
3. 適合性評価モジュール A / B / C / H
4. CRAが求める4つのキーポイント
5. 報告義務のタイムライン — そして「脆弱性の判断に固定値はない」
6. CRA対応は「ドキュメント作業」では終わらない
7. JFrog Platform でどう対応するか
8. 今日から始める3つのステップ
まとめ
この記事の著者について

1. 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か月を要します。指定が始まってから駆け込むと、確実に間に合いません。

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

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以上の製品を持つ企業は、整合規格を完全に適用できるかどうかが自己評価ルートに残れるかの分岐点になります。ここは早めに規格側の動きを追う価値があります。

3. 適合性評価モジュール 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対応をツールで解く価値が最も大きい部分です。

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

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

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

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

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

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

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対応の実務では、「その脆弱性が自社製品の文脈で実際に到達可能／悪用可能か」を判定できる仕組みが前提条件になります。

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

CRAの要件を、ソフトウェアサプライチェーンの工程（Design → Create → Package → Promote → Distribute → Deploy → Run）にマッピングすると、要件が全工程に散らばっていることがわかります。

Design — サイバーセキュリティリスク評価、Security by 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時間の通知）

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

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

7. JFrog Platform でどう対応するか

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

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

7-1. 入口を固める — JFrog Curation / Catalog / IDEプラグイン

満たす要件：Security by Design（Annex I）、サードパーティコンポーネントのデューデリジェンス

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

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

7-2. 検出と証明を自動化する — JFrog Xray / Advanced Security / Runtime

満たす要件：SBOM（Annex VII）、脆弱性の検出・修正、報告義務のSLA遵守

自動化された 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が求めるサポート期間中の継続的な脆弱性対応は、ランタイムの可視性なしには成立しません。

7-3. 証跡でリリースを裏づける — JFrog AppTrust

満たす要件：適合宣言の根拠、技術文書の完全性、10年間の監査対応、Module H的な継続的ガバナンス

CRA対応で最後に残る、そして最も厄介な課題が「証明」です。「セキュアに作りました」と主張することと、当局や通知機関に対して監査可能な形で証明することの間には、深い溝があります。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 の「品質管理システム全体の審査と、新製品追加時の再評価」に耐えるのは、こうしたコード化されたプロセスです。

7-4. AppTrust が実現する「Application Risk Governance」

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

信頼はこう作られます。

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

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

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

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

ステップ1：製品分類の確定（今すぐ）

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

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

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

ステップ3：証跡の自動化（2027年12月11日に向けて）

技術文書、SBOM、リスク評価、テスト結果、例外管理、定期レビュー——CRAが求める成果物は多岐にわたりますが、これらを人手で集めていては、リリースごとに破綻します。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対応の進め方について具体的なご相談は、お気軽にお問い合わせください。

参考：EUサイバーレジリエンス法（CRA）とは