はじめに
新人君
おっさん、最近「CRA」ってよく聞くんですけど、うちに関係あるんですか？
ossan
EUで製品を売っているなら関係あるよ。EUの「サイバーレジリエンス法」のことで、2026年9月11日から報告義務がもう始まっている んだ。製品に組み込んだOSSの脆弱性でも、製品の中で悪用されたら報告の対象になるんだよ。
この記事では、組み込んだOSSに脆弱性が見つかったときに報告が必要かどうかの判断のしかたを中心に、OSSを使う開発者・作る開発者それぞれにCRAがどう関わるかを整理します。
結論：「悪用された脆弱性」は24時間以内に報告。土台はSBOM
- CRAの報告義務（第14条）は 2026年9月11日から適用 されている。そのほかの大部分の義務は2027年12月11日から
- 製品に「悪用されている脆弱性」が見つかったら、気づいてから24時間・72時間、修正策や緩和策が出てから14日 の3段階で報告する。製品の中で悪用されたら、組み込んだOSSの脆弱性も含まれる
- 「どの製品に、どのOSSが入っているか」を把握する SBOM（ソフトウェア部品表） が対応の土台になる
CRAとは？
CRA（Cyber Resilience Act、サイバーレジリエンス法）は、「デジタル要素を含む製品」、つまりソフトウェアやネットワークにつながる機器をEUの市場に出す事業者に、セキュリティへの責任を求めるEUの規則です。正式名は Regulation (EU) 2024/2847 で、2024年10月23日に採択されました。
たとえるなら、家電の「安全基準」のソフトウェア版です。売るときに安全なだけでなく、売ったあとに見つかった欠陥（脆弱性）にも対応し続けることを求めています。
EUの「規則（Regulation）」は、各国が国内法を作らなくても、そのままEU全体に適用されます。EUの外にある会社でも、EUの市場に製品を出していれば対象になります。
いつから始まる？
義務は段階的に始まります（第71条）。
| 日付 | 始まること |
|---|---|
| 2026年6月11日 | 適合性評価機関の通知（ノーティファイドボディの指定）に関する規定（第IV章、第35〜51条） |
| 2026年9月11日 | 製造者の報告義務（第14条） |
| 2027年12月11日 | そのほかの義務の全面適用（セキュリティ要件、SBOMの作成、OSSスチュワードの義務など） |
自分はどの立場？
CRAの義務は、立場によって大きく変わります。まず、自分がどこにあたるかを確かめましょう。
| 立場 | どんな人か | 報告義務 |
|---|---|---|
| 製造者 | 製品を開発し、自分の名前や商標でEUの市場に出す人や会社（第3条）。OSSを組み込んだ製品を売る会社はここに入る | あり（第14条）。2026年9月11日から |
| OSSスチュワード | 商業利用を想定したOSSの開発を、継続的に支えている法人（第3条） | 限られた範囲であり（第24条第3項）。2027年12月11日から |
| 商業活動にあたらない形でOSSを公開している個人 | 収益化せずにOSSを公開している個人など（法人の場合は、スチュワードにあたることがある） | なし |
ここからしばらくは、製造者の話をします。OSSを公開している人は、後半の「OSSを公開している人も対象？」を見てください。
組み込んだOSSの脆弱性、報告は必要？
脆弱性の報告が必要なのは、組み込んだOSSの脆弱性が 製品の中で悪用された ときです。脆弱性が公開されたというだけでは、報告の対象になりません。
ここからの説明は、欧州委員会のFAQとガイダンスにもとづいています。どちらも委員会の考え方を示したもので、法的拘束力はありません。
新人君
使っているライブラリにCVE（脆弱性の識別番号）が出たら、24時間以内に報告ですよね？
ossan
そこが勘違いしやすいところだよ。CVEが出ただけでは対象にならないんだ。報告するのは、製品の中で悪用された証拠があるときだよ。
判断は、次の3つの質問の順に進めます。
質問1：その製品はCRAの対象？
CRAの対象は、EUの市場に出している、機器やネットワークとのデータ接続が想定される「デジタル要素を含む製品」です（第2条第1項）。医療機器や車両など、適用除外の分野もあります（同第2〜7項）。ここで気をつけたいのが、すでに発売している製品です。
新人君
CRAの全面適用は2027年12月からなんですよね。それより前に売り始めた製品なら、関係ないですよね？
ossan
報告義務だけは違うんだ。CRAの対象になる製品なら、2027年12月11日より前に市場に出した製品にも報告義務がかかる よ。
2027年12月11日より前に出した製品にCRAがかかるのは、原則として、その日以降に大きな変更（substantial modification）を加えた場合だけです（第69条第2項）。報告義務はこの原則の例外で、発売済みの製品も対象です（同第3項）。ただし、求められるのは通知と利用者への周知で、脆弱性対応の義務まではかかりません（FAQ 5.3）。
質問2：そのOSSは製品に入っている？
脆弱性の情報が出たら、まず「そのOSSが自社のどの製品に入っているか」を調べます。ここで役立つのがSBOM（Software Bill of Materials、ソフトウェア部品表）です。食品の「原材料表示」のように、製品にどのライブラリのどのバージョンが入っているかを一覧にしたものです。
CRAは、附属書I 第II部 (1) で、製造者にSBOMの作成を求めています。
💡 CRAが求めるSBOM（附属書I 第II部 (1)）
- 一般的に使われている、機械が読める形式 で作る（たとえば SPDX や CycloneDX。条文に形式の名前はなく、欧州委員会が実施法で形式や項目を定められることになっている＝第13条第24項）
- 少なくともトップレベルの依存関係 を含める（条文に定義はないが、おおむね、製品が直接使っているライブラリと考えられる）
- 公開する義務はない（前文第77項）
SBOMの作成は報告義務とは違い、2027年12月11日から適用される要件です。ただ、報告義務に対応するためにも、今のうちから作っておくのが現実的です。
トップレベルの依存関係だけのSBOMでは、ライブラリが内部で使っている間接的な依存関係が一覧に出ないことがあります。間接的な依存関係の脆弱性も追いたいなら、そこまで含めて作っておくことになります。
ライセンス管理のために作っているOSSの一覧も、バージョンまで記録していれば脆弱性管理に使えます。scancode-toolkitでOSSのライセンスを調べる方法で紹介した ScanCode も、SPDX や CycloneDX の形式で結果を出力でき、依存関係の把握に役立ちます。
質問3：製品の中で悪用された、信頼できる証拠がある？
決め手は、脆弱性があることではなく、悪用された証拠があることです。第3条では、攻撃者がシステムの持ち主に無断で悪用したと信頼できる証拠で示せるものを、「悪用されている脆弱性（actively exploited vulnerability）」としています。
組み込んだOSSの脆弱性が自社の製品の中で悪用されたなら、製造者が報告します。部品に脆弱性があっても、ガイダンス上は、次の場合は報告義務の対象外とされています（ガイダンス 218）。
- ❌ 自社の製品では悪用できない（脆弱なコードに到達しないなど。FAQ 5.4 も同じ）
- ❌ 自社の製品では悪用されていない
また、善意の研究者が見つけた脆弱性で、悪用された証拠がないものも対象外です（FAQ 5.2）。ただし、製品のセキュリティに影響する重大インシデントにあたれば、別に報告が必要です（第14条第3項）。
⚠️ 報告義務の対象でなくても、何もしなくてよいわけではありません。2027年12月11日以降に市場に出す製品（または大きな変更を加えた製品）には、製造者の脆弱性対応の要件（附属書I 第II部）と、メンテナーへの報告（第13条第6項）がかかります（第69条第2項、ガイダンス 218）。
報告が必要なら、何をする？
3つの質問の結果、報告が必要になったときの流れを、架空の例で追ってみます。
| 時点（架空の例） | すること |
|---|---|
| 金曜 21:00 | 顧客から「攻撃されたかも」と連絡があり、すぐに初期評価を始める |
| 土曜 10:00 | 悪用をある程度の確かさで判断できた ＝ ここが「気づいた」とき |
| 日曜 10:00 まで | 早期警告（気づいてから24時間以内） |
| 火曜 10:00 まで | 通知（気づいてから72時間以内） |
| 修正策や緩和策を出してから14日以内 | 最終報告 |
24時間と72時間は上限で、どちらも「遅滞なく」出すことが求められています（第14条第2項）。期限の起点は、連絡を受けたときではなく「気づいた（become aware）」ときです。ガイダンス（213）によると、怪しい出来事を見つけたり外部から知らされたりしたら、すぐに初期の評価を行います。その結果、ある程度の確かさで判断できた時点が「気づいた」ときです。どのくらい時間がかかるかは状況によって変わりますが、初期の評価を速やかに行うことが重視されています（ガイダンス 214）。
火事を見つけたら、まず119番に電話して、落ち着いてから詳しく説明する、という流れに似ています。最初の24時間は「何が起きたか」の第一報で、詳しい内容はあとの報告で伝えます。
製品のセキュリティに影響する重大インシデントも、報告の対象です。早期警告と通知の期限は同じで、最終報告だけが違い、72時間の通知から1か月以内です（第14条）。
どこに報告する？
報告先は、ENISA（EUサイバーセキュリティ機関）が運営する「単一報告プラットフォーム（SRP）」です（第16条）。SRPは2026年9月11日から稼働していて、欧州委員会の共通アカウント「EU Login」で登録して使います。報告は、各国の調整役のCSIRT（セキュリティ事故対応チーム）とENISAに同時に届きます。
報告は、EU内の主な拠点がある国のCSIRTあてに出します（第14条第7項）。EU内に拠点がない会社（日本の会社など）は、次の順番で報告先の国を決めます。
- 代理人（authorised representative）がいる国
- 輸入者がいる国
- 販売者（distributor）がいる国
- 利用者がいちばん多い国
1〜3は、その会社の製品をいちばん多く扱っている代理人・輸入者・販売者で決めます。
利用者にも知らせる？
当局への報告とは別に、影響を受ける利用者（適切な場合は全利用者）に、脆弱性やインシデントと、利用者がとれる対策を知らせることも求められています（第14条第8項）。ただし、詳細をすべて公開するという意味ではなく、関係する利用者に絞って伝えることもできます（ガイダンス 220）。
OSSのメンテナーにも伝える？
第13条第6項では、製造者が組み込んだ部品（OSSを含む）に脆弱性を見つけたときは、その部品を作っている人やメンテナーに報告する ことが義務とされています。製造者が修正を作った場合は、そのコードや文書を部品の作り手と共有します（適切な場合は機械が読める形式で）。この義務は、第14条の報告義務とは違い、2027年12月11日から 適用されます。それより前に出した製品には、その後に大きな変更を加えない限りかかりません（第69条第2項）。
メンテナーがすでに知っていると確認できる場合や、メンテナーがいない場合は、報告しなくてかまいません（ガイダンス 223、225）。
自分で開発していないOSSでも、製品に組み込んだ製造者には、見つけた脆弱性をOSSのプロジェクトに伝える義務があるということです。
違反したらどうなる？
報告義務（第14条）、製造者の義務（第13条）、附属書Iのセキュリティ要件を守らなかった場合、最大1,500万ユーロ、または全世界の年間売上高の2.5%のいずれか高いほう の制裁金が科されることがあります（第64条第2項）。
実際の金額は、違反の内容や期間、会社の規模（中小企業かどうか）などを考えて決められます（第64条第5項）。制裁金の細かいルールは、EUの各国が定めます（第64条第1項）。
なお、零細企業・小企業は、24時間以内の早期警告に間に合わなかったことについては、制裁金の対象外とされています（第64条第10項(a)）。
⚠️ 報告義務は2026年9月11日から適用されていますが、制裁金を定めた第64条は、条文の上では2027年12月11日から適用されます。欧州委員会のFAQ（7.1）でも、市場監視と執行に関する規定は2027年12月11日から適用 されると説明されています。
2026年9月11日から2027年12月10日までの報告義務違反に制裁金が科されうるかについては、欧州委員会のFAQ・ガイダンスとも直接は触れていません。条文からも明確には読み取れません。いずれにしても報告義務そのものはすでに適用されているので、「制裁金がないなら報告しなくてよい」とは考えないでください。
OSSを公開している人も対象？
新人君
僕、趣味でGitHubにOSSを公開してるんです。僕にも24時間以内の報告義務があるんですか？
ossan
趣味で公開しているだけなら、基本的には対象外だよ。CRAは「商業活動として市場に出す製品」が対象なんだ。ただ、お金のもらい方によっては話が変わるから、線引きを見ておこう。
「商業活動」かどうかの線引き
CRAは、製品を「商業活動として」EUの市場に提供することを対象にしています（第3条の「市場で入手可能にすること」の定義）。前文とガイダンスでは、OSSについて次のような考え方が示されています。
✅ 商業活動とみなされないもの（前文第15・18・20項、ガイダンス 56、61）
- 製造者が収益化（monetise）していないOSSを公開すること
- 他の製造者が組み込む部品として公開しているOSSで、自分では収益化していないもの
- GitHub などの公開リポジトリやパッケージマネージャーに置いているだけのこと（前文第20項）
- 製造者から資金援助を受けている、製造者が開発に参加している、というだけのこと
- 定期的にリリースしている、というだけのこと
- 誰でも自由に入手できるOSSで、有償のサポートは任意で別に買う形にしていること
- 利益目的ではない寄付を受けること（寄付を募るだけなら、集まった額が費用を超えても利益目的とはみなされない）
- 費用を除いた収益をすべて非営利の目的に使うように組織された非営利団体が、OSSを開発すること
- 自分が責任を持っていないOSSプロジェクトに、コードを寄稿すること
前文第18項では、どういう経緯で開発されたか、開発資金がどこから出たかだけで、商業活動かどうかを判断しないとされています。
⚠️ 商業活動とみなされうるもの（前文第15項、ガイダンス 56、57、62）
- 製品に値段をつけること
- OSSの入手や保守を、支払いを条件にしていること（サポートつきの有償版など）
- 他のサービスで収益を上げるための基盤として提供すること
- セキュリティ・互換性・相互運用性の改善だけを目的とする場合を除いて、個人データの処理を利用の条件にすること
- 寄付が実質的に代金になっていること（寄付した人だけがリリースや更新を受け取れるなど）
決め手は、OSSそのものの入手や保守が支払いを条件にしているかどうかです（ガイダンス 56）。個人がサポートをセットにして料金を取る場合も、生活費を含む実費の回収なら、それだけで商業活動とはされません（ガイダンス 58）。
⚠️ 個人の開発者でも、OSSの入手や保守を有償にするなど、上の「商業活動」にあたる形で提供すれば、製造者として扱われる可能性があります。前文とガイダンスは考え方を示したもので、個別のケースでどう判断されるかは 事情によって変わり、断定できません。収益につながる形でOSSを提供している場合は、専門家に相談しましょう。
新しい立場「OSSスチュワード」
CRAには、「オープンソースソフトウェアスチュワード」という新しい立場があります。商業利用を想定したOSSの開発を、継続的に支えている法人のことです（第3条）。前文第19項では、財団や、ビジネスの中でOSSを開発・公開している団体（非営利団体を含む）が例に挙げられています。OSSで収益を上げていなくても、法人が継続的に支えていれば、スチュワードにあたることがあります。たとえば、自社製品に組み込むライブラリを無償で公開している法人です（ガイダンス 68）。
スチュワードには、製造者よりも軽い「ライトタッチ」な義務が定められています。
- セキュリティポリシーを作り、記録しておく（第24条第1項）
- 市場監視当局から求められたら協力する（第24条第2項）
- 報告義務は限られた範囲で負う。悪用されている脆弱性は、そのOSSの開発に関わっている範囲で、重大インシデントは、スチュワードが開発のために提供しているシステムに影響する範囲で報告し、利用者にも知らせる（第24条第3項）
- 制裁金は科されない（第64条第10項(b)）
第24条は、CRAの全面適用と同じ2027年12月11日から適用されます。
実務での対応：今日から始めること
EU向けに製品を出している場合は、次のことから始めましょう。
- ✅ 製品ごとにSBOMを作り、どのOSSのどのバージョンが入っているかを把握する
- ✅ 使っているOSSの脆弱性情報を監視し、「製品の中で悪用された」という情報が入ったときの社内の連絡ルートを決めておく
- ✅ 「対象の製品か」「入っているか」「製品の中で悪用された証拠があるか」を、誰がどう判断するか決めておく
- ✅ SRPへの報告担当者と手順を決めておく（24時間は、週末をはさむとあっという間です）
- ✅ EU内に拠点がない場合は、どの国のCSIRTに報告するかを先に決めておく
- ✅ 組み込んだOSSに脆弱性を見つけたら、OSSのプロジェクトにも伝える手順を決めておく
- ⚠️ 2027年12月11日より前に出した製品も、報告義務の対象になる
- ⚠️ 自社でOSSを公開している場合は、「商業活動」にあたる提供のしかたをしていないか、スチュワードにあたらないかを確認する
まとめ
- CRAの報告義務は2026年9月11日から適用済み。悪用されている脆弱性は、気づいてから24時間・72時間、修正策や緩和策が出てから14日の3段階で報告する
- 組み込んだOSSの脆弱性は、CVEが出ただけでは報告の対象にならない。製品の中で悪用された証拠があれば報告する。OSSのメンテナーへの報告は、2027年12月11日から義務になる（それより前に出した製品は、大きな変更を加えない限り対象外）
- 入っているOSSを把握するSBOMが対応の土台。趣味で公開しているだけのOSSは基本的に対象外だが、「商業活動」の線引きには注意する
ossan
ライセンス管理で作っているOSSの一覧は、セキュリティの対応にも役立つよ。まずは「何が入っているか」を把握するところから始めよう。
関連記事
参考資料
この記事の内容は、2026年11月1日時点の情報をもとにしています。
- Regulation (EU) 2024/2847（Cyber Resilience Act）– EUR-Lex
- European Commission – Cyber Resilience Act: Reporting obligations
- European Commission – Commission guidance on the application of the Cyber Resilience Act（2026年7月27日）
- European Commission – FAQs on the Cyber Resilience Act（第1.4版、2026年9月4日）
- ENISA – Single Reporting Platform: Frequently Asked Questions
本記事は一般的な情報提供を目的としたものであり、法的助言ではありません。具体的な案件については、弁護士などの専門家にご相談ください。
