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

この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の登録ガイダンスは、これを勧めていません。

原文はこうです。

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

つまり、報告が必要になった時点で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人という体制は、組み込み機器のメーカーでは珍しくありません。報告の起点は「報告対象となる悪用または重大インシデントを、製造者が認識した時点」であり、担当者の在席状況を待ってくれません。バックアップの担当者を登録できる仕組みがあるのは、この点で意味があります。

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

（ダッシュボードに表示される下書きの通知は自分が作成したものだけであり、同じメーカーに紐づく他の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時間以内に早期警告を出さなければならないのに、承認待ちで止まったら間に合いません。

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

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

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

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

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

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

なお、この記載は画面機能ガイダンスの「Add an Association with an Additional Manufacturer」の節に置かれています。

【2026年9月2日 追記】ENISA公式FAQに「20通知」の記載があります

本記事の公開後、ENISAのSRP公式FAQ（ENISA CRA SRP Frequently Asked Questions）が2026年8月31日付で更新され、未検証のARについて次の記載が加わりました。

（検証が済んでいないARは、検証が必須になる前に、1つのメーカーについて最大20件の通知を提出できる、という趣旨）

画面機能ガイダンスの10件と、FAQの20件は、この時点では記載が一致していませんでした。（この不一致はその後解消されています。後述の【2026年9月11日 追記】をご覧ください）

10件のほうが「Add an Association with an Additional Manufacturer」の節に置かれていることは確認できます。ただし、節の位置だけでは、その上限が追加メーカーの場合にのみ適用されると断定できません。 考えられるのは次のいずれかですが、公開文書だけでは判別できませんでした。

• 対象範囲が異なる2つの上限である

• 画面機能ガイダンス側の記載が更新されておらず、古い数字が残っている

• FAQによって上限が変更された

この数字を「法定通知をここまでしか出せない上限」として扱わないでください。 未検証の状態で多数の通知が必要になりそうなら、件数を抑える方向ではなく、上限に近づく前にENISAまたは担当CSIRTへ適用関係を照会し、検証を進めるのが実務上の対応になります。

【2026年9月11日 追記】10件と20件の不一致は解消されました。両方とも20件です

SRPの稼働開始日にあたる2026年9月11日、上記2つの文書を改めて取得したところ、画面機能ガイダンス側の数字が10件から20件へ変わっており、不一致は解消されていました。

画面機能ガイダンス（CRA SRP guidance - AR Interface functions、`Last updated: 09 September 2026`）の記載です。

（「未検証」のARとして、最大20件の通知を提出できる、という趣旨）

公式FAQ（ENISA CRA SRP Frequently Asked Questions、`Updated: 11 September 2026`）の側も、文言が次のように書き換わっています。

（メーカーとの関連付けがまだ検証されていないARは、検証が必須になる前に、そのメーカーについて最大20件の通知を提出できる、という趣旨）

つまり、未検証のARが提出できる通知は、1つのメーカーにつき最大20件と読むのが現在の記載です。上の「考えられるのは次のいずれか」で挙げた3つのうち、画面機能ガイダンス側に古い数字が残っていたという可能性が実際に近かったことになります。

なお、10件という数字が9月9日の更新で消えたのか、それ以前の更新で消えたのかは、旧版の保存が見つからなかったため特定できませんでした。本記事が10件として引用したのは、2026年8月14日更新版の記載です。

同じFAQには、担当者の人数についての記載もあります。

（1つのメーカーにつきPrimary ARは1名のみ、Secondary ARは最大20名まで、という趣旨）

ポイント2で扱った担当者の体制は、Primary AR 1名＋Secondary AR 最大20名という形で人数の上限まで示されたことになります。なお、FAQのこの記載は下書きの共有可否には触れていません。少なくとも筆者が確認した画面機能ガイダンスでは、他のARが作成した下書きは閲覧できないとされています。人数を増やす場合も、引き継ぎ用の情報はSRPの外に持っておくことになります。

■ ポイント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：最終報告を出すと、後から直せなくなります

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

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

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

脆弱性の場合、最終報告の期限は「修正・緩和策が利用可能になってから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公開時に実務上まず必要なのは、報告ではなく影響判定です。CVEの公開だけを起点とする24時間・72時間の報告期限は、本記事で確認した資料には示されていません。 ただし、実際に悪用を認識してから動き出すのでは、24時間の早期警告に間に合いません。平時のうちに影響判定ができる状態にしておくことが、ポイント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加盟国へ一斉に伝わるわけではない、ということです。ただしこれは報告する側の義務には影響しません。担当CSIRTから他国のCSIRTへ展開される時期は、製造者に適用される提出期限を変えるものではありません。

■ 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が推奨していない運用でもあるため、画面については公開資料の範囲で扱います。

■ 要確認事項

• 本記事の内容は、3本のガイダンスとファクトシートを2026年8月16日、追記したFAQを2026年9月2日、提出上限の追記を2026年9月11日に、筆者が確認した時点のものです。ガイダンスは短い間隔で更新されているため、実務判断の際は必ず一次情報で再確認してください。

• 引用した英文の日本語訳は筆者による趣旨の要約であり、公式訳ではありません。正確な内容は原文をご確認ください。

• 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の承認は、報告義務の履行の前提条件ではない。未検証時の提出上限は、1つのメーカーにつき20件（公開当初は画面機能ガイダンスの10件とFAQの20件が食い違っていたが、2026年9月11日時点では両方とも20件で一致している）

• SRPの操作上、早期警告を提出しないと72時間通知を出せない。順序が要求される

• 最終報告を提出すると、その通知は編集できなくなる

• 報告対象は「自社製品に影響する脆弱性が現に悪用されていること」と「重大インシデント」。それを製造者が認識した時点が起算点であり、CVEの公開だけでは義務は発生しない

報告の手順は示されました。次に問われるのは、自社製品がその脆弱性の影響を受けるかどうかを、24時間の早期警告に間に合う範囲で判断でき、72時間の通知に向けて初期評価を更新していける体制があるかです。

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

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

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

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

• 不具合や脆弱性の早期発見

• 原因特定の時間短縮

• 対応コストの低減

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

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

関連記事・新着のお知らせ

lwIPの不具合・脆弱性の記事は、症状ごとに継続して追加しています。自社が使っている機能に関わる脆弱性が出たときに気づけるよう、下のマガジンをフォロー・ブックマークしておくことをおすすめします。

• lwIPの不具合・脆弱性の記事一覧（症状から探せます）：lwIPトラブル対策室｜日本語記事一覧

• CRAの72時間報告への実務準備（準備5項目）：News #2｜CRAの72時間報告にlwIP製品は間に合うか

• lwIPの脆弱性の責任は誰にあるのか：News #4｜lwIPの脆弱性、責任を負うのは誰か

• 脆弱性情報にいつ気づけるのか：News #5｜lwIPの脆弱性に気づけるのはいつか