Bug bounty has changed more in the last two years than in the five before. The platforms are the same, HackerOne and Bugcrowd, but the work is different: more vendor-run vulnerability disclosure programs, more AI-assisted triage between you and the program, and far more competition on the paid programs everyone can see.
I have been doing this for over five years alongside client VAPT (vulnerability assessment and penetration testing) work. The 12 CVEs I am credited for all came through vendor VDPs rather than paid programs, and that is not an accident. This post is what I would tell someone starting now: how the landscape works, how to pick programs, how to write a report that survives triage, what to do when a report is closed, and why unpaid disclosure programs are worth your time if you want credit that lasts.
The landscape
Two things matter when you look at a program listing: who runs it and what you get.
Platforms versus vendor-run programs. HackerOne and Bugcrowd host programs for organisations and provide the submission flow, triage layer and reputation system. A growing number of vendors also run their own disclosure programs, on those platforms or on a plain security page with a security.txt file. Vendor-run programs are less crowded because they do not surface in a "programs with bounties" filter.
VDPs versus paid programs. A vulnerability disclosure program (VDP) is a formal reporting channel with a published policy and safe-harbour language but no monetary reward. A bug bounty program adds payment tiers. Both give you a report record, a triage decision and, usually, public recognition on a Hall of Fame page.
AI-assisted triage. Platforms and large programs now use automated and model-assisted tooling to pre-classify incoming reports, flag likely duplicates and check for missing fields. I cannot tell you the exact mechanics of any platform, and you should be suspicious of anyone who claims to. The practical effect is clear enough: a structured, specific, reproducible report moves through triage quickly; a vague one missing its version and steps gets stuck or bounced back. Writing for a human triager and writing for an assisted pipeline turn out to be the same skill.
Picking programs
Beginners pick programs by payout. Experienced hunters pick by fit.
- Scope quality. A program that lists exact assets, versions and out-of-scope items is easier to work than one that says "everything we own". Precise scope means precise safe harbour.
- Response times. Public program pages show average time to first response and to triage. A program that takes weeks to acknowledge will also take weeks to argue severity with you.
- Your strengths. If your background is API testing, a program with a documented REST or GraphQL API gives you more surface than a marketing site. Depth on one product beats breadth across fifty.
- Vendor products, not just web apps. The Progress Software CVEs I am credited for were in an npm package, a code generator and a family of UI component libraries: products that organisations ship to their own customers, so a bug in one reaches every downstream deployment. Vendor VDPs covering shipped software are under-hunted compared with consumer web apps.
Reports that get accepted
A report has one job: let a stranger reproduce the issue and understand why it matters in under ten minutes.
# Title: <bug class> in <component> <version> allows <impact>
## Affected
Product / component: @vendor/package-name
Version tested: 1.2.3 (also confirmed on 1.2.4)
Environment: fresh install, default config
## Summary
One paragraph: what the bug is, where, who can trigger it, what they get.
## Steps to reproduce
1. Install version 1.2.3 and run the default sample.
2. Send the request below.
3. Observe the response.
## Request / response
(minimal, redacted, copy-pasteable)
## Impact
Who is affected, what an attacker gains, preconditions.
## CWE and CVSS
CWE-xxx. CVSS 3.1 vector, one line per metric justifying the choice.
## Suggested fix
Why each section is there:
Version pinning. Triage has to confirm the bug exists in a supported version. "Latest" is not a version. Record the exact number and, if you can, whether neighbouring releases are also affected.
Minimal proof of concept. Strip the PoC until removing anything else breaks it. A minimal PoC is faster to verify and harder to dispute.
Impact, stated plainly. "Reflected XSS in a search parameter" is a bug class. "A link sent to a logged-in administrator runs attacker JavaScript in the admin console and can change user roles" is an impact. Triage assigns severity on the second one.
CVSS with justification. The Common Vulnerability Scoring System (CVSS) is the standard severity scale. The number matters less than the vector string and your reasoning. If you claim PR:N (no privileges required), say why an unauthenticated user can reach the endpoint. For the chart-tooltip XSS bugs I reported, the public record carries PR:L and UI:R: a low-privileged user must be able to influence a string bound to the chart, and a victim must hover. Claiming higher would have been severity inflation, and programs remember. A researcher whose Mediums are real Mediums gets their Criticals taken seriously.
Evidence. A short video or three screenshots showing the request, the response and the visible effect.
Duplicates, informatives and N/A
How you handle these decides whether the program wants to hear from you again.
Duplicate. Someone reported it first. Ask, politely, whether your report added anything (a new vector, a bypass of their fix). If it did, ask for a separate issue. If not, accept it and move on. Arguing a straight duplicate burns reputation for nothing.
Informative. The program agrees it is real but it falls outside their threat model or the impact is too low. Read their reasoning. Sometimes they are right. Sometimes you have not shown the impact clearly, and a follow-up with a chained scenario changes the outcome. Re-submitting the same report with a louder title never works.
Not applicable. Out of scope, accepted risk, or not reproducible. "Not reproducible" is on you: supply the environment details you left out. Out of scope: apologise and read scope harder next time.
The misconception is that triage decisions are verdicts on your skill. They are decisions about one report against one program's policy. Keep the notes; a closed report often becomes a valid one on a different target running the same component.
VDPs and Hall of Fame: why I do them
Unpaid programs are where I have earned the credit that actually moves my career. My public Hall of Fame entries are NASA, Nojoto, RepAutomate and six Bugcrowd VDPs: Vero, Progress Sitefinity, Chef, DevTools, DataDirect and MarkLogic. None paid. Twelve CVE records with my name as finder came out of that work, which no bounty payment gives you.
What a VDP gives that a payout does not:
- Durable credit. A CVE record on cve.org and a vendor advisory outlive any platform profile. They are what a hiring manager or client finds when they search your name.
- Less competition. Paid programs attract automated mass submission. VDPs for shipped software attract people who actually read the product.
- Relationships. A vendor security team that has had three clean reports from you answers the fourth quickly and asks your opinion on their fix.
- Practice at coordinated disclosure. Working with a vendor that is also a CVE Numbering Authority (CNA), an organisation authorised to assign CVE IDs, teaches you how advisories and affected-version ranges actually get written.
From report to CVE
You report through the vendor's VDP; the vendor confirms, fixes and, if they are a CNA, publishes a CVE record with you as finder, with an advisory alongside. You do not request the CVE. You make the report good enough that the vendor wants to publish it. The full process is in the companion post linked at the end.
Tooling that matters
Recon pipeline. Continuous, automated discovery of in-scope hosts and change detection. A new host is the highest-signal event in bug bounty. Build it once; run it always.
Proof-based scanning. Scanners that only report what they can demonstrate, with request and response attached, stop you submitting false positives. This is why I built SentryScan and SentryScan Mobile around proof rather than pattern matching.
Manual logic testing. Authorization, business flows, multi-step state. No scanner finds a BOLA (broken object level authorization) in a tenant-scoped API or a coupon that applies twice. This is where valid, non-duplicate findings come from.
Ethics and safe harbour
Safe harbour is the clause in a program policy stating that good-faith research within scope will not be treated as unauthorised access. It only covers you if you stay inside the lines it draws.
- Test only listed assets. A subdomain you discovered is not in scope unless the policy's wildcard covers it.
- Stop at proof. Show you can read one record, not ten thousand; show command execution with a harmless command, not a persistent shell.
- Do not pivot into third-party systems, even if the target's bug leads there.
- Use test accounts, not production user data.
- Respect rate limits; do not degrade service.
- Do not disclose publicly before the program's policy allows.
Beyond the legal point: a vendor deciding whether to credit you reads your report for signs of restraint. Overreach gets reports closed and researchers banned.
Checklist: before you submit
- Exact product and version, confirmed on a clean install.
- Minimal PoC, copy-pasteable, tokens redacted.
- Impact stated as what an attacker gains, not a bug class name.
- CWE identified; CVSS vector with per-metric justification.
- Scope re-read; asset explicitly listed.
- Evidence: request, response, visible effect.
- Suggested fix included.
Fixes / defence: what program owners should do
The same points apply from the other side. Publish precise scope and versions. State your threat model so "informative" closures are predictable. Acknowledge quickly, even if triage takes longer. Credit researchers consistently, and if you are a CNA, publish the CVE record and advisory together so downstream users can act. Programs that do this get better reports, because researchers learn what you want.
Takeaways
- The platforms have not changed; the triage layer and the competition have. Structured, reproducible, version-pinned reports win in both human and assisted triage.
- Pick programs by scope quality, response time and your own depth, not headline payout.
- Handle duplicates and informatives like a professional. Programs remember behaviour longer than bugs.
- VDPs on shipped software are under-hunted and are the path to CVE credit with your name on it.
- Stay inside safe harbour. Restraint is part of the evidence.
Learn more
- OWASP Top 10 and OWASP API Security Top 10 (owasp.org) for the bug classes programs expect you to know.
- MITRE CWE (cwe.mitre.org) for the weakness IDs your reports should cite.
- CVE Program (cve.org) for how records, CNAs and publication work.
- FIRST CVSS specification documents for scoring vectors with justification.
Related: From a Bugcrowd VDP Report to a Published CVE · Building a Recon Pipeline That Scales. Need this tested on your product? Book a free 30-minute scoping call.
