責任ある開示 — 穴を見つけたあと

学びが進むと、いつか自分の実習環境の外で、何かの「気配」に気づくことがあります。よく使うサービスの挙動が妙だ、URL を少しいじると見えてはいけなさそうなものが見えた気がする——。そのときにどう振る舞うかで、あなたが診断エンジニアとして信頼される人かどうかが分かれます。この章は、その作法の話です。

まず、やってはいけないこと

気づいたときに、つい手が動きそうになることこそ、やってはいけないことです。

• 「本当に穴か」を確かめるための追加攻撃をしない。 第1章のとおり、他人のシステムへの承諾なきアクセスは不正アクセスになりえます。「善意で確かめただけ」は理由になりません。
• SNS などで先に公表しない。 直っていない穴を公表することは、攻撃者に地図を配ることになります。
• データを持ち出さない・保存しない。 見えてしまった他人の情報を保存すれば、それ自体が別の問題になります。

責任ある開示という枠組み

見つけた側が、直せる立場の人(サービスの運営者やメーカー)に、まず静かに伝える。運営者が直すための時間を確保し、直ってから必要に応じて公表する。この流れを一般に責任ある開示(Coordinated / Responsible Disclosure)と呼びます。

日本には、これを制度として支える仕組みがあります。IPA(情報処理推進機構)が窓口となる脆弱性関連情報の届出制度です。ソフトウェアや Web サイトの脆弱性を見つけた人が IPA に届け出ると、IPA と JPCERT/CC が調整役となって、開発者に連絡し、修正と公表の段取りを整えます。制度の詳細は IPA の公式サイト(ipa.go.jp)で確認できます。

模擬報告を書いてみる(外部には送りません)

作法は、一度書いてみると身につきます。ただし——

自作のやられアプリで見つけた穴を題材に、次の型で下書きを作ってみてください(そのまま報告書のコースにもつながる骨格です)。

項目	書くこと(例・すべて架空)
対象	自作の練習用アプリ「架空メモ帳」v0.1(自分の 127.0.0.1 で稼働)
種類	反射型XSS(コメント欄)
再現手順	1. コメント欄に特定の入力を送る 2. 表示時にスクリプトが動く
影響	閲覧者のブラウザで任意のスクリプトが動きうる
修正案	出力時にエスケープする/textContent で描画する

この下書きは、あなたのメモとして手元に置くだけで十分です。実在の第三者や窓口に向けて送らない——それが、この章のいちばん大事なルールです。

この章のまとめ

穴に気づく力がつくほど、その力をどう使うかが問われます。責任ある開示の芯は、「攻撃して確かめる」誘惑をこらえ、直せる人に静かに渡すこと。そして練習は、必ず自作環境と自分用の下書きの中で完結させること。次の最終章で、実習前に毎回見返すチェックリストにまとめます。