Triage & Validation: Gate Definitions

This skill defines the validation gates used by the validator agent and the /validate and /triage commands. Every finding must pass all gates before becoming a submission candidate.

Quick Triage (2-Minute Assessment)

Used by /triage for rapid go/no-go on a single finding. Answer these three questions:

1. Is it exploitable without device modification? (jailbreak, root, ADB debug mode)
   • YES → continue
   • NO → KILL unless program scopes modified devices
2. Does the attacker gain something concrete? (data, access, privilege)
   • YES → continue
   • NO → KILL
3. Is it on the never-submit list?
   • NO → PROCEED to full validation
   • YES alone → KILL or CHAIN_REQUIRED
   • YES but chained → PROCEED

If all three pass → the finding is worth full validation. If any fail → KILL with reason and move on.

Mobile 7-Question Gate

The complete validation gate applied by the validator agent. Every finding must pass all 7 questions.

Q1: Exploitability

Question: Can an attacker trigger this on a real, unmodified device?

Assessment framework:

• For IPC findings (URL schemes, intents, exported components): Can a malicious app installed from the App Store / Play Store exploit this? The malicious app must pass platform review.
• For binary findings (hardcoded keys, weak crypto): Does this manifest at runtime? Dead code paths are not exploitable.
• For config findings (ATS, network security): Is the misconfiguration actually used by the app's runtime behavior?

KILL criteria:

• Requires jailbreak/root (unless scoped)
• Requires ADB debugging enabled
• Requires physical access to unlocked device (unless scoped)
• Requires developer mode
• Dead code path: the function exists but is never called

Q2: Scope Alignment

Question: Is this type of finding in scope for the program?

Check against scope.json:

• binary_analysis_allowed: Is reverse engineering permitted?
• client_side_accepted: Are client-side-only findings accepted?
• exclusions[]: Is this specific finding type excluded?

Common exclusions to watch for:

• "Client-side vulnerabilities without server-side impact" → kills most storage/crypto findings
• "Reverse engineering is not in scope" → kills binary analysis findings
• "Missing security controls" → kills missing pinning, missing root detection

KILL criteria:

• Finding type is explicitly excluded by the program
• Binary analysis findings when reverse engineering is not scoped

Q3: Asset Confirmation

Question: Is this the production App Store / Play Store build?

Check:

• iOS: No get-task-allow entitlement (unless TestFlight is scoped). No ProvisionedDevices in mobileprovision.
• Android: debuggable=false, signed with release key, not a debug/beta build
• Version matches current store listing (outdated findings are duplicates or fixed)

KILL criteria:

• TestFlight / debug / beta / enterprise build (unless scoped)
• Outdated app version (finding may be fixed)

Q4: Access Feasibility

Question: Does exploitation require only standard, unmodified access?

Standard access means:

• Installing a malicious app from the store
• Sending a link/message to the victim
• Being on the same network (for MITM)
• Having the APK/IPA file (for static analysis findings)

Elevated access (auto-KILL unless scoped):

• USB connection + ADB debugging
• Physical access to unlocked device
• Jailbroken/rooted device
• MDM enrollment
• Developer mode enabled

Q5: Novelty Check

Question: Is this a known platform behavior, not a vulnerability?

Known behaviors to KILL:

• iOS pasteboard access before iOS 16 → known, Apple added paste notification
• Android implicit intent resolution → documented Android behavior
• App backup including app data → standard adb backup behavior (the backup flag itself isn't the vuln)
• WebView loading HTTP on older targetSdk → standard behavior, not a misconfiguration

How to assess: If Apple/Google has documented this behavior and considers it "working as intended," it is not a vulnerability. The finding must demonstrate impact beyond the documented behavior.

Q6: Impact Proof

Question: Is concrete impact demonstrated with evidence?

Required evidence by finding type:

Authorization boundary on proof: several of these proofs involve sending a request to a live service. Only exercise a discovered credential or endpoint when the asset is covered by the program's stated scope, and, when the service is third-party hosted (Firebase, Google Cloud, AWS, and similar), only with the program's written permission; the program owns that account, the researcher does not. Where that authorization is absent, a hardcoded-secret finding still passes Q6 on static evidence: the credential's location in the binary, the service and key type it belongs to, the access the provider documents for that key type, and an explicit request that the program confirm server side. Record which of the two paths was used in the finding's evidence. An unauthorized probe is never acceptable proof, and a finding is never killed for lacking one.

KILL criteria:

• "The component is exported" without demonstrating impact
• "ATS is disabled" without proving sensitive data over HTTP
• "Key found in binary" with no assessment of whether it is live or what access it grants, by either path above
• "Weak crypto used" without identifying protected data

Q7: Never-Submit Check

Question: Is this on the auto-KILL list?

Auto-KILL list (standalone findings only; chains may override):

4 Post-Validation Gates

Applied after the 7-question gate passes. These catch findings that are technically valid but not submission-worthy.

Gate 0: Reality Check (30 seconds)

Question: Can this be demonstrated on a real device or emulator right now?

Mentally walk through the exploit:

• For IPC: craft the intent, URL, or scheme invocation. Does it work?
• For data storage: extract the data via the documented method. Is it there?
• For binary: does the code path execute at runtime?

KILL if: The exploit only works in theory but cannot be practically demonstrated.

Gate 1: Attacker Gain (2 minutes)

Question: What does the attacker gain that they couldn't get otherwise?

The gain must be:

• Specific: Not "access to data" but "access to all user messages including private conversations"
• Novel: The attacker couldn't get this through normal app usage
• Meaningful: Worth the attack complexity (installing a malicious app, hosting a page, etc.)

Examples of insufficient gain:

• Exported activity shows the app's About page → no sensitive data
• Hardcoded key for a public API that requires no auth anyway
• Reading app version or non-sensitive configuration

KILL if: No meaningful, specific gain beyond normal app behavior.

Gate 2: Deduplication (5 minutes)

Question: Has this been reported before?

Check:

1. Program's disclosed/resolved reports (HackerOne Hacktivity, Bugcrowd)
2. Platform security advisories (Apple/Google security bulletins)
3. Is the finding on the current app version? (may be fixed in update)
4. Is this a variant of a known, widely-reported issue?

KILL if: Likely duplicate based on disclosed reports or addressed in a recent app update.

Gate 3: Report Quality (10 minutes)

Question: Is the finding documented well enough for a triager to reproduce?

Required elements:

• Title follows the format: [Bug Class] in [App vX.Y] [Component] allows [attacker] to [impact]
• Steps include app version, platform version, device/emulator
• Exact reproduction commands (adb, xcrun, URLs, code snippets)
• Evidence: code snippets with file paths, config excerpts, command output
• Impact statement with concrete attacker gain
• Specific remediation (exact code/config changes)

DOWNGRADE if: Finding is valid but poorly documented → reduce severity, request enrichment.

Verdict Definitions

Automated vs Manual Validation

tools/validation/validate.py runs automated checks:

• Never-submit list matching
• Scope alignment verification
• Confidence threshold check
• Platform-specific gate checks via mobile_gates.py

Findings that pass automated gates go to needs_review/ for the validator agent to apply the full 7-question gate manually.

tools/validation/poc_generator.py generates PoC artifacts:

• adb commands for Android IPC testing
• xcrun simctl commands for iOS URL scheme testing
• Frida script stubs for runtime verification
• Code snippets for PoC apps

Validation Consistency Rules

1. Be strict. False positives damage researcher reputation and waste triager time.
2. Every PASS must have a clear exploit path. No theoretical vulnerabilities.
3. When in doubt, KILL. The agentic loop can catch missed findings in the next iteration.
4. Never override the never-submit list unless a proven chain elevates the impact.
5. Apply gates consistently regardless of bounty size or program prestige.
6. Document kill reasons clearly so the orchestrator can make informed re-hunt decisions.