欧州連合のサイバーレジリエンス法(Cyber Resilience Act、以下CRA)のうち、報告に関する部分が2026年9月11日から動き出した。欧州委員会の説明によると、この日以降、デジタル要素を含む製品のメーカーは、攻撃に悪用されている脆弱性と、製品の安全性に影響する重大なインシデントを当局へ届け出る義務を負う。法律全体の適用開始は2027年12月とされているので、報告の部分だけが先に立ち上がった形になる。

欧州の規制と聞くと遠い話に思えるが、WordPressのプラグインやテーマを世に出している作り手には、まったくの他人事とも言い切れない。脆弱性の調整を手がけるPatchstackは、この条文が公開ソフトの作り手にどう関わるかを、WordPressを例に取り上げている。

届け出るものと、その締め切り

報告が必要になるのは二種類ある。実際に悪用が確認されている脆弱性と、製品の安全性に影響する重大なインシデントである。締め切りは短い。認識してから24時間以内に早期警告を出し、72時間以内に概要と初期評価を含む通知を提出する。最終報告は、悪用中の脆弱性であれば修正措置が利用できるようになってから14日以内、重大インシデントであれば72時間通知から1か月以内とされている。あわせて、影響を受ける利用者に何が起きたかと身の守り方を伝えることも求められる。

提出先は一本化されていて、欧州のサイバーセキュリティ機関であるENISAが運用するSingle Reporting Platform(単一報告窓口、SRP)に集約される。メーカーは一度出せばよく、主たる拠点のある国のセキュリティ対応組織、いわゆるCSIRTに届き、原則としてENISAにも同時に共有される。最初に受け取ったCSIRTは、その製品が流通している他国のCSIRTへ遅滞なく共有する仕組みになっている。

公開物か、商用製品かの線引き

ここで気になるのが、誰が義務の当事者になるのかという点である。欧州委員会のページでは、オープンソースソフトウェアのスチュワードに対する報告義務は第24条3項に基づくもので、適用は2027年12月11日からと明記されている。一方でPatchstackは、GPLで公開されていても有料版など収益を得る手段があるプラグインの販売者は、スチュワードではなくメーカーに当たるという整理を示している。営利の意図がまったくない公開プラグインを法人の従業員が保守している場合はスチュワードに当たる、という例も添えられている。同社によれば、スチュワードには制裁金は科されないが、非準拠の製品を欧州市場から取り除くための手段は残るという。

オープンソースであることと無償であることが一致しないWordPressの世界では、この線引きは意外と身近に響く。人気のあるプラグインの多くは、公開されていながら商用の意図を持った製品でもあるからだ。同社は、WordPress周辺で知られている脆弱性の半分以上を自社が調整してきたとしており、影響範囲の広さがうかがえる。

窓口の使い勝手という現実的な話

制度の中身以上に現場に効きそうなのが、窓口の操作である。PatchstackはSRPにAPIがなく、報告1件につき3つのフォームを手作業で埋める必要があると指摘している。提出にはEU Loginの個人アカウントと多要素認証が必要で、アカウントは個人に紐づく。24時間という締め切りを考えると、事が起きてから登録を始めるのでは間に合わない恐れがある。同社は、アカウントだけでも先に用意しておくことを勧めている。

その負担を引き受ける動きも出ている。Patchstackは9月11日付で、公開ソフトの保守担当者向けに、指定代理人として報告を代行する仕組みを無料で使える形で提供し始めたと発表した。報告件数が増え、SRPにAPIが用意されないままであれば、1件あたりの課金を将来的に導入する可能性があるとも書き添えられている。

受託制作の側から見ると

日本で中小企業のサイトを作っている立場なら、自分が報告義務の当事者になる場面はそう多くないだろう。ただ、納品したサイトに組み込んだ有料プラグインの作者が欧州市場に製品を出しているなら、悪用が確認された脆弱性の情報が、これまでより早く表に出てくる可能性はある。

更新の判断材料が増えること自体は、受け取る側には悪い話ではない。ただ、公表が早くなるということは、修正版が出てから適用するまでの猶予が短くなるということでもある。どのサイトにどのプラグインが入っていて、誰が更新を見ているのかを手元で把握しておく。規制そのものは欧州の話でも、そこを通って流れてくる情報の速さは、地方の小さな制作現場にも同じように届く。