海外ITニュース

悪用された脆弱性を知ってから24時間。EU CRAの報告義務は、もう動いている

EU Cyber Resilience Act（CRA）は「2027年の話」として語られがちです。それは半分だけ正しい。実体的な製品要件は確かに2027年12月からですが、報告義務はすでに2026年9月11日から動いています。そして適用の判定にメーカーの設立地は含まれません。EU市場に製品を出している日本の開発者にとって、これは現在進行形の義務です。

いつ何が効くのか

まず日付を押さえます。

• EU官報掲載／OJ L 2024/2847、2024年11月20日
• 発効／2024年12月10日
• 第4章（適合性評価機関の通知）適用／2026年6月11日
• 第14条（報告義務）適用／2026年9月11日
• 全面適用／2027年12月11日

つまりいま効いているのは報告義務だけで、Annex Iの必須要件、技術文書、CEマーキング、適合宣言、サポート期間は2027年12月11日まで適用されません。「2026年9月からCRAが始まった」という言い方は、この区別を潰してしまいます。

報告を受け付けるENISAの単一報告プラットフォーム（SRP）も、2026年9月11日の稼働を目標として整備されてきました。

24時間・72時間・14日

第14条が求める報告の対象は2つ。積極的に悪用されている脆弱性と、製品のセキュリティに影響する重大インシデントです。報告先は、調整役に指定されたCSIRTとENISAに同時に。

• 悪用されている脆弱性／認識から24時間以内に早期警告／72時間以内に通知／是正・緩和措置が利用可能になってから14日以内に最終報告
• 重大インシデント／認識から24時間以内に早期警告／72時間以内に通知／初回通知から1か月以内に最終報告

EU内に主たる事業所がない場合の報告先は、①認定代理人の所在加盟国 → ②輸入者 → ③販売者 → ④ユーザーが最も多い加盟国、の順で最初に該当する国のCSIRTです。この規定が置かれていること自体が、EU域外のメーカーも第14条の対象であることを前提にしています。

実務で効くのは「認識（becoming aware）」の起点です。欧州委員会のガイダンスは、実施規則(EU)2024/2690のrecital 31およびEDPB Guidelines 9/2022と整合的に読むべきとしています。24時間という時計が、誰のどの判断から回り始めるのか——ここを社内で定義していないと、期限の管理ができません。

2027年に来るもの

全面適用で効いてくる義務のうち、エンジニアに直接関係する主なものです。

• SBOM／Annex I Part II 点(1)。製品に含まれる脆弱性とコンポーネントを特定・文書化し、少なくともトップレベルの依存関係をカバーする機械可読形式のSBOMを作成する。市場監視当局は依存関係評価のためSBOMの提出を求めうる
• サポート期間／第13条8項。最低5年。製品の想定使用期間が5年未満の場合はその期間。期間設定の根拠を技術文書に記録
• アップデートの提供可能期間／最低10年、またはサポート期間の残りのいずれか長い方
• CEマーキング／EU適合宣言書を作成し、CEマーキングを貼付。記録は最低10年またはサポート期間のいずれか長い方で保持
• CVDポリシー／協調的脆弱性開示ポリシーの策定・運用。連絡先アドレスの提供を含む
• 修正済み脆弱性の公開／説明・影響製品・影響・深刻度・修正方法。正当な場合は公開延期可

製品分類によって適合性評価のルートが変わる点も実装に影響します。重要製品Class II（ハイパーバイザ、コンテナランタイム、TPM、産業用ファイアウォール／IDS／IPS、リモートアクセスソフトなど）は自己評価（Module A）が使えず、ノーティファイドボディの関与が必要になります。

オープンソースはどう扱われるか

ここは誤解が多い領域です。欧州委員会の公式説明と条文から整理します。

• 対象／「市場で入手可能にされた」FOSSのみ。メーカーが収益化していないFOSSは商業活動とみなされない
• コントリビュータ／自らの責任下にないFOSSにソースコードを寄与する開発者には適用されない
• 責任主体／開発・リリース・配布をコントロールするメンテナ。そのコントロールを持たない者は責任主体でない
• スチュワード／メーカー以外で、商業活動を目的とした特定のOSS製品の開発を体系的に支援する法人。文書化されたサイバーセキュリティポリシーの策定、当局への協力などの義務を負う
• 制裁金／第64条10項により、オープンソースソフトウェアスチュワードは本規則のいかなる違反についても制裁金の対象外

委員会ガイダンスの解釈では、無償版・コミュニティ版は原則として市場に置かれたとみなされず、別途購入可能なサポートがあっても該当しない。無償版と有償版の両方を提供する法人は、無償版についてスチュワード義務を負う。無償版のみを提供する自然人（個人開発者）は、そもそもCRAの対象外です。

寄付リンクの存在だけでは営利目的の証拠になりませんが、寄付が事実上の価格と同等であれば商業活動として扱われうる、とも整理されています。

制裁金

• Annex Iの必須要件、第13条・第14条の不遵守／15,000,000ユーロ、または前会計年度の全世界年間総売上高の2.5%のいずれか高い方
• 第18〜23条、第28条ほかの不遵守／10,000,000ユーロ、または全世界年間売上高の2%のいずれか高い方
• 当局への不正確・不完全・誤解を招く情報の提供／5,000,000ユーロ、または全世界年間売上高の1%のいずれか高い方

24時間の早期警告の期限を徒過したマイクロ企業・小企業は、第64条10項により制裁金の適用除外とされています。

日本の開発者が対象になる条件

CRAには「域外適用」という表題の条文はありません。適用はEU製品法に共通の接続点——EU市場に置かれたかどうか——で決まります。

• 第2条1項／「市場で入手可能にされた」デジタル要素を持つ製品に適用
• 第3条21号／placing on the market＝EU市場での最初の入手可能化
• 第3条22号／making available on the market＝EU市場での流通または使用のための供給

メーカーの設立地は要件に入っていません。日本法人でも個人開発者でも、EU向けに有償で供給していれば対象です。

GDPRと混同されやすい点を1つ。認定代理人（第18条）の選任は任意です。条文は「may」であり、非EUメーカーに選任義務を課す規定はこの条にはありません。ただし代理人を置かない場合、技術文書の提供や当局対応は輸入者・販売者の側に流れ、契約条件として跳ね返ってきます。

SBOMは、何を出せば満たしたことになるのか

SBOMは「出す」こと自体より、どこまでの深さで、どの項目を含めるかが論点です。EUと米国で要求が違い、しかも両方が2026年に動きました。

EU CRA（Annex I Part II 点(1)）

• 要求／製品に含まれる脆弱性とコンポーネントを特定・文書化し、少なくともトップレベルの依存関係をカバーする機械可読形式のSBOMを作成する
• 提出先／原則として公開義務ではない。市場監視当局が依存関係評価のために提出を求めうる

CISA 2026 Minimum Elements（2026年7月29日公表）

• 公表主体／CISA、NSA、FBIおよび国際パートナー。15の国際サイバーセキュリティ機関が参加
• 位置づけ／2021年のNTIAベースライン（7フィールド）以来初の全面改訂。要求データ項目は約2倍
• 新規要求／Component Hash、License、SBOM Tool Name、SBOM Generation Context ほか
• 追加されたメタデータ／SBOM Author Signature、Data Format Name、Data Format Version、Generation Context、Tool Name、Tool Version、SBOM Version
• コンポーネント側／Component Hash Value、Component Hash Algorithm、Component License
• 深さ／推移的依存関係を深さ制限なしで要求
• 廃止・削除／Access Control要素を削除、SWIDタグを廃止
• フォーマット／SPDXとCycloneDX（いずれもEcma標準）

ここで差が出ます。EUはトップレベル以上、CISAは推移的依存関係を深さ制限なし。同じ製品で両方を満たそうとすると、実質的にCISA側に合わせることになります。

実装上の含意は明快です。

1. ビルド時に生成する。後からスキャンして作ると、実際にリンクされたものと一致しない
2. ハッシュとライセンスを取れる仕組みにしておく。2026年版で新たに必須級になった項目
3. 生成ツールとそのバージョンを記録する。メタデータとして要求されている
4. SPDXかCycloneDXで出す。独自形式は選択肢にならない

必須フィールドの総数、および採用期限は公開情報では確認できませんでした。CISAの告知は「baseline」「should include」という表現で、強制力の有無を明記していません。

米国は逆方向に動いている

同じ時期、米国の政策は規制緩和の方向です。

• 大統領令14028／撤回されていない。2025年6月のEO 14306も14028を撤回していない。ただしEO 14144のうちSSDF自己認証のFAR改正を指示していた部分は削除
• OMB M-26-05（2026年1月23日）／M-22-18・M-23-16が課していたソフトウェア提供者の自己認証（attestation）要件を撤回。SBOMは「省庁が契約条件として要請に応じた提供を求めうる」任意のものに
• CISA 2026 Minimum Elements for SBOM（2026年7月29日）／CISA・NSA・FBIほか国際パートナーが公表。Component Hash、License、SBOM Tool Name、Generation Contextなどを新規要求。2021年のNTIAベースライン以来初の全面改訂で、要求項目は約2倍

法的義務は緩み、技術標準は精緻化する——この逆方向の同時進行が2026年の米国の特徴です。EUが義務として迫るのに対し、米国は調達条件として降りてくる。開発側から見れば、やることは結局同じ方向に収束します。

いま手を付けるなら

1. EU向けに何を出しているかの棚卸し。有償か無償か、誰が配布をコントロールしているかで扱いが変わる
2. 「認識」の定義を社内で決める。24時間の時計が回り始める起点を、誰のどの判断とするか。決めていなければ期限は管理できない
3. SBOMの生成を、2027年を待たずにCIに入れる。EUは機械可読形式でトップレベル依存関係以上、CISAは2026年版でさらに項目を増やしている。後から足すより、最初から出力しておくほうが安い
4. 自社製品の分類を確認する。ハイパーバイザやコンテナランタイム、リモートアクセスソフトは自己評価が使えないClass II。評価のリードタイムが調達計画に効く

出典

• 欧州委員会／Cyber Resilience Act implementation factpage（2026年7月27日更新）／施行スケジュール、各マイルストーン
• 欧州委員会／CRA and open source（2026年7月31日更新）／オープンソースの扱い
• 規則(EU)2024/2847／OJ L 2024/2847（2024年11月20日掲載）／第2条、第3条、第13条、第14条、第18条、第24条、第64条、第71条、Annex I
• ENISA／Single Reporting Platform（SRP）／報告先と期限
• Orrick／EU Cyber Resilience Act: New Guidance Clarifies Scope, Reporting（2026年9月）／委員会ガイダンスの内容
• Covington（Inside Government Contracts）／OMB Rescinds the Common Form Secure Software Attestation Requirement（2026年2月）
• CISA／2026 Minimum Elements for a Software Bill of Materials (SBOM)（2026年7月29日）

本記事は2026年10月27日時点で公開されている情報に基づいています。条文の逐語解釈については原典（EUR-Lex、CELEX: 32024R2847）をご確認ください。ENISAの単一報告プラットフォームが実際に稼働を開始した旨のENISA公式による確認は取れていません。オープンソースソフトウェアスチュワードの定義の条番号は、参照元によって表記が分かれています。