Bug Bounty Programmes

Reward structure. What a valid finding pays, banded by severity, often using CVSS from the previous chapters as the starting point. Programmes vary from recognition only (a "hall of fame"), properly called a vulnerability disclosure programme, to substantial payments for critical findings.

Safe harbour. A written promise that the organisation will not pursue legal action against researchers who act in good faith within the policy, and that it will not ask others to. This is the clause that does the real work: it is the organisation stating that activity under the policy is authorised and will not be treated as an offence. A programme without a safe-harbour statement offers weaker assurance, and experienced researchers check for it before spending time.

Disclosure terms. Whether and when a researcher may publish, usually after a fix and with the organisation's agreement.

How a finding is reported and rewarded

The lifecycle of one bounty finding is the vulnerability lifecycle run quickly:

1. The researcher tests within scope and finds a flaw.
2. They write a report and submit it privately through the programme's platform.
3. The organisation triages: reproduces it, assesses severity, may ask questions, and decides whether it is in scope and novel.
4. If valid, they pay and credit, and fix the flaw.
5. Public disclosure, if any, happens later and by agreement.

What a good report contains, because this is what separates a paid finding from a rejected one:

• A clear title naming the flaw and where it is.
• The affected target, exactly (URL, endpoint, parameter, application version).
• Steps to reproduce, numbered, precise enough that a triager can follow them without guessing, including the accounts used.
• Evidence: request and response, or a screenshot, with sensitive values masked.
• Impact: what an attacker could actually achieve. This is the part researchers skimp and triagers care most about.
• A suggested severity with a CVSS vector, and ideally a remediation suggestion.

"Your site is vulnerable to XSS" earns nothing. "The search parameter on this endpoint reflects input into the page without encoding; steps below; an attacker can run script in a victim's session and read their session token; suggested CVSS vector; fix by contextual output encoding" earns the reward and the fix.

Why reports get rejected, which is worth knowing before you write one:

• Out of scope, the commonest reason by far.
• Duplicate: somebody reported it first. Bounties usually pay only the first reporter, which is why speed matters and why disputes arise.
• Not a vulnerability: accepted behaviour, or a theoretical issue with no demonstrable impact. Missing security headers with no exploitable consequence are the classic example.
• No demonstrated impact: the researcher showed a quirk but not what an attacker gains.
• Scanner output pasted in without verification or analysis, which most programmes explicitly refuse.

A worked example

Priya reads the policy for a shopping company's programme: scope is *.example-shop.test; denial of service and social engineering are forbidden; rewards run from a small sum for Low to a large one for Critical; there is a clear safe-harbour clause; publication requires agreement.

• She tests only subdomains of example-shop.test. She notices an interesting login portal on a different domain the same company owns and does not touch it, because the scope does not name it; instead she asks the programme whether it can be added. That single decision is the difference between a researcher and a defendant.
• She finds that a password-reset link remains valid after use, so an old link found in a forwarded email or a browser history could be replayed to take over an account.
• She writes it up: the endpoint, the exact steps with two of her own test accounts, the masked evidence, the impact (account takeover without the victim's password), a CVSS vector suggesting Medium, and the fix (invalidate the token on first use and on password change).
• The company confirms it, pays the Medium band, credits her, and ships the fix. She publishes nothing until they agree.

Compare this with the grey hat of the earlier chapter, who found a flaw on a stranger's site uninvited: identical skill, identical technique, and an entirely different legal position. The bounty is the difference, and the difference is permission granted in advance.

What beginners get wrong

• Reading a bounty as permission to test anything the company owns. The permission is exactly the published scope and no wider. A system the same company owns but did not list is unauthorised.
• Assuming every programme pays. Many offer only recognition. Read the policy first.
• Breaking the rules of engagement to "prove impact". Running a denial-of-service test inside a bounty that forbids it breaks the policy and the safe harbour, turning authorised testing back into an offence.
• Publishing to get attention. Disclosing before the organisation agrees breaches the terms, forfeits the reward, and damages the trust the whole arrangement depends on.
• Reporting scanner output. Programmes refuse it. A finding needs verification, impact and analysis.
• Omitting impact. Triagers must justify payment internally; a report that does not explain what an attacker gains gives them nothing to justify.
• Testing with real user data. Almost always forbidden, and it engages the confidentiality provisions of the Act. Use the test accounts provided.

Quick revision

• A bug bounty is a standing, public authorisation to test named targets under published rules, rewarding valid findings. It grants permission in advance, which is what makes it lawful.
• Parts: scope (the legal boundary, with exclusions), rules of engagement (usually forbidding denial of service, social engineering, real user data), reward structure (banded by severity, often CVSS-based), safe harbour (no legal action for good-faith work in policy), disclosure terms.
• A vulnerability disclosure programme offers recognition without payment; a bug bounty pays.
• A good report: title, exact target, numbered reproduction steps, masked evidence, impact, suggested severity and fix.
• Rejections: out of scope, duplicate, not a vulnerability, no demonstrated impact, unverified scanner output.
• A bounty complements a penetration test: breadth and continuity against structured, guaranteed coverage.

Test yourself

1. How does a bug bounty make testing lawful when uninvited testing is not?

It is a standing, public grant of permission to anyone who accepts its rules, so testing within its scope is authorised and does not fall under section 43's "without permission of the owner", which uninvited testing does regardless of motive.

1. What is a safe-harbour clause, and why do experienced researchers check for it?

A written undertaking that the organisation will not take legal action against researchers acting in good faith within the policy. Researchers check for it because it is the organisation's explicit assurance that policy-compliant activity is authorised rather than an offence.

1. A researcher on a bounty finds a promising system the company owns but which is not listed in scope. What should they do, and why?

Not test it, and ask for it to be added. Ownership by the company is not authorisation: the permission extends only to the published scope, so testing an unlisted system is unauthorised access.

1. List four things a report must contain to be paid, and give the commonest reasons reports are rejected.

The exact affected target, numbered steps to reproduce, evidence with sensitive values masked, and a statement of impact (plus a suggested severity and fix). Reports are rejected chiefly for being out of scope, duplicates, not actually vulnerabilities, lacking demonstrated impact, or being unverified scanner output.

1. How does a bug bounty differ from a penetration test as a way of finding flaws?

A bounty is continuous, pays per valid finding, and draws on many researchers, giving breadth but no guarantee of coverage. A penetration test is time-boxed and paid for effort, and gives structured, guaranteed coverage of an agreed scope with a report. They complement each other.