御盾結論と決定条件
- 同名のインストーラーを単に提出するのではなく、そのソース、バージョン、ファイルダイジェスト、署名計画、および想定される配布チャネルを記録する必要があります。
- 単に「最大強度」を要求するのではなく、どのロジックがリバースエンジニアリングまたは改変された場合に、具体的なビジネス損失を引き起こすかを特定してください。
- 技術スタックには、使用言語、ビルドシステム、最低 OS バージョン、ABI、ネイティブコンポーネント、動的ローディング、クロスプラットフォームフレームワーク、およびサードパーティ SDK を含める必要があります。
- PoC 開始前に、成功・失敗・未カバー範囲・停止・ロールバックの各条件を定義し、起動成功をリリース準備完了と誤認しないようにしてください。
まず一意に識別可能なリリース候補を提供してください
リリース候補は、後続の設定、テスト、結論における共通対象です。最低限、パッケージ名または Bundle ID、バージョン、ビルドソース、ファイル SHA-256、現在の署名状況、目標署名計画、および想定される配布チャネルを提供してください。ファイル配送が一時的に不可能な場合は、プロジェクトがアーキテクチャ設計、開発、統合、あるいはリリース準備のどの段階にあるかを明確に記載してください。
同名のファイルが同一アーティファクトであることを意味しません。再ビルド、再署名、チャネルリソースの変更、または依存関係の置き換えは、新しいアイデンティティを生成します。変更ごとにどの検証を再実行すべきかを特定し、古い候補からの合格結論を新しいファイルに直接適用しないでください。
専有コードやユーザーデータ涉及時は、中央 Yudun プラットフォーム上の管理されたプロジェクトワークフローを通じて提出してください。公開トピックサイトは手法とエントリーポイントのみを提供するものであり、アカウント、インストーラー、証明書、またはプロジェクト機密の受け付けは行いません。
| 項目 | 記載例 | 目的 | 一般的な不備 |
|---|---|---|---|
| アプリケーション ID | パッケージ名またはバンドル ID、バージョン | リリース、アップグレード、テスト範囲への紐付け | ストア名のみの記載 |
| ファイル ID | SHA-256 ハッシュと生成時刻 | すべての証拠が同一ファイルを指していることを保証 | 同名ファイルによる上書き |
| ビルドソース | ブランチ、コミット、CI ジョブ、またはリリース記録 | 問題のトレースバックと再ビルド | ソースの特定不可 |
| 署名計画 | 現状、最終証明書、および署名手順 | アップグレードおよびリリース ID の検証 | PoC 後の任意の再署名 |
| 配布範囲 | ストア、企業、またはプライベートチャネル | 完全性シグナルと配信チェックの決定 | 全チャネルが同一であるという誤った前提 |
保護が必要なコードに関するビジネス損失の定義
「最大強度」「完全保護」「クラック防止」といった表現は実行可能な要件ではありません。コアアルゴリズム、認可チェック、プロトコル処理、コンテンツ権利、モデル、または重要なローカル判断を列挙し、それらが解読、複製、改変、またはバイパスされた場合に発生する具体的な損失を説明してください。
同時に、このロジックがクライアント側に残る必要がある理由を説明してください。サーバー側で処理可能な高リスクな認可はまずサーバーで判定し、オフライン機能、低遅延、またはプラットフォームネイティブ機能を要する経路についてのみクライアント側保護を検討すべきです。これにより、VMP（仮想化保護）は実行表現の変更が真に必要なコードに限定して適用されます。
各アセットには所有者、関数呼び出しのエントリポイント、実行頻度、スレッドコンテキスト、入出力定義、依存関係、および失敗時のフォールバックを明確にする必要があります。独立した受入経路を持たないアセットは、その価値にかかわらず、まずテスト条件を追加しなければなりません。
| アセットタイプ | 記述すべき損失 | クライアント側必須性の根拠 | 推奨される受入準備 |
|---|---|---|---|
| 認可と権利 | ローカル分岐がバイパスされた場合にアクセス可能となるリソース | オフライン機能または高速なローカル判定 | 通常、有効期限切れ、改ざん、サーバー再検証の状態 |
| コアアルゴリズム | 複製による商業的価値の喪失 | オンデバイスでの性能、プライバシー、またはオフライン要件 | 入出力の一貫性、性能、および境界値データ |
| プロトコルと鍵の使用 | リプレイ、改ざん、または大量悪用が発生した場合の影響 | デバイス紐付けまたはローカル通信 | エラー処理、リプレイ検知、キーローテーション、およびサーバー側制限 |
| オンデバイスモデルまたはルール | モデル、プロンプト、または後処理の複製と改変 | オフライン動作、プライバシー、または低遅延の要件 | バージョンペアリング、読み込み、ロールバック、およびログ記録 |
| 重要なサードパーティインターフェース | SDK のバイパスまたは誤った関数呼び出しが発生した場合の影響 | プラットフォームまたはチャネルの要件 | 実アカウント、署名、およびコールバックパス |
技術スタックの棚卸しが適合性テストの範囲を定義する
Android プロジェクトでは、Java、Kotlin、NDK、Gradle、Android Gradle Plugin のバージョン、minSdk、targetSdk、リリース済み ABI、およびリフレクション、シリアライゼーション、動的クラス読み込み、ホットフィックス、プラグイン化、WebView、ネイティブコンポーネント、マルチプロセスアーキテクチャの使用状況を明記する必要があります。iOS プロジェクトでは、Swift、Objective-C、最低 OS バージョン、拡張機能、動的ライブラリ、ランタイム特性、および署名機能を明記する必要があります。
Flutter、React Native、Unity、Cocos、またはその他のクロスプラットフォームフレームワークを使用する場合、フレームワークバージョン、ブリッジング手法、エンジン、およびビジネスロジック用のネイティブライブラリを記録してください。「クロスプラットフォーム」と一概に記述しないでください。アーティファクト構造、起動挙動、サードパーティ統合はバージョンによって大きく異なるためです。
サードパーティ製ログイン、決済、プッシュ通知、地図、音声/動画、分析、リスク制御、ホットフィックス、ベンダーサービスは、リフレクション、署名、Manifest エントリ、URL スキーム、JNI、リソース、または独自の完全性チェックに依存している可能性があります。これらを初期評価段階で完全に列挙しておけば、クラッシュ発生後に一つずつ推測するよりも時間を節約できます。
- 言語、ビルドシステム、および主要プラグインのバージョン
- 最低および対象 OS、デバイス、ABI
- ネイティブコンポーネント、JNI、動的読み込み、およびクロスプラットフォームフレームワーク
- マルチプロセス、WebView、ホットフィックス、およびプラグイン化
- 重要 SDK：ログイン、決済、プッシュ、音声/動画など
PoC 実施前に署名、チャネル、アップグレード計画を明確化する
PoC アーティファクトが使用する署名、本番リリースの署名担当者、チャネルリソースの処理タイミング（署名前か署名後か）、Play App Signing の有無、および iOS の配布方法を特定してください。これらの要素はインストール、アップグレード、完全性シグナル、最終的なファイル識別子に影響を与えます。
Android は公式に、アプリ署名キーがアップデートを同一の鍵保有者から発行されたことを確認すると明記しています。PoC で一時証明書を使用する場合、検証対象はその特定の環境に限られ、オンライン版のカバレッジを自動的に証明するものではありません。正式な承認には、認可およびセキュリティワークフローで許可され、リリースチェーンと整合性のある署名計画が必要です。
チャネル処理は固定順序に従う必要があります。最終署名後にパッケージ本体を変更すると署名が無効化され、承認後の再ビルドや再署名は新たな候補版を生成します。ロールバック版についても、事前に署名、バージョン番号、データ移行、および上書きアップグレードの検証を実施しなければなりません。
| 質問 | 重要性 | 許容される PoC の状態 | 正式な承認要件 |
|---|---|---|---|
| 最終署名を実行するのは誰か？ | 鍵の責任所在とアーティファクトの識別性を決定する | 制限事項を明確にした一時署名 | 正式プロセスと整合し、監査可能であること |
| チャネル向けのパッケージ本体変更はいつ行うか？ | 変更によりファイルおよび署名対象コンテンツが変化する | 順序を説明可能であること | 署名前に完了し、識別性を再固定すること |
| オンライン版をどのようにカバレッジするか？ | 署名とバージョンの連続性を検証する | スキップ可能だが、未カバーとして明示すること | 実稼働のオンライン版からのアップグレード |
| どのようにロールバックするか？ | インシデント発生時に実行可能であること | ベースライン候補版を準備する | 担当者を割り当て、事前検証済みのロールバックパッケージ |
PoC の成功・失敗・停止条件を事前に定義する
PoC は単にインストール可能なハードニング済みパッケージを生成することではありません。観察対象の保護範囲、静的な曝露面、起動挙動、重要な業務フロー、パフォーマンス予算、対象システム、ABI、サードパーティ SDK、インストール/アップグレード、および例外時のフォールバックを事前に決定してください。プロジェクトごとに重み付けは異なりますが、いずれも定義を欠くことはできません。
成功条件は測定可能である必要があります。具体的には、鍵入力/出力の一貫性、対象システムにおける各項目の合格、プロジェクト予算内の起動変化、安全な例外パス、および追跡可能な保護設定などです。失敗条件には、起動ブロック、重要な業務エラー、許容できないパフォーマンス変化、対象範囲内での互換性障害、または原因特定不可能な問題が含まれます。
停止条件はスコープの闇雲な拡大を防ぎます。候補 ID の不整合、ベースラインの欠落、重要ログの未入手、署名ワークフローの未確認、またはテスト環境とリリーススコープの不一致がある場合は、続行前にこれらのギャップを解消してください。
| ステータス | 意味 | 報告要件 | 公開可能か |
|---|---|---|---|
| 検証済み | 合意されたスコープ内で同一候補に関する証拠が取得された状態 | 手法、環境、結果、および境界を明記すること | 判断の有効性は当該スコープに限定される |
| 失敗 | 再現可能なブロック発生または予算不適合が発生した状態 | 最初の差異とその影響を保持すること | 元の構成では公開不可 |
| 未実施 | デバイス、アカウント、データ、または認可が不足している状態 | 理由と次のステップを記載すること | 他の結果で代替することはできない |
| 該当なし | プロジェクトにおいて本プラットフォームまたは機能が明示的に除外されている状態 | 判断の根拠を提供すること | 現在のスコープから除外 |
project_stage: release-candidate
artifacts:
baseline: identified
protected_candidate: pending
assets:
- entitlement-decision
- protocol-core
stack:
platform: Android
min_os: project-defined
abis: [arm64-v8a]
critical_journeys:
- cold-launch
- sign-in
- protected-operation
acceptance:
functional_parity: required
performance_budget: project-defined
compatibility_matrix: required
rollback_rehearsal: required
boundaries:
- no_unverified_attack_resistance_claim
- uncovered_devices_remain_open全データ提出後に Yudun 評価により形成される成果物
完全な入力により 3 つの連続フェーズをサポートします。第 1 フェーズでは資産、技術スタック、リリースチェーンを確認し、初期保護スコープとリスクリストを策定します。第 2 フェーズでは追跡可能な PoC を生成し、同一候補 ID に対して静的およびランタイムチェックを実行します。第 3 フェーズでは結果に基づきスコープを調整し、対象マトリクス、リリース境界、およびロールバック条件を確定します。
具体的な保護機能、プラットフォーム対応、性能予算、および納期は実プロジェクトに対して確認する必要があります。本ページには顧客事例、合格率、または一般的な性能数値は一切掲載せず、リリース候補なしに最終結果を保証するものではありません。
ログイン、登録、アプリケーション、価格設定、およびプロジェクトデータは中央の Yudun プラットフォーム内で統合されます。トピックサイトではアカウント体系や申請システムを二重に構築しません。プロジェクト開始後に候補 ID やリリーススコープの追加補足を繰り返さないよう、提出前に本チェックリストに従って資料を整理してください。
- 追跡可能なリリース候補、ベースライン、およびリリースチェーン
- 保護対象資産とビジネス損失の明確な記述
- 完全な技術スタック、サードパーティ依存関係、および対象マトリクス
- 成功・失敗・未カバー範囲・ロールバック条件の定義
- 機密データは中央プラットフォーム経由でのみ提出すること
証拠と適用可能性の境界
このセクションでは、文書化されたプラットフォームの事実、技術的な判断、および未検証の製品主張に一般化できない制限を分けて説明します。
| 条文判決 | 事実または工学的根拠 | 適用制限 |
|---|---|---|
| リリース候補 ID は評価証拠における共通主キーです。 | 再ビルド、署名、チャネル変更、および依存関係の変更は、最終ファイルと実行時の動作に影響を与える可能性があります。 | SHA-256 はファイルを識別しますが、ファイルの安全性を保証するものではありません。 |
| VMP 保護の対象は、ビジネス損失の評価と脅威モデリングに基づいて決定する必要があります。 | OWASP MASVS では、リバースエンジニアリング対策と改ざん検知を、特定の脅威に対する多層防御の一環として扱い、サーバー側ロジックや全体アーキテクチャの代替とはみなしません。 | 規格を満たしていることだけで、特定のリリース候補や構成が合格したことを証明することはできません。 |
| 署名とアップグレードの計画は、正式な受領検査においてクローズドループで管理されなければなりません。 | Android ではアプリ署名 ID を使用してアップデートの連続性を確認し、Apple プラットフォームでも実行可能コードがコード署名チェーンに従うことが求められます。 | 配布方法の違いや証明書ローテーション戦略は、プロジェクトごとに検証する必要があります。 |
| インストールおよび起動の可否だけでは、PoC（概念実証）の結論としては不十分です。 | リリースには、重要なビジネスフロー、パフォーマンス、システム、ABI、サードパーティ連携、アップグレード、監視、ロールバックなど多数の要素が含まれます。 | プロジェクトでは実際のユーザー範囲に基づいて評価項目を削減できる場合がありますが、未カバーの項目は明示的に記載する必要があります。 |
| トピックサイトでは、機密性の高いプロジェクトデータを受け付けていません。 | アカウント、アプリケーション、プロジェクトデータはすべて中央の Yudun プラットフォームで一貫して処理され、コンテンツサイトは公開メソッドとリダイレクトのみを提供します。 | 具体的なデータ権限と保持ルールは、中央プラットフォームおよびプロジェクト契約に準拠します。 |
エンジニアリングに関する質問
ソースコードなしで APK のみを使用して評価を申請できますか？
アーティファクトと対象を最初に確認することは可能ですが、保護設定、問題の帰属判定、再ビルド機能には制限が生じる場合があります。ビルド協力、シンボルファイル、テストアカウント、ベースラインの提供可否を事前に明確にする必要があります。
初回連絡時に正式な署名を提供する必要がありますか？
必ずしも必要ではありません。部分的な PoC には制御されたテスト署名を使用できますが、これがオンラインアップグレードや正式な署名チェーンを表すものではないことを明確に明記する必要があります。正式な受領前にリリース計画を完了させる必要があります。
なぜすべてのサードパーティ SDK をリスト化する必要があるのですか？
サードパーティ SDK は、リフレクション、署名、リソース、JNI、初期化順序、または独自の整合性チェックに依存する場合があり、互換性問題の主要な原因となります。
すぐに最大強度の保護を要求できますか？
リスク選好を表明することは可能ですが、最終的なスコープはビジネス価値、実行頻度、ブラスト半径、および回帰テストの能力に基づいて階層化する必要があります。そうでなければ、安定したリリース結論を導き出すことは困難です。
本記事に記載されているデータを、トピックサイト経由で直接アップロードすることは可能ですか？
いいえ。トピックサイトでは公開コンテンツのみ提供しています。ログイン、登録、アプリケーション申請、およびプロジェクトデータについては、すべて中央の Yudun プラットフォームへリダイレクトして処理する必要があります。
独自のアプリでこれをテストしてみませんか?
Yudun PoC と互換性評価のために、リリース候補、ターゲット システム、重要なビジネス パスを提出します。