| name | bug-bounty-validation |
| description | Pre-submission validation for bug bounty findings with scope/impact/exploitability gates, CVSS scoring, and submit/kill verdict |
| license | MIT |
| metadata | {"category":"compliance","locale":"en","phase":"v1"} |
What this skill does
Provides a structured decision framework for validating bug bounty findings before submission. Runs a sequential gate system — 7-Question Gate, Always-Rejected List, Chain Requirement Evaluation, 4 Pre-Submission Gates, and CVSS 3.1 severity assessment — to produce a final verdict of SUBMIT, KILL, NEEDS CHAIN, or NEEDS IMPROVEMENT. Eliminates wasted submissions by catching invalid, out-of-scope, or low-quality reports before they reach the program.
When to use
- After discovering a potential vulnerability and before writing the full report
- When unsure whether a finding is worth submitting
- When a finding seems valid but impact is borderline
- When you have a low-severity finding and want to know if chaining elevates it
- When a triage response came back "Informational" or "N/A" and you want to understand why
- When reviewing a draft report for quality before final submission
Prerequisites
- A potential finding with at least one HTTP request/response pair demonstrating the behavior
- Knowledge of the target program's scope page (assets, exclusions, accepted vulnerability classes)
- Access to the program's policy page on HackerOne, Bugcrowd, Intigriti, or equivalent platform
- No external tools are required — this skill is a decision framework
Inputs
| Variable | Required | Description |
|---|
BV_FINDING | Yes | Short description of the vulnerability (e.g., "IDOR on /api/orders/ID allows reading other users' orders") |
BV_ASSET | Yes | Full domain or asset where the finding was observed (e.g., api.example.com) |
BV_VULN_CLASS | Yes | Vulnerability class (e.g., IDOR, XSS, SSRF, Open Redirect, CSRF) |
BV_POC_STEPS | Yes | Number of reproduction steps documented |
BV_IMPACT | Yes | One sentence describing the concrete business impact |
BV_AUTH_REQUIRED | Yes | none, user, or admin — minimum privilege level required to exploit |
BV_PROGRAM_SCOPE_URL | Optional | URL to the program's scope page for cross-reference |
BV_CHAIN_PARTNER | Optional | Second vulnerability you can chain with this finding (leave blank if standalone) |
Workflow
Step 1: Run the 7-Question Gate
Answer YES or NO to each question. All 7 must be YES to continue. Any NO is an immediate KILL.
7-QUESTION GATE
===============
Q1: Do you have a real HTTP proof-of-concept — not just theoretical reasoning?
YES = you can show a request/response pair where the bug is triggered
NO -> KILL. Document the behavior as a research note and move on.
Q2: Is the impact accepted by the program's policy?
YES = the program explicitly lists this vuln class as in-scope or does not exclude it
NO -> KILL. Policy exclusions are non-negotiable regardless of technical severity.
Q3: Is the affected asset explicitly in scope?
YES = the asset (domain, subdomain, API endpoint) appears in the program's in-scope list
NO -> KILL. Out-of-scope submissions damage your reputation and waste triage time.
Q4: Can it be exploited WITHOUT privileged or admin access?
YES = a regular user account (or no account) is sufficient to trigger the bug
NO -> KILL unless the program specifically rewards admin-perspective findings.
Q5: Is this NOT known or documented behavior?
YES = the behavior is not described in the app's documentation, help center, or changelogs
NO -> KILL. Intentional behavior is not a vulnerability.
Q6: Can you prove impact beyond "technically possible"?
YES = you can demonstrate actual data read, data written, account taken over, or equivalent
NO -> KILL or downgrade to NEEDS IMPROVEMENT (add a concrete impact demonstration).
Q7: Is this NOT on the always-rejected list?
YES = the finding does not match any entry in the always-rejected list (see Step 2)
NO -> KILL. Always-rejected findings are rejected regardless of quality.
GATE RESULT: Count YES answers.
7/7 YES -> Proceed to Step 2
Any NO -> KILL. Do not submit.
Step 2: Check the always-rejected list
Reference: See REFERENCE.md for the full Always-Rejected List (14 finding types that are automatic KILLs regardless of technical quality).
Compare the finding against each entry. A match is an automatic KILL regardless of Step 1 results. 0 matches -> Proceed to Step 3.
Step 3: Evaluate chain requirement
Reference: See REFERENCE.md for the Conditionally-Valid-With-Chain Table mapping standalone verdicts to chained verdicts for Open Redirect, Self-XSS, Clickjacking, CSRF, IDOR, and other common findings.
Some findings are invalid standalone but valid (and often high severity) when chained. Identify the finding's chain status before scoring severity.
EVALUATION:
Finding is valid standalone -> Proceed to Step 4
Finding requires a chain partner -> Check BV_CHAIN_PARTNER
BV_CHAIN_PARTNER is set -> Document chain, proceed to Step 4 with combined class
BV_CHAIN_PARTNER is not set -> NEEDS CHAIN. Research chain partner before submitting.
Finding is N/A even with chain -> KILL.
Step 4: Run the 4 pre-submission gates
Each gate has a PASS threshold. Failing any gate produces NEEDS IMPROVEMENT, not KILL — fix the gap and re-run.
PRE-SUBMISSION GATE 1: TECHNICAL
=================================
[ ] PoC works in a clean browser profile or fresh session (not just your existing session)
[ ] PoC works with cookies/tokens from a second test account (confirms it is not self-only)
[ ] Minimum 3 reproduction steps documented (numbered, unambiguous)
[ ] Each step specifies: HTTP method, endpoint, headers, body, and expected vs. actual response
[ ] PoC does not depend on a race condition you cannot reliably reproduce (if it does, note success rate)
GATE 1 RESULT:
5/5 checked -> PASS
Missing items -> NEEDS IMPROVEMENT. Complete all items before proceeding.
PRE-SUBMISSION GATE 2: SCOPE
==============================
[ ] Confirm the exact domain/IP is listed on the scope page (wildcard *.example.com covers subdomains)
[ ] Confirm the vulnerability class is not in the program's explicit exclusion list
[ ] Confirm the endpoint is not a third-party service (check CNAME, Shodan, response headers)
[ ] If the target is a mobile app, confirm the app version tested matches the current release
GATE 2 RESULT:
4/4 checked -> PASS
Missing items -> NEEDS IMPROVEMENT. Verify scope before proceeding.
PRE-SUBMISSION GATE 3: IMPACT
==============================
[ ] Written a one-sentence business impact statement (who is affected, what data or action, at what scale)
[ ] Calculated CVSS 3.1 score (see Step 5) and it is consistent with the demonstrated impact
[ ] Impact statement references a concrete artifact: data exfiltrated, account compromised, service disrupted
[ ] Impact is proportional to actual exploitation — not the theoretical worst case
GATE 3 RESULT:
4/4 checked -> PASS
Missing items -> NEEDS IMPROVEMENT. Strengthen impact evidence before proceeding.
PRE-SUBMISSION GATE 4: QUALITY
================================
[ ] Report follows the platform's template structure (Summary, Steps to Reproduce, Impact, CVSS)
[ ] Screenshots or HTTP logs (Burp/Caido export) are attached for every key step
[ ] Report does not contain actual PII of real users (use test accounts only; blur or redact any real data)
[ ] Technical jargon is explained in one sentence where used (program staff may not be senior engineers)
[ ] Title is ≤ 120 characters and contains: vuln class + asset + one-line impact
Good: "IDOR on /api/v2/orders allows unauthenticated read of any user's order history"
Bad: "Security issue found"
GATE 4 RESULT:
5/5 checked -> PASS
Missing items -> NEEDS IMPROVEMENT. Fix quality gaps before proceeding.
OVERALL GATE RESULT:
Gates 1-4 all PASS -> Proceed to Step 5
Any gate NEEDS IMPROVEMENT -> Fix all flagged items, re-run that gate, then proceed
Step 5: Assess CVSS 3.1 severity
Reference: See REFERENCE.md for the full CVSS 3.1 Quick Reference — metric weights (AV/AC/PR/UI/S/C/I/A), severity bands (Critical/High/Medium/Low with typical profiles and examples), and score sanity checks.
Use the quick reference to calculate a score. Assign the score that matches what you can actually demonstrate, not the theoretical maximum.
Step 6: Output final verdict
Combine all gate results into a single verdict.
FINAL VERDICT LOGIC
====================
IF any 7-Question Gate answer is NO:
-> VERDICT: KILL
-> Reason: [which question failed]
-> Action: Do not submit. Document as research note.
IF any Always-Rejected List item matched:
-> VERDICT: KILL
-> Reason: [which list entry matched]
-> Action: Do not submit. Delete draft to avoid accidental submission.
IF finding requires a chain partner AND BV_CHAIN_PARTNER is not set:
-> VERDICT: NEEDS CHAIN
-> Reason: Standalone finding does not meet minimum impact threshold
-> Action: Research chain partner. Re-run from Step 3 once chain is identified.
IF any Pre-Submission Gate is NEEDS IMPROVEMENT:
-> VERDICT: NEEDS IMPROVEMENT
-> Reason: [list each failed gate item]
-> Action: Fix all flagged items. Re-run failed gate only. Do not re-run full validation.
IF all gates PASS and CVSS score is calculated:
-> VERDICT: SUBMIT
-> Severity: [Critical / High / Medium / Low] (CVSS [score])
-> Report title: [BV_FINDING — one line, ≤ 120 characters]
-> Checklist before sending:
[ ] PoC request/response attached
[ ] Reproduction steps numbered and complete
[ ] Impact statement written
[ ] CVSS score included in report
[ ] No real user PII in report
[ ] Platform template followed
VERDICT SUMMARY TABLE
======================
Verdict | Meaning | Next action
-------------------|---------------------------------------------|---------------------------
SUBMIT | Finding is valid, scoped, impactful, quality| Submit report now
KILL | Finding is invalid or out of scope | Discard, log as research note
NEEDS CHAIN | Valid only when chained with another bug | Find chain partner, revalidate
NEEDS IMPROVEMENT | Valid finding, report quality insufficient | Fix flagged items, recheck gates
Done when
- All 7 questions in the 7-Question Gate answered YES
- Always-Rejected List reviewed with zero matches
- Chain requirement resolved (standalone PASS or chain partner identified and documented)
- All 4 Pre-Submission Gates at PASS status
- CVSS 3.1 score calculated and validated against demonstrated impact
- Final verdict is SUBMIT with a complete pre-send checklist confirmed
Failure modes
| Symptom | Cause | Resolution |
|---|
| Gate 1 fails — PoC only works in your own session | Session-dependent state (CSRF token, account-specific condition) | Create a second test account and reproduce from scratch |
| Gate 2 fails — asset not confirmed in scope | Wildcard scope ambiguity or subdomain not listed | Email program contact or check scope changelog; when in doubt, do not submit |
| Gate 3 fails — impact statement is vague | Finding described technically but not in business terms | Answer: "Who loses what, and how many of them?" |
| Gate 4 fails — report contains real PII | PoC used production data instead of test accounts | Re-run PoC with test accounts, redact screenshots, replace request logs |
| Q4 fails — requires admin access | Found finding while logged in as admin test account | Verify whether the endpoint enforces authorization for lower-privilege roles |
| Q6 fails — impact is "technically possible" only | No concrete exploit demonstrated | Build a minimal working exploit that shows actual data access or action execution |
| CVSS score is Critical but program rates it High | Program applies internal severity mapping | Accept the program's rating; note your CVSS in the report for transparency |
| Stuck on chain requirement — no obvious partner | Finding is low-impact and no sibling bugs exist | Use bug-bounty-methodology skill to hunt for a chain partner; otherwise KILL |
Notes
- Run this validation on every finding before drafting the full report — it saves hours of writing reports that will be rejected.
- CVSS is a starting point, not a contract. Programs apply internal modifiers; a CVSS 7.5 may pay as Medium if the program has a restricted severity map.
- The Always-Rejected List reflects patterns that consistently receive N/A responses across major platforms. These are not arbitrary — they represent findings that either have no real-world impact or are considered acceptable risk by most programs.
- A NEEDS CHAIN verdict is not a dead end. Many High and Critical findings are built from two Low findings. The chain-finding step is active research, not failure.
- Do not submit simultaneously to multiple programs if the asset is shared infrastructure. Confirm the owning program first.
- When a report comes back as Informational or Duplicate, re-run this gate on your next similar finding before submitting to identify the gap.
- Keep a personal rejected-findings log. Patterns in your own rejections (e.g., always failing Q6) reveal a specific skill gap to address in training.
