日本の届け先 — 早期警戒パートナーシップ

「止まった。では、どこへ伝えればいいのか」。前の章の続きです。幸い、日本には個人が一人で抱えなくて済む公式の枠組みがあります。

情報セキュリティ早期警戒パートナーシップ

日本では、脆弱性の届出を受け付け、開発者へ橋渡しする情報セキュリティ早期警戒パートナーシップという制度が運用されています。大づかみに、役割はこう分かれています。

この枠組みのありがたさは、あなたが攻撃者にも交渉人にもならなくて済むことです。見つけた人が、直接相手に乗り込んで「穴があるぞ」と迫る必要はありません。第三者機関を挟むことで、感情的な対立や、脅迫と誤解される事故を避けられます。

大きな流れ

制度の細部は公式に譲りますが、流れの骨格はこうです。

1. 届出 — 発見者が、脆弱性の情報(対象・再現手順・影響)を受付(IPA)へ届け出る。
2. 受理・確認 — 内容が確認され、対象の開発者・運営者へ調整機関(JPCERT/CC)経由で連絡される。
3. 修正 — 開発者・運営者が修正する。必要な期間が確保される。
4. 公表 — 修正の状況を踏まえ、必要なら調整のうえで公表される。

サイト運営者側の窓口も見ておく

相手が自社サービスや個人開発のサイトなら、そのサイト自身にセキュリティ連絡先が用意されていることもあります。近年は、連絡先を機械可読で示す security.txt(サイトの /.well-known/security.txt に置かれるテキスト)という慣行も広がっています。報告する前に、

• 相手のサイトに「セキュリティに関するお問い合わせ」窓口や security.txt があるか、
• 無ければ、早期警戒パートナーシップの届出を使うか、

を確認するのが実務の順序です。いずれにせよ、正規の連絡経路を使い、いきなり本番システムを叩かない——これが芯です。

持ち帰る一言

一人で抱えず、直接攻撃せず、正しい窓口へ。 日本には IPA 受付・JPCERT/CC 調整の枠組みがあり、届出 → 調整 → 修正 → 公表の順で進みます。発見者の役割は「最初の一報」まで。次の章は、その一報を相手が動ける形にする——良い報告書の要素を見ます。