【lwIP】News #6｜CRAの脆弱性報告、9月11日開始｜SRP運用ガイドが示した6つの実務ポイント

2026年8月16日 15:05

このnoteでは、lwIPで実際に起こり得る不具合・脆弱性・再現方法・最小修正の考え方やデバッグのノウハウをシリーズで解説しています。
▶ 日本語記事一覧はこちら：lwIPトラブル対策室｜日本語記事一覧

本記事は、外部で公表された制度動向（ENISA公開情報）を整理し、lwIP搭載製品の担当者向けに実務への当てはめを示すものです。制度の細目には未確定の部分があり、その箇所は「要確認」と明記します。また、筆者はSRPの画面を実際に操作していません。本記事の内容はENISAが公開したガイダンス文書の記載に基づくものです。

■ 今回のニュース概要

ENISA（EUサイバーセキュリティ機関）が、CRA（EU Cyber Resilience Act、サイバーレジリエンス法）の報告基盤 SRP（Single Reporting Platform） について、実際の登録手順・通知提出手順・画面上の操作を説明するガイダンスを公開しました。現在3本が公開されています。

登録ガイダンス（CRA SRP guidance - AR User registration）：2026年8月3日更新
通知提出ガイダンス（CRA SRP guidance - AR Notification submission and update）：2026年8月3日更新
画面機能ガイダンス（CRA SRP guidance - AR Interface functions）：2026年8月14日更新
ファクトシート（CRA Single Reporting Platform Factsheet）：公開済み

SRPは2026年9月11日から、脆弱性・重大インシデントの必須報告に使用されます。

本記事は、lwIPを組み込んだ製品を出荷しているメーカーで、脆弱性の報告を実際に担当することになる方（品質保証・セキュリティ担当、開発リーダー、製品担当者）に向けたものです。読むと、9月11日までに何を準備すべきか、そして何は準備しなくてよいかが分かります。特に、これから触れる「バックアップ担当者を登録しておけば下書きも引き継げる」「CVEが公開されたら報告義務が発生する」という2つの想定は、いずれもガイダンスの記載とは食い違います。

■ この記事のポイント：制度の説明から、操作の手順へ

これまでENISAが公開していたのは、主にFAQと制度の枠組みでした。「いつから」「何時間以内に」「誰が」という制度側の情報です。本シリーズの News #2 は、その段階の情報をもとに「事前に何を棚卸ししておくべきか」を整理したものです。

今回公開されたのは、その一段先です。アカウントをどう作るか、通知をどの順番で出すか、出した後どうなるか、複数の担当者でどう運用するかという、実際に手を動かす側の情報が示されました。

制度 → 運用 → 操作、と具体化が進んだことになります。

そして操作レベルまで降りてくると、制度の説明だけを読んで想像していた運用と食い違う点がいくつか出てきます。ここからは、そのうちlwIP搭載製品のメーカーに関係が深い6点を取り上げます。

■ ポイント1：「今のうちに登録しておこう」は、推奨されていません

CRA対応の準備として、まずSRPのアカウントを作っておこう、と考えるのは自然な発想です。しかしENISAの登録ガイダンスは、これを勧めていません。

原文はこうです。

manufacturers and open-source stewards are advised to register and initiate the validation process only when they need to submit a specific notification, rather than creating an account pre-emptively

（製造者およびオープンソースのスチュワードは、あらかじめアカウントを作成するのではなく、特定の通知を提出する必要が生じたときにはじめて登録と検証を開始することが推奨される、という趣旨）

つまり、報告が必要になった時点でSRPへの登録を始める運用が想定されています。

ただし、ここで非推奨とされているのはSRPへの登録と検証の開始であって、EU Loginの作成ではありません。 SRPの登録にはEU Loginアカウントが必要で、ENISAのFAQは、EU Loginは事前に作成できると案内しています（「which can be created in advance」）。事前に用意しておいてよいのはEU Loginまで、SRPの登録は報告が必要になってから、という切り分けになります。

では、準備することは何もないのか。 そうではありません。登録が不要になった分、準備の重心が「自社製品側の情報整備」に寄ったと考えるのが妥当です。報告が必要になってから登録するということは、登録と、影響製品の特定と、初期評価を、同じ24時間から72時間の中で並行して進めるということだからです。

では、その「自社製品側の情報整備」は、誰が持っていればよいのか。ここが次のポイントにつながります。

■ ポイント2：「バックアップ担当者を登録しておけば下書きも引き継げる」わけではありません

2026年8月14日に公開された画面機能ガイダンスで、複数の担当者による運用の仕組みが明らかになりました。

SRPには担当者のロールが2種類あります。登録フローを完了した人が Primary AR（ロール名は `AR Primary User`）、招待によって登録した人が Secondary AR（同じく `AR Backup User`）です。Primary ARは、同じメーカーのSecondary ARを招待して登録させることができます。

担当者の交代も想定されています。Secondary ARはPrimary ARへの昇格を申請でき、その申請は担当CSIRT（CDaC）に送られて審査されます。

セキュリティ担当が実質1人という体制は、組み込み機器のメーカーでは珍しくありません。報告の起点は「認識した時点」であり、担当者の在席状況を待ってくれません。バックアップの担当者を登録できる仕組みがあるのは、この点で意味があります。

ただし、ここに落とし穴があります。 同じガイダンスには、次の記載があります。

The Dashboard displays only the draft notifications created by you. You cannot view draft notifications created by another AR associated with the same manufacturer.

（ダッシュボードに表示される下書きの通知は自分が作成したものだけであり、同じメーカーに紐づく他のARが作成した下書きは閲覧できない、という趣旨）

つまり、下書きは担当者間で共有されません。

具体的に何が起きるかというと、こうです。担当者AがlwIPの脆弱性について早期警告の下書きを作り、提出前に不在になったとします。担当者Bはその下書きを開くことができません。Bは同じ内容を一から入力し直すことになります。24時間という期限の中で、この作り直しは軽くありません。

つまり、アカウントを冗長化するだけでは足りません。 複数の担当者で運用する場合はSecondary ARを登録できますが、それだけでは下書きは引き継げません。報告に必要な情報を、SRPの外で担当者間が共有できる状態にしておく必要があります。具体的には次のような情報です。

対象製品と、その製品分類
使用しているSDKのバージョンと、同梱されているlwIPのバージョン
ベンダーfork（SDK同梱版の独自改変）の有無
有効にしているlwIPの機能（SNMP・DHCP・DNS・SMTPクライアントなど）
影響を受けると判断した根拠、または受けないと判断した根拠
SRPに入力する予定の内容そのもの

これらは、News #2 の「準備5項目」を、担当者間で引き継ぐ実データにまで具体化したものです。製品・バージョン・fork・有効機能は準備項目1・2・4に、影響判断の根拠とSRPへの入力予定内容は準備項目3・5に対応します。下書きが共有されないという仕様が分かったことで、この台帳をSRPの外に持っておく必要性がはっきりしたと言えます。

なお、ガイダンスが明記しているのは下書き（draft）についてです。提出後の通知を同じメーカーの他のARが閲覧・編集できるかどうかは、筆者には読み取れませんでした＝要確認。

■ ポイント3：「承認が下りるまで報告できない」わけではありません

SRPでは、報告する担当者（Assigned Representative、以下AR）が本当にその企業を代表して報告できる立場かどうかを、担当CSIRT（CSIRT Designated as Coordinator）が確認します。

なお、この Assigned Representative は、SRPで通知を入力するためのプラットフォーム上のユーザーロールです。CRA第3条(15)が定める authorised representative（授権代理人。製造者から書面による委任を受けたEU域内の自然人または法人）とは別の概念で、名称が似ているだけです。CRA上の授権代理人がSRPのARとして登録することはあり得ますが、SRPでARとして登録しただけでCRA上の授権代理人になるわけではありません。人選の際は混同しないよう注意してください。

ここで気になるのは、その確認が終わるまで報告できないのではないかという点です。24時間以内に早期警告を出さなければならないのに、承認待ちで止まったら間に合いません。

この点について、登録ガイダンスは明確に否定しています。

Validation of the registration of the assigned representative (AR) by the CSIRT Designated as Coordinator (CDaC)...is not a prerequisite for fulfilling the CRA reporting obligation.

（担当CSIRTによるAR登録の検証は、CRAの報告義務を果たすための前提条件ではない、という趣旨）

検証は最初のアクセスの後に行われ、通知の提出自体を妨げないとされています。ポイント1の「事前登録を推奨しない」という方針は、この設計とセットで理解すると筋が通ります。

画面機能ガイダンスは、この点をさらに具体的にしています。まず、1つのARアカウントを複数のメーカーに関連付けることができます（受託開発やグループ企業で意味を持ちます）。そして検証が済んでいない状態については、次の記載があります。

As unverified AR you can submit only up to 10 notifications.

（未検証のARとして提出できる通知は10件までである、という趣旨）

上限はあるものの、検証の完了を待たずに報告できることが、件数という具体的な形で示されたことになります。

なお、この10件という上限は、追加したメーカーとの関連付けが未検証である場合について明記されているものです（画面機能ガイダンスの「Add an Association with an Additional Manufacturer」の節にあります）。初回登録時の未検証状態にも同じ上限が適用されるかどうかは、公開文書からは確認できませんでした＝要確認。

■ ポイント4：「72時間かけて調べてから、まとめて報告」はできません

報告は3段階です。24時間以内の早期警告（Early Warning）、72時間以内の通知、そして最終報告（Final Report）。ここまでは News #2 でも扱いました。

今回明らかになったのは、SRPの操作フローの上で、この3段階に順序が要求されることです。通知提出ガイダンスは、各段階の前提条件（Pre-conditions）を次のように示しています。

72時間通知の前提：同じ通知の早期警告が既に提出されていること（An Early Warning has already been submitted.）
最終報告の前提：早期警告と72時間通知の両方が既に提出されていること（An Early Warning and a 72-hour Notification have already been submitted.）

これは実務上、無視できない制約です。「情報がまとまってから一度に出す」という進め方が、SRPの画面上でできません。まず早期警告を提出しないと、72時間通知の入口に立てないのです（ここで述べているのはSRPの操作上の前提条件であり、CRA条文が定める義務の順序そのものの解説ではありません）。

lwIP搭載製品では、この制約が特に重く効きます。 悪用の一報が来た時点で、自社製品が使っているlwIPのバージョン、ベンダーfork（SDK同梱版の独自改変）の有無、有効にしている機能（SNMP・DHCP・DNSなど）が分かっていないことは、十分あり得ます。しかし調査の完了を待って早期警告を先送りすると、次の段階に進めません。

「24時間の時点では分かっていることが少ない」という状況は、想定されている前提です。分かっていないまま早期警告を出し、72時間の通知で初期評価を足す、という運用になります。

■ ポイント5：最終報告を出すと、後から直せなくなります

通知提出ガイダンスには、次の記載があります。

The notification becomes non-editable after the submission of a Final Report.

（最終報告の提出後、その通知は編集不可になる、という趣旨）

これは、最終報告を出すタイミングの判断に直結します。

脆弱性の場合、最終報告の期限は「修正・緩和策が利用可能になってから14日以内」です（重大インシデントの場合は72時間通知の提出から1か月以内）。期限に余裕があるうちに早めに出しておこう、という判断は自然ですが、出した後で追加の影響製品が見つかっても、その通知は編集できません。

lwIPのように複数製品・複数SDKにまたがって組み込まれているコンポーネントでは、影響範囲の確定に時間がかかります。「他の製品ラインにも同じlwIPが入っていた」と後から分かることは起こり得ます。

とはいえ、期限を過ぎてよいわけではありません。 期限を守ったうえで、提出前に可能な範囲で影響製品を確認しておく、という運用になります。なお、期限後に新たな影響製品が判明した場合にどう扱われるのかは、公開ガイダンスからは確認できませんでした＝要確認。

■ ポイント6：CVEが公開されただけでは、報告義務は発生しません

ここは誤解しやすいところです。lwIPに新しいCVEが公開された、というニュースを見た瞬間に「24時間以内に報告しなければ」と考える必要はありません。

ENISAのファクトシートは、報告対象を次の2つとしています。

Actively Exploited Vulnerabilities：悪意ある行為者によって現に悪用されていることが判明している、デジタル要素を持つ製品の脆弱性（CRA第3条(42)）
Severe Incidents：デジタル要素を持つ製品のセキュリティに重大な影響を与えるインシデント（可用性・真正性・完全性・機密性の侵害など。CRA第3条(44)。重大性の基準は第14条(5)）

つまり、報告義務の引き金は「脆弱性が公開されたこと」ではなく、「現に悪用されていること」または「重大インシデントが起きたこと」です。

たとえば本シリーズで扱った Bug #6（CVE-2026-8836）は、SNMPv3を有効にしたlwIP 2.1.0〜2.2.1で、認証情報を持たない相手からの1パケットによって固定長のスタックバッファをはみ出す、という内容です。深刻な脆弱性であり、CVEとしても公開されています。しかしCVEが公開されたこと自体は、SRPへの報告義務を発生させません。

ただし、これは「対応しなくてよい」という意味ではありません。

CRAには、今回の報告義務とは別に、脆弱性の取り扱いに関する要求もあるとされています（本記事はSRPの報告実務を扱うもので、そちらの詳細には立ち入りません＝要確認）
悪用が観測された時点で、24時間の計測が始まります。そのとき影響製品を特定できる状態にあるかどうかが問われます

CVE公開時に必要なのは、報告ではなく影響判定です。そして、その判定が24時間から72時間でできる状態になっているかどうかが、ポイント2で述べた「情報をSRPの外で共有しておく」ことと、ポイント4で述べた順序の制約に直結します。

■ 提出した後、通知はどう流れるか

提出後の流れについては、ファクトシートと通知提出ガイダンスで書き方が違うため、補足しておきます。

ファクトシートは、通知が担当CSIRTと関係国のCSIRT、そしてENISAへ「automatically」送られ、最初に受け取ったCSIRTが「without delay（遅滞なく）」他の関係CSIRTへ展開する、と説明しています。一方、通知提出ガイダンスは、関係CSIRTが早期警告を受け取るのは担当CSIRTによる「manual dissemination（手動の展開）」の後である、としています。

この2つは矛盾しません。整理するとこうなります。

提出した通知は、担当CSIRTとENISAには自動的に届く
他の関係国のCSIRTには、担当CSIRTが展開の操作を行った後に届く
「manual」は展開を人が開始するという方式の話、「without delay」はそれをいつ行うかという義務の話であり、指している対象が違う
例外的な状況では展開を遅らせることが認められています（ファクトシートはCRA第16条(2)、および委任規則 (EU) 2026/881 を挙げています）

実務上の意味は、提出した瞬間に全EU加盟国へ一斉に伝わるわけではない、ということです。ただしこれは報告する側の義務には影響しません。期限は提出の時点で判断されます。

■ lwIP搭載製品にとっての意味

今回のガイダンス公開で、報告する側の手順は具体化されました。整理すると、SRP側で事前にやっておくことは、ENISAの推奨に従うならほとんどありません。

代わりに残るのは、自社製品側の情報整備です。しかもポイント2で見たとおり、その情報はSRPの中に置いておくことができません（下書きが担当者間で共有されないため）。社内の台帳や資料として、担当者が代わっても引き継げる形で持っておく必要があります。

製品ごとのlwIPバージョンと、ベンダーfork（SDK同梱版の独自改変）の有無
有効にしている機能（SNMP・DHCP・DNS・SMTPクライアント・RAW/Socket APIなど）
脆弱なコードへの外部からの到達可能性
対象製品・販売国・顧客通知先

これらは、報告が必要になってから調べ始めたのでは間に合いません。具体的な棚卸しの手順は、News #2｜CRAの72時間報告にlwIP製品は間に合うかに「準備5項目」のチェックリストとして整理しています。

また、そもそもlwIP由来の脆弱性について誰が報告する立場にあるのかという論点は、News #4｜lwIPの脆弱性、責任を負うのは誰かで扱っています。

■ まだ分からないこと

技術記事として、確認できていないことも明示しておきます。

筆者はSRPの画面を実際に操作していません。 本記事はENISAが公開したガイダンス文書の記載に基づくものであり、実際の画面遷移・入力項目・入力必須の範囲は未検証です。
稼働後の実運用は未確認です。 担当CSIRTがどの程度の速度で処理するのか、通知がどのように扱われるのかは、稼働してみないと分かりません。
通知が無効化される条件は分かりません。 画面機能ガイダンスには、例外的または重大な事象が起きたときに赤いアラートが表示され、その例として担当CSIRTが提出内容を無効化した場合（a designated CSIRT has invalidated a submission）が挙げられています。しかし、どういう場合に無効化されるのか、無効化されたときに期限の扱いがどうなるのかは記載を見つけられませんでした＝要確認。
下書きが共有されない仕様の範囲。 ポイント2で述べたとおり、ガイダンスが明記しているのは下書き（draft）についてです。提出後の通知が同じメーカーの他のARからどう見えるのかは、筆者未確認です＝要確認。

■ 次に確認すること

SRPは2026年9月11日から稼働予定です。ガイダンスは2026年8月3日に2本、8月14日に1本と、短い間隔で追加されています。稼働までにさらに追加・更新される可能性は高いと考えられます。

ENISAが追加公開する情報（FAQの更新、研修資料、運用上の告知）を追跡し、本記事の内容に変更があれば続報としてお伝えします。

なお、検証目的だけでSRPへ登録することはしません。ENISAが推奨していない運用でもあるため、画面については公開資料の範囲で扱います。

■ 要確認事項

本記事の内容は、2026年8月16日に筆者がENISA公開情報を確認した時点のものです。ガイダンスは短い間隔で更新されているため、実務判断の際は必ず一次情報で再確認してください。
引用した英文の日本語訳は筆者による趣旨の要約であり、公式訳ではありません。正確な内容は原文をご確認ください。
CRAの条文番号（第3条(42)、第3条(44)、第14条(5)、第16条(2)）は、ENISAファクトシートの記載に基づくものです。第3条(15)の authorised representative の定義はCRA本文（Regulation (EU) 2024/2847）によります。条文そのものの解釈については一次情報をご確認ください。
SRPのAPIについては、2026年8月3日更新のENISA FAQに「no Application Programming Interfaces will be provided at this stage（現段階ではAPIは提供されない）」とあります。社内の脆弱性管理システムから完全自動で提出することは、現時点ではできません。将来提供される可能性は残ります。

■ 本記事の取り扱いについて（免責事項）

目的： 本記事は、公開情報をもとに、lwIP搭載製品の担当者向けにCRA報告実務の要点を整理し、注意喚起・確認ポイントの整理を目的としています。
法的助言ではありません： CRAの条文解釈に関する法的助言ではありません。個別の義務の有無・報告要否・担当者の人選は、一次情報および法務・専門家の確認に基づいて行ってください。
自己責任： 対応の判断にあたっては、各社の事業形態・製品要件に基づき、利用者自身の責任において十分な確認を行ってください。
免責： 万一、本記事の情報に基づいて生じた損害やトラブルについて、筆者は一切の責任を負いかねます。

■ 最後に

今回のガイダンス公開で分かったことを、6点にまとめます。

SRPへの事前登録は推奨されていない。報告が必要になった時点で登録する運用（ただしEU Loginは事前に作成できる）
担当者を複数登録できるが、下書きは担当者間で共有されない。引き継ぎ用の情報はSRPの外に持っておく必要がある
担当CSIRTの承認は、報告義務の履行の前提条件ではない（メーカー追加時の未検証状態でも10件まで提出可能）
SRPの操作上、早期警告を提出しないと72時間通知を出せない。順序が要求される
最終報告を提出すると、その通知は編集できなくなる
報告対象は「現に悪用されている脆弱性」と「重大インシデント」。CVEの公開だけでは義務は発生しない

報告の手順は示されました。次に問われるのは、自社製品がその脆弱性の影響を受けるかどうかを、72時間以内に判断できる体制があるかです。

具体的な棚卸しの方法は、News #2｜CRAの72時間報告にlwIP製品は間に合うかにチェックリストとしてまとめています。

lwIPは無料で手軽に製品に組み込める反面、利用する際にはバージョンや設定、既知の問題を把握しておくことが重要です。
また、商用製品のような保証付きサポートが前提ではないOSSであるため、最終的にはメーカー自身で不具合や脆弱性に対応しなければなりません。
そのため対応コストが製品出荷後に増大するリスクについても考慮しておく必要があります。

OSSであるlwIPには多くの利点がありますが、長期保守やサポート体制が重要な製品では、商用スタックを選択するケースもあります。

ただし、すでにlwIPで開発中の製品や出荷済みの製品を今から置き換えることは現実的ではありません。
そういった方に向けて、本記事の情報が、

不具合や脆弱性の早期発見
原因特定の時間短縮
対応コストの低減

の参考になれば幸いです。

今後も、lwIPの問題に対して実用的な情報を公開します。