Bug bounty hunting, from first report to first payout.
Labs teach you the technique. A bounty program is where it meets a system somebody depends on, with scope, safe harbour and a payout schedule written down before you send the first request.
How the platform works
Scope you can read
Every program states what is in scope, what is explicitly out, and which classes of finding it will not pay for. Reading that page properly is the single highest-value habit in bug bounty work — most rejected reports were out of scope before a single request was sent.
Reports with a structure
A report is a claim plus the evidence for it: where the bug is, what an attacker gains, and the exact steps a triager can replay. Submissions here are structured so the parts a triager needs are required rather than hoped for.
Safe harbour, written down
Each program carries an explicit safe-harbour statement setting out the testing it authorises. That statement is the difference between security research and a computer misuse offence, and it belongs in writing before you start, not after.
Paid on severity
Bounties are set against the impact of the finding, assessed by the triage team and visible on the program page as a range before you start. Payouts are tracked to your account and paid out directly.
From target to payout
- 01
Pick a program
Read its scope, its exclusions, and its safe-harbour terms. Match it against what you are actually good at — a program full of mobile targets is a poor fit if you have never opened a decompiler.
- 02
Recon
Map the attack surface inside scope: subdomains, endpoints, parameters, authentication flows, roles. Most findings live in the part of an application nobody remembered to test.
- 03
Find and verify
Confirm the bug is real and reproducible before writing it up, and establish what an attacker actually gains. A reproducible proof-of-concept is what separates a paid report from a closed one.
- 04
Report
One finding per report. Location, impact, reproduction steps, and a suggested fix. Keep the proof-of-concept minimal — demonstrating impact is not the same as maximising damage.
- 05
Triage and payout
The team validates, assigns severity, and pays against the program's range. If it is a duplicate you will be told what it duplicated and when that was received.
Run your own bug bounty program
The other side of the platform. Put your systems in front of vetted researchers, get structured reports triaged before they reach your engineers, and pay only for real, in-scope findings.
Launch a program
Define your scope, your exclusions and your reward table, publish a safe-harbour statement, and open to researchers. Run it public or invite a vetted private pool — you decide who can test and what they can touch.
Triage you can trust
Reports arrive structured — location, impact, reproduction — and are validated and severity-rated before they reach your engineers, so your team sees confirmed issues, not a queue of noise and duplicates.
Vetted researchers
The same people who compete in the arena and place on the leaderboard are the ones testing your systems. You can gate a private program to a skill tier, so a critical asset is only ever in experienced hands.
Pay for impact, not hours
You set the reward range per severity and pay only for valid, in-scope findings. No retainer, no per-hour billing — a bounty is cheaper than the breach it prevents and far cheaper than a pentest that finds nothing.
Bug bounty questions, answered
What is a bug bounty program?
A standing offer from an organisation: test these systems, within these rules, and we will pay you for valid security findings. It converts what would otherwise be unauthorised testing into authorised research, because the scope document is the authorisation. The payment is for the finding's impact, not for the time you spent looking.
Can a beginner earn from bug bounty?
Yes, but be realistic about the curve. The first months are usually spent finding duplicates and out-of-scope issues, and that is normal — you are learning an application's shape as much as a vulnerability class. People who get through it tend to be the ones who picked one target and went deep rather than scanning fifty and moving on.
Is bug bounty hunting legal?
It is legal within the scope and safe-harbour terms of a program that has published them, and it is a criminal offence outside them in most jurisdictions — including testing a target that never invited it. Scope is not a formality. Read it, stay inside it, and stop if you find yourself somewhere it does not cover.
How much do bug bounties pay?
Across the industry, the range runs from tens of dollars for a low-severity issue to five figures for a critical one on a mature program, and the distribution is heavily skewed toward the low end. Each program on OFFCON publishes its own range on its page before you start, so you are never guessing.
What should I practise before hunting on live targets?
Web exploitation on real applications, until finding an injection or a broken access control is routine rather than lucky. The lab machines and the web modules in the guided tracks cover the same classes that make up most of what bounty programs pay for, without the risk of testing something you are not authorised to touch.
We are a company — how do we start a program?
Get in touch and we will set it up with you: scope and exclusions, a safe-harbour statement, a reward table by severity, and whether it runs public or as a private invite-only pool. You can start small — a tight scope on one asset — and widen it as you get comfortable with the flow of reports.
What does a program cost to run?
You pay the bounties you award for valid, in-scope findings, at the reward range you set, plus the platform's fee for hosting and triage. There is no per-hour billing — unlike a pentest, you are paying for outcomes, and an unfound bug costs you nothing.