【lwIP】News #4｜lwIPの脆弱性、責任を負うのは誰か｜CRA正式ガイダンス公開が示す「製造者責任」

2026年7月29日 13:16

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

lwIPを組み込んだ製品をEU市場に出す場合、CRA上の責任を負うのはOSS開発者と完成品メーカーのどちらでしょうか。本記事は「News」として、欧州委員会とENISAの公開情報から、lwIP搭載製品の責任主体を整理します。制度の細目や条文解釈には専門判断を要する部分があり、その箇所は「要確認」と明記します。

■ 今回のニュース概要

欧州委員会は2026年7月27日、EU Cyber Resilience Act（CRA、サイバーレジリエンス法）の適用を支援する新しい実務ガイダンスを正式に公開しました。文書名は「Commission guidance on the application of the Cyber Resilience Act (CRA)」（整理番号 C(2026) 5252、本体とAnnexで構成）です。2026年3月3日に意見募集のため公開されていたガイダンス案（draft guidance）を踏まえた、欧州委員会による非拘束的な適用ガイダンスです。

このガイダンスは法令そのものを変えるものではなく、法的拘束力もありません。CRAの条文はそのままで、「どの企業がどの義務を負うか」を判断するための欧州委員会の手引きが追加された、という位置づけです。
ENISA（EUサイバーセキュリティ機関）の Single Reporting Platform（SRP）に関するFAQも、この正式ガイダンスを参照先として追加しています。
脆弱性・重大インシデントの報告義務は予定どおり2026年9月11日から開始されます。認識時点から24時間以内に早期警告、72時間以内に正式通知、脆弱性については修正・緩和策が利用可能になってから14日以内に最終報告、という期限に変更はありません（この報告義務まわりの実務は News #2 で詳しく扱っています）。

出典：欧州委員会「Commission publishes new guidance to support timely Cyber Resilience Act implementation」（2026年7月27日）、正式ガイダンスAnnex（C(2026) 5252）、欧州委員会「Commission publishes for feedback draft guidance ...」（2026年3月3日・ガイダンス案）、欧州委員会「CRA implementation FAQ」、ENISA「Single Reporting Platform (SRP)」、CRA本文（Regulation (EU) 2024/2847）。細目は今後変更され得るため、実際の判断前に一次情報での確認を推奨します（要確認）。

■ この記事のポイント：「OSSだから責任はOSS開発者」は誤解

今回のガイダンスで、lwIP搭載製品のメーカーにとっていちばん重要なのは、報告期限の話ではなく「誰が責任を負うのか」という点です。ここは実務でよく誤解されます。

よくある誤解は、次のようなものです。

「lwIP は無償のOSSだ」
「だから、脆弱性が見つかっても責任を取るのはlwIPの開発者だ」
「自社は"使っているだけ"だから、CRA上の重い義務は負わない」

CRAの考え方では、これは成り立ちません。自社の名義・商標で完成品をEU市場に投入する事業者（製造者＝manufacturer）が、その製品全体のセキュリティについて責任を負うのが基本構造です。製品の中で使っているのが自社製コードか、第三者のOSSかは、この責任を免れる理由にはなりません。

つまり、lwIPを組み込んだゲートウェイやIoT機器をEU市場に出す製造者は、lwIP由来の脆弱性についても自社製品への影響を判定し、CRAの要件を満たす場合には通知と利用者への情報提供を行う必要があります。

■ CRAにおける「立場」の区別

CRAは、事業者が製品との関わり方に応じて異なる立場（役割）を持つと整理しています。今回のガイダンスは、この立場の区別を判断するための手引きになります。主なものは次のとおりです。

製造者（manufacturer）：製品を開発し、自社の名義・商標でEU市場に投入する事業者。CRA上の中心的な義務（セキュリティ要件・脆弱性対応・報告など）を負います。
輸入者（importer）／販売者（distributor）：EU域外の製品をEUに持ち込む、あるいは流通させる事業者。製造者ほどではないものの、確認義務などを負います。
オープンソースソフトウェア・スチュワード（open-source software steward）：CRAが新たに設けたカテゴリ（義務はCRA第24条に規定）で、商用製品に使われるOSSの開発を持続的に支える法人などを指します。通常の製造者とは異なる軽量な制度ですが、サイバーセキュリティ方針の整備や当局への協力に加え、開発への関与や提供するインフラへの影響に応じて報告義務も適用されます。
非商用のOSS開発者：営利目的ではなくOSSを開発・提供する個人・コミュニティは、原則としてCRAの製造者としての義務の外に置かれる、というのが基本的な考え方です。

ここで重要なのは、lwIP のようなOSSそのものの開発者・提供者と、それを組み込んだ完成品をEU市場で販売するメーカーとは、CRA上の立場が別だという点です。前者が完成品に関する製造者義務を負う主体になるわけではありません。lwIPを組み込んだ製品を自社の名義・商標でEU市場に出す事業者は、原則として自社が製造者に当たります。

補足すると、OSS Steward はあくまで「商用製品に使われるOSSの開発を支える法人など」を想定した区分です。本記事の調査範囲では、lwIPについてCRA第3条(14)の要件を満たすOSS Stewardを一次情報から特定できていません。該当主体の有無は個別確認が必要です。いずれにせよ、lwIPを組み込んだ製品を自社の名義・商標でEU市場に出す事業者は、製造者として自社製品への影響を判定する必要があります。

なお、自社が「製造者・輸入者・販売者・OSS Steward」のどれに当たるかの正確な線引きは、事業形態によって判断が分かれ得ます。ガイダンス本文と、必要に応じて法務・専門家の確認を推奨します（要確認）。

■ 第三者コンポーネント由来の脆弱性は誰が報告するのか

「lwIPは第三者が作ったコンポーネントだから、そこの脆弱性はうちの報告対象ではないのでは」という疑問も、実務でよく出ます。ここも今回のガイダンス・FAQが手当てしている論点です。

ENISAのSRP FAQは、第三者コンポーネントに起因する脆弱性について、製造者が報告対象になるかを、欧州委員会のCRA FAQ（第5.4節「実際に悪用された脆弱性が第三者コンポーネントに含まれる場合」）で確認するよう案内しています。
また、製造者およびOSS Stewardの報告義務の詳細は、今回のガイダンスの point 9.1 に説明があると案内されています。

要点は、第三者のOSS（今回で言えばlwIP、あるいはlwIPを同梱するベンダーSDK）に由来する脆弱性であっても、その製品を市場に出した製造者の側で影響判定・報告の要否を検討する必要がある、ということです。ただし、脆弱なコードが自社製品では到達不能、または自社製品で実際に悪用されていない場合、その完成品の製造者に当該脆弱性の報告義務は生じません。

また、その第三者コンポーネント自体が別個の製品としてEU市場に投入されている場合は、コンポーネント側の製造者にも通知義務が生じ得ます。完成品メーカーだけが排他的な報告主体になるわけではありません。実際の判断にあたっては、欧州委員会FAQ第5.4節とガイダンスpoint 9.1の条件を直接確認してください（要確認）。

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

ここまでを、lwIPを使う製品の担当者の視点でまとめると、次のようになります。

lwIP由来の脆弱性であっても、完成品の製造者は監視・影響判定を行い、CRAの要件を満たす場合には必要な通知と利用者対応を行う。「OSSだから対応は誰か他の人がやってくれる」という前提は成り立たない。
したがって、「自社製品が、どのlwIP（upstream か、ベンダーSDK同梱か）を、どのバージョンで、どの機能を有効にして使っているか」を、脆弱性の一報が来る前に把握しておくことが、そのまま報告義務への備えになる。
特に、ベンダーSDKが upstream lwIP に独自の改変・追加を加えている場合、upstream の情報だけでは影響有無を判断できない。この具体例は、ESP-IDF独自のDHCPサーバー実装で見つかった脆弱性（CVE-2026-45160）を扱った News #3 で解説しています。

言い換えると、CRAの報告義務は「制度の話」に見えて、実際には「自社製品のlwIP構成を棚卸しできているか」という、きわめて実務的な準備に落ちてきます。

■ では、何を準備すればよいか

「72時間以内に影響判定して報告」に間に合わせるために、製品担当者が今から整備しておくべき情報（製品ごとのlwIPバージョン・ベンダーfork・有効機能・到達可能性など）は、News #2｜CRAの72時間報告にlwIP製品は間に合うかに「準備5項目」のチェックリストとして整理しています。本記事と合わせて確認してください。

また、実際に脆弱性が出たときに「自社は対象か・対象外か」を切り分ける具体例は、本シリーズの各記事で扱っています。

SNMP（SNMPv3）を有効にしているか：認証情報を持たない相手からの1パケットで固定長スタックバッファをはみ出す脆弱性（CVE-2026-8836、詳細は Bug #6）。
DHCPクライアントを使っているか：トランザクションID（XID）が予測可能になり得る問題（詳細は Bug #3）。
ESP-IDFで独自のDHCPサーバー（SoftAP等）を使っているか：受信データの外側を読むOut-of-Bounds Read（CVE-2026-45160、詳細は News #3）。

これらは「どの機能を有効にしているか」が分かっていれば、脆弱性の一報に対して短時間で影響有無を切り分けられます。逆に、機能構成を把握できていないと、報告のたびに一から調べ直すことになります。

■ 要確認事項

本記事は、欧州委員会のガイダンス公開（2026年7月27日）とENISA SRP FAQの案内内容を整理したものです。ガイダンス本体（C(2026) 5252 本文・Annex）、および欧州委員会CRA FAQの第5.4節・ガイダンス point 9.1 の具体的な条文・条件は、一次情報で直接確認してください。
自社が製造者・輸入者・販売者・OSS Stewardのどれに該当するか、また個別の製品・脆弱性が報告対象に当たるかの判断は、事業形態や事実関係により異なります。最終的な判断は法務・専門家への確認を推奨します。
報告義務の開始日（2026年9月11日）・報告期限（24時間／72時間／14日）は、記事執筆時点の公開情報に基づきます。

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

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

■ 最後に

今回は、欧州委員会が公開したCRA適用ガイダンスを起点に、「lwIPの脆弱性の責任は誰が負うのか」という論点を整理しました。要点は、lwIPがOSSであっても、完成品の製造者はlwIP由来の脆弱性について自社製品への影響を判定し、CRAの要件を満たす場合には必要な通知と利用者対応を行う、という点です。だからこそ、自社製品のlwIP構成を事前に把握しておくことが、そのままCRA対応の備えになります。

本シリーズでは今後、第三者コンポーネント（lwIPやそれを同梱するベンダーSDK）の脆弱性が公表されたときに、製造者がどのように影響判定を進めればよいかを、SDK別のCVE影響整理を例に取り上げていく予定です。

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

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

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

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

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

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