Hello there, ('ω')ノ
✅ アプリのバージョンが変わると何が変わる？
| 変更箇所 | 例 |
|---|---|
| コードのロジック | 認証処理の変更、バリデーションの強化・弱体化 |
| 使用ライブラリ | 新しいSDKの導入、古いライブラリの置き換え |
| 設定ファイル | AndroidManifest.xml のパーミッション変更 |
| UI/UXの導線 | 設定画面の場所が変わり、特定の操作がしづらくなる |
| ビルド構成 | debug/releaseの設定、Proguard（難読化）の有無 |
👉 つまり、「前に診断した結果が、最新版にもそのまま当てはまるとは限らない」ということです。
✅ よくあるバージョン関連の“再現性トラブル”
| 状況 | 原因 |
|---|---|
| テストでは再現できたが、本番ではできない | テスト端末のアプリが旧バージョンだった |
| 昔の脆弱性報告に対し「再現しない」と開発者に言われる | 診断時と異なる最新版を参照していた |
| 修正されたはずの脆弱性が再発していた | 別のブランチや古いビルドから派生したコードで復活していた |
✅ 再現性を保つために必要なチェックポイント
📦 1. APKのバージョン情報を記録する
# ADBを使った確認例 adb shell dumpsys package com.example.app | grep version
- versionName / versionCode を必ず記録
- 診断報告書にも明記しておく（例：「診断対象：v1.4.2（code: 142）」）
📑 2. 診断時のAPKハッシュ値を残す
sha256sum app-release.apk
- APKの内容が変更されていないことを保証するため
- 開発チームと同一ファイルを見ていることを確認できる
🧾 3. 変更履歴（changelog）を開発側から取得する
- 何が変わったのか（コード？SDK？設定？）
- 脆弱性関連の変更が含まれているか
👉 小さな修正に見えて、セキュリティ上は大きな影響があることも！
✅ 診断観点：過去バージョンも含めたアプローチ
| 観点 | 内容 |
|---|---|
| リリース済みの旧バージョンの診断 | まだインストール中のユーザーがいる可能性 |
| バージョン別に脆弱性が変わる場合 | 修正済と思ったら、旧バージョンだけ修正漏れという例も |
| 継続診断時に差分チェック | CI/CDで自動検出できる仕組みが望ましい |
✅ MobSFなどを使ったバージョン差異の可視化（応用編）
- MobSFでは、APK単位で脆弱性スコアを比較可能
- 過去バージョンと新バージョンの診断結果差分をレポートで出すこともできる
- バージョンごとに 危険度の上下をグラフ化 → レビューに活用可能
Best regards, (^^ゞ
