Hello there, ('ω')ノ
✅ よくある“伝わらない報告”の例
| 報告 | 開発者の反応 |
|---|---|
| 「XSSの脆弱性があります」 | 「……XSSってWebの話じゃないの？」 |
| 「パーミッション昇格のリスクあり」 | 「危険なのは分かるけど、コードのどこ？」 |
| 「暗号鍵が平文で埋め込まれている」 | 「それ、誰にでも見える状態なんですか？」 |
→ こうしたギャップは、診断者が“伝え方”を間違えているケースが多いです。
✅ 報告の基本構成：5つの柱
開発者への報告は、次のような構成がわかりやすく効果的です：
① 脆弱性の名前（分かりやすく簡潔に）
例：「外部からインテントを受け取るExported Activityにアクセス制限がない」
② どこにあるか（画面名・ファイル名・クラス名など）
com.example.app.ui.LoginActivityがexported=trueのまま公開されています。
③ 何ができてしまうか（影響）
他アプリから意図せずこの画面を呼び出され、ログインバイパスが可能になります。
④ 再現方法（手順付き）
Drozerで次のように実行し、該当のアクティビティが起動することを確認：
run app.activity.start --component com.example.app/.LoginActivity
⑤ 修正案（選択肢があれば複数）
- AndroidManifest.xml の該当Activityに
android:exported="false"を明記- インテント受信時に
checkCallingPackage()で呼び出し元を検証
✅ 伝える際のトーンの工夫
| NG例 | 改善例 |
|---|---|
| 「この実装は危険です」 | 「この実装は、悪意あるアプリからのアクセスを受ける可能性があります」 |
| 「重大なミスです」 | 「セキュリティ上の懸念があるため、優先的な対応をおすすめします」 |
| 「このコードが間違っています」 | 「この部分の処理は、想定外の動作を引き起こす可能性があります」 |
→ 診断者は**“攻める人”ではなく、“支える人”**であるべきです。
🧩 報告形式のベストプラクティス
| 方法 | 説明 |
|---|---|
| Markdown形式の報告書 | 開発者に読みやすく、チケット化しやすい |
| 添付資料で再現コードを提供（安全に） | FridaやBurpでの実行例は別ファイル化 |
| 画面キャプチャ付きのレポート | UIに関わる問題は“見える形”で伝えると効果的 |
| Jiraなどの管理ツール連携 | 報告書からそのままタスク化できると改善が早い |
✅ “伝える相手”を意識することが重要
| 相手 | 重視すべきポイント |
|---|---|
| アプリ開発者 | コード修正方法の明示・再現方法の簡潔さ |
| PM・責任者 | 影響範囲と対応優先度（ビジネスへの影響） |
| 情報システム部門 | ポリシー・再発防止策・他のアプリへの波及リスク |
✅ まとめ
- 開発者への報告は「技術情報の翻訳」としての役割がある
- 再現可能性と修正方法がセットで伝わってこそ、“価値ある報告”になる
- 誤解や対立を防ぐために、やさしいトーンと明確な根拠を大切に
- 「脆弱性を見つけて終わり」ではなく、“直してもらって初めて仕事が完了”
Best regards, (^^ゞ
