EUサイバーレジリエンス法の報告義務の適用開始日は2026年9月11日となる
ライフサイクル終了間近のオープンソースがもたらすリスクを把握し、期限が迫る前にパッチを適用してコンプライアンスを維持しましょう。
EU市場に製品を流通させるすべての企業に適用されます。本社の所在地は問いません。
報告義務は、以下の時点から開始されます。
00
DAYS
00
営業時間
00
MIN
00
SEC
締切 -2026年9月11日
9月11日が来る前に、自分が何の上に立っているのかを知っておきましょう。
4つの分野にわたる16問の問題で、それぞれが関連する法令条文に基づいています。得点、分野ごとの弱点、そして優先して改善すべき点を確認できます。結果を確認するのに登録は不要です。
16の質問
4つのセクション
約4分
CRA対応準備レポート
EU規則（EU）2024/2847に基づく。本ツールは一般的な指針を提供するものであり、法的助言ではなく、またコンプライアンス認証を意味するものでもありません。
このチェックリストは、あなたの処理の流れについて示しています。それでは、実際にコードに何が書かれているかを確認してみましょう。
上記の質問は、ポリシー、連絡窓口、サポート期間の約束といったプロセスが整備されているかどうかについて尋ねたものです。これらは、製品に含まれるオープンソースコンポーネントが現在すでにサポート終了状態にあるかどうかを判断するものではありません。それは別の、より具体的な問題であり、第14条に基づく報告対象となる脆弱性として最も頻繁に挙げられるものです。
「サイバーレジリエンス法」に基づく報告期間のカウントダウンが始まり、その期間は四半期単位ではなく、時間単位で計算される。
「デジタル要素を含む製品」の製造業者は、実際に悪用されている脆弱性や重大なインシデントについて、新たなCRA単一報告プラットフォームを通じて報告しなければなりません。製造業者が、自社製品に実際に悪用されている脆弱性があることを認識した（または重大なセキュリティインシデントが発生した）時点で、3段階のカウントダウンが開始されます：
早期警報
内部で
24時間
ENISA単一報告プラットフォームを通じて、自国のCSIRTに最初の通知を行う（この通知はENISAにも同時に表示される）
通知全文
内部で
72時間
現時点で判明している詳細および講じられた是正措置をすべて盛り込んだ通知。
最終報告書 - 悪用された脆弱性
内部で
14日間
是正措置が実施可能となってから14日以内に最終報告書を提出すること。
最終報告書 - 事案
内部で
1か月
重大なセキュリティインシデントについては、1か月以内に最終報告書を提出すること。
これは新製品に限った話ではありません。
報告義務は、すでにEU市場に出回っている製品（レガシーソフトウェアを含む）に適用されます。「次のリリースまでに何とかする」といった対応は通用しません。この問題を先送りすることはできません。
報道が最優先であり、あとはそれに続く。
必須要件のすべて（セキュア・バイ・デザイン、SBOM、CEマーキング）は、2027年12月11日以降に適用されます。報告義務は、2026年9月に導入される短期的な推進要因となります。
罰則について、わかりやすく説明します。
中核的な義務を遵守しなかった場合、最高1,500万ユーロ、または全世界の年間売上高の2.5％のいずれか高い方の罰金が科される可能性があります。
クイックリファレンス
報告期限
2026年9月11日
旧製品にも適用されますか？
はい
EUの企業のみですか？
いいえ
最高刑
1,500万ユーロ／売上高の2.5％
必須要件の全項目
2027年12月11日
対象となるためには、必ずしも欧州に拠点を置く必要はありません。
適用範囲は、本社の所在地ではなく、市場での事業展開の有無によって決まります。「これはEU企業のみに適用される」というのは、CRAに関する最も一般的な、そしておそらく最も大きな損失を招きかねない誤解です。以下のいずれかに該当する場合、この規定が適用されます：
EU向けに製品を販売しているソフトウェアベンダーまたはISVの方
たとえ間接的にであっても、チャネルパートナーを通じてであっても――ご自身がそう認識しているかどうかに関わらず、同法上は「製造業者」とみなされます。
EUに顧客や子会社がある、あるいはEUで販売されているSKUが1つある
EU市場に1つの製品を投入すれば十分です。本社の所在地がどこであろうと、その事実は変わりません。
あなたは、すでにSBOMや監査の依頼に対応しているセキュリティまたはコンプライアンスの責任者です
すでに順守すべき枠組みに加え、新たに厳格な外部報告の期限が課されることになりました。
スタック内にサポート対象外のオープンソースが含まれていることは分かっているが、その全容を把握しきれていない
スタック内にサポート対象外のオープンソースが含まれていることは分かっているが、その全容を把握しきれていない
締め切り自体は難しいことではありません。
難しいのは、何を報告すべきかを見極めることです。
存在すら知らなかったコンポーネントの脆弱性について、24時間以内の報告期限を守ることは不可能ですが、監査担当者はそれを当然のこととして期待してきます。サポート終了済みでサポート対象外のオープンソースは、手遅れになるまで見過ごされがちなものです。フレームワークが公式アップデートを受けなくなると、HeroDevsを除いて、誰もそれを監視しなくなるのです。
EOLはCVEではありません
新しい脆弱性に対処する者がいないからです。お使いのCVEスキャナーは、「今後、このコンポーネントの新しい脆弱性を修正する者がいない」という事実を検出するようには設計されていません。EOL（サポート終了）ソフトウェアのスキャン結果にCVEが表示されないからといって、脆弱性が存在しないわけではありません。それは、お使いのスキャナーが全体像を把握できていないことを意味するのです。
推移的な依存関係の中に隠れている
問題を引き起こす可能性が最も高いEOLコンポーネントは、直接選択したものではなく、依存関係のさらにその先の依存関係にあるものです。
報告すべき正当な理由は何もない
たとえ問題を時間内に発見したとしても、アップストリームからの修正は期待できないため、誠意ある対応として提示できるものは何もなく、土壇場での更新や移行に着手する時間も残されていない。
9月までに準備すべきこと
2つのステップ：自分が立っている場所を確認し、その場所を守れるようにしておくこと。
HeroDevsは、「可視性の問題」と「是正措置の問題」という2つの課題を解決するため、フレームワークのスケジュールに縛られることなく、ご自身のペースで誠実に報告を行うことができます。
ステップ 1 · 表示設定
EOL Dataset は、使用しているオープンソースコンポーネントのうち、すでにサポート終了（EOL）となり、サポート対象外となっているものを特定します。これは、CVE スキャナーでは検出できないリスクです。このツールは、既存の SCA ツールと対立するのではなく、連携して機能します。SCA ツールが既知の CVE を一覧表示するのに対し、EOL Dataset はサポートが終了し、もはや追跡されていないコンポーネントを特定します。
放棄された依存関係、サポート終了（EOL）の依存関係、およびまもなくサポート終了となる依存関係を検出します。これには、多くのインベントリでは見落とされがちな推移的な依存関係も含まれます。
4つの明確なステータス状態があるため、すでにサポート対象外となっているものと、今後サポート対象外となるものを区別できます。
コンプライアンス担当者に提出できる、説得力のある在庫リスト――これなしでは報告できないものです。
1,900万以上のオープンソースパッケージに関するライフサイクルデータに基づいているため、特定のコンポーネントに関する答えはすでに用意されており、チームが独自に調査する必要はありません。
ステップ 2 · 是正措置
Never-Ending Support (NES)
EOL（サポート終了）対象が判明すれば、NESはその製品に対して継続的にパッチを適用します。これには、フレームワークの公式サポート終了後に発見された新しいCVEも含まれるため、常に正当な根拠に基づいた報告が可能になります。安全なドロップイン置換を、お客様のスケジュールに合わせて実現し、即座に問題を解決。セキュリティの妥協も、業務への支障もありません。
社内に、AngularJS 、Spring 、Vue、Bootstrap などのオリジナルフレームワークのメンテナが在籍しています。
CNAのステータス— HeroDevsは、公開された情報に反応するだけでなく、CVEを先回りして発見し、パッチを適用することができます。
すべての深刻度に対応したパッチ適用、ドロップインインストール— アプリケーションへの互換性破綻を招く変更はなく、即座に問題を修正できます。
証明書――コンプライアンス担当者が監査人に提出できる書類。
各チームから最初に寄せられる質問
もちろん、お探しの答えが見つからない場合は、お気軽にお問い合わせください。
NESが具体的にどの規定を廃止し、強化し、手をつけないのか。
これはコンプライアンスの主張ではなく、範囲を把握するためのツールとしてお読みください。メンテナンスが行われていないサポート終了コンポーネントは、いくつかの規定において重大な不適合となりますが、商用サポートを受けることで、それらは適合となります。また、他の規定については適合性を高めるだけであり、まったく影響がないものもあります。
NESが直接その差を埋める
EOLコンポーネントは、ここでは「不合格」となります。しかし、ベンダーが再びパッチの提供を開始したため、NESはこれを「合格」に判定します。
セキュリティ更新プログラムの提供などを通じて、脆弱性を速やかに特定し、是正措置を講じること。
最適な適合――まさにこれがNESの役割です。
附属書Iの第II部に規定される脆弱性について、公表されたサポート期間（最低5年間）を通じて対応を行う。
アンカー条項。NES により、EOL コンポーネントを含むスタックに対して 5 年以上のサポート期間を宣言することが可能になります。
既知の悪用可能な脆弱性がない状態で市場に投入された製品。
パッチが適用されていないCVEを含むEOL依存関係は、導入時点で悪用可能な既知の脆弱性となります。NESでは、バックポートされた修正プログラムを提供しています。
脆弱性は、セキュリティ更新プログラムによって対処することができます。
アップストリームが機能していない場合、更新パスは一切存在しません。NESは、npm、Maven、またはPyPIを通じて更新パスを復元します。
セキュリティ更新プログラムは、アドバイザリメッセージとともに、遅滞なく無料で提供されます。
メンテナがいなければ、配布も行われません。NESは、アーティファクトとアドバイザリの両方を提供しています。
更新プログラムが利用可能になった時点で、修正済みの脆弱性を公開する。
HeroDevs のアドバイザリおよび脆弱性ディレクトリのエントリには、このコンポーネントに関する情報が記載されています。
各セキュリティ更新プログラムは、少なくとも10年間、またはサポート期間の残存期間中、利用可能となります。
発行されたことのない更新内容を保持することはできません。NESはアーティファクトを生成しますが、その保持はユーザー側の責任となります。
NESがその立場を強化しても、義務を負っているのは依然としてあなたです
サードパーティ製コンポーネントに関するデューデリジェンス
EOL（サポート終了）となった依存関係に対して商用サポートを確保することは、文書化可能なデューデリジェンス行為であり、あなたが持つ中で最も説得力のある証拠となります。
コンポーネントのメンテナに通知する
上流が機能していない場合、取引相手が存在しません。NESなら、その相手を提供します。
24時間、72時間、および14日ごとの報告
NESは義務を免除するものではありません。これは、最終報告書を「結論の出ない認否」ではなく、達成可能なものにするための指針となる是正措置を提供するものです。
ソフトウェア部品表
NESはSBOMを作成するのではなく、SBOMに表示される内容を変更するものです。
調整された脆弱性開示
HeroDevsにはコンポーネントに関するポリシーがありますが、製品レベルのポリシーについては引き続き貴社が決定します。
ユーザー向けのサポート期間に関する情報
NESこそが、公表されたサポート終了日を信頼できるものにしているのです。
NESはこれらに対して何の役にも立たない。我々はそれを隠そうとはしない。
製品の分類（第6条～第8条）、大幅な変更（第20条）、EU適合宣言（第22条）、適合性評価手続き（第24条）、CEマーキング（第30条）、および自社のファーストパーティコードに適用される第13条第1項。適合性評価が遅れている場合、NESはその問題の解決策にはなりません。
一言で言えば、NESは、第13条(8)の違反を同条(8)の適合に変換し、是正措置のない第14条の報告書を、是正措置が添付された報告書に変えます。それ以外の事項については、対応はしますが、責任を免除するわけではありません。
9月11日が来る前に、自分が何の上に立っているのかを知っておきましょう。
報告期限が迫る前に、ご存じないサポート終了済みのオープンソースを見つけ出し、それ以外のものについてはパッチを適用し、監査に対応できる状態にしておきましょう。