Writing a bug bounty scope hunters will actually read

Open ten random /security pages and you'll find ten different interpretations of "scope." Some are a paragraph. Some are a wall of asset URLs without context. Some imply payment without ever stating amounts. Almost none of them tell hunters what they need to know in the first ten seconds.

Hunters do read your scope, but they read it like an attacker reads a target: looking for the cheapest path to a valid finding. If the scope is unclear, they spend their time elsewhere. If the scope contradicts itself, they assume the program is run badly and move on. If the scope is well-written, they spend a Saturday on you.

This is what good scope writing looks like, why most teams get it wrong, and a structure you can copy.

What scope actually does

Scope serves two purposes, and one of them is more important than the other.

First, it tells hunters which assets they can test legally. Without that, the cautious researchers, who tend to be the better ones, will not engage. Computer-misuse laws in most jurisdictions are broad enough that "I was testing your security" is not a defense in itself. A scope page with safe-harbor language is the legal cover that makes their work safe.

Second, it filters submissions. Hunters who read your scope and find that their pet bug class is explicitly out of scope will not submit it. Hunters who read your scope and find a clearly defined asset list will not submit reports about your marketing site or your office wifi. Every hour of triage time you save with a clear scope is an hour that didn't have to be paid for.

The second purpose drives the value, but the first purpose drives the credibility. A scope without legal cover is not a scope; it's a liability waiver for the company that didn't think through what they were inviting.

Why most scope pages are unreadable

Three patterns we see, in order of frequency.

Vague language

"Our products and services" is not a scope. Neither is "anything publicly accessible." Hunters need URLs, hostnames, IP ranges, or named applications. Without specificity, every report is a coin flip on whether triage will accept it, which means hunters either avoid your program or submit everything in the hope that something sticks.

A specific scope reads like: app.example.com, api.example.com, *.example-cdn.net (with a list of which subdomains are in), our mobile apps on iOS App Store and Google Play (with bundle IDs), and the source code at github.com/example/example-public. Anything not on that list is out.

No exclusion list

Even a specific in-scope list is not enough. Hunters will find things on your network that are technically reachable but not business-relevant: a forgotten subdomain pointing at a partner's server, a third-party SaaS with your branding, a security-research honeypot you set up for a different program. Without an exclusion list, you will spend triage hours explaining why these are not valid.

A short out-of-scope section, written in plain language, saves more time than the in-scope list does. Common entries:

• Findings on third-party services hosted at our domains (specify which ones).
• Best-practice scanner output without demonstrated impact.
• Self-XSS, missing security headers without exploitation, and similar low-impact findings.
• Social engineering of our employees or customers.
• Physical security testing.
• Denial-of-service testing of any kind.
• Spam, phishing-link generation, or content-policy violations.

Outdated asset list

The third pattern is the most insidious. A scope that was correct two years ago lists three subdomains that have since been decommissioned. Hunters report bugs against assets that no longer exist or that were transferred to a different team. Triage closes them as out of scope, which feels arbitrary because the asset is literally on your scope page.

Scope pages need a maintenance cadence, not a write-once approach. At minimum, review the asset list every quarter. When you launch new public surfaces, update the page before you launch.

Anatomy of a scope hunters will read

A structure that tends to work. You can copy it.

Lead with what's in

Open with the in-scope list. Be specific, use real hostnames, and group by product if you have several. Hunters should be able to copy your scope into their notes app and start working without clarifying questions.

Be specific about what's out

Follow the in-scope list with an out-of-scope list. Include both asset exclusions (specific hostnames or paths) and finding-type exclusions (self-XSS, scanner output, etc.). The two together set the boundary cleanly.

State what counts as valid

After scope, briefly describe what makes a finding valid. Common language: "We accept reports demonstrating clear security impact on in-scope assets. Reports must include reproduction steps that work end-to-end and a description of the impact." This filters the "is this a valid finding" question before submission.

Reference your testing rules of engagement

A short list of dos and don'ts for testing. Examples:

• Use only your own accounts to test. Do not test against other users.
• Do not exfiltrate data beyond what's needed to demonstrate the bug.
• Use rate limits responsibly. If your testing degrades service, stop and contact us.
• Do not publicly disclose findings before our fix-and-disclose timeline (state the timeline).

Include the legal cover

Safe-harbor language matters. If you're not sure how to write it, disclose.io maintains a community-vetted template. Adapt it; don't write your own from scratch.

Set the response cadence

Hunters need to know how fast to expect a reply and how to escalate if they don't get one. State your acknowledgement SLA and your escalation contact. If you outsource triage, name the triager or service.

State the payout (or don't, but be specific)

If you pay, state your tiers. "Critical: $5,000–$25,000" is specific. "We reward quality findings" is not. If you don't pay, say so plainly. Vagueness about payment does more damage than either extreme.

Date the page

Add a "Last updated" date. Auditors look for it. Hunters look for it. It signals whether the page is maintained.

Concrete examples

In-scope, written well:

Web applications:

• app.example.com (production web app)
• api.example.com (REST API, all endpoints under /v1 and /v2)
• staging.example.com (staging, testing here is preferred for destructive operations)

Mobile applications:

• iOS: com.example.app (App Store version 4.x and later)
• Android: com.example.app (Play Store version 4.x and later)

Source code:

• github.com/example/example-cli (open source CLI)

Out-of-scope, written well:

The following are out of scope. We will close reports against them with an explanation but without further triage:

• marketing.example.com (managed by a third party)
• support.example.com (Zendesk-hosted; report directly to Zendesk)
• *.legacy-example.com (deprecated, scheduled for removal)
• Findings that require physical access to user devices.
• Vulnerabilities in third-party dependencies that have already been reported upstream and are pending vendor fix.
• Best-practice findings (missing HSTS, weak ciphers, etc.) without a demonstrated exploitation path.

Both lists are short. Both are specific. A hunter can read them in under a minute and know whether their finding is in scope.

Maintenance: how often to update

A short cadence:

• Quarterly: review the asset list. Remove decommissioned items. Add new public surfaces. Bump the "Last updated" date.
• On launch: any new public-facing product or domain triggers an update.
• On bug class trends: if a specific finding type is showing up repeatedly and you don't want to keep paying for it, add it to the out-of-scope list (with notice to existing hunters).
• Annually: review the safe-harbor language for legal correctness.

A checklist you can lift

Use this when drafting or auditing your scope:

1. Is the in-scope asset list specific (hostnames, bundle IDs, repos)?
2. Is the out-of-scope list explicit, with both asset and finding-type exclusions?
3. Is "what counts as valid" stated in plain language?
4. Are testing rules of engagement listed?
5. Is the safe-harbor clause present and current?
6. Is the response SLA stated?
7. Is the payout structure specific (or clearly absent)?
8. Is the page dated, with a maintenance cadence?

If any answer is no, that's the next thing to fix.

Where we fit

We help programs draft scope as part of onboarding. It's the most common upgrade we make in the first month: tightening vague language, adding the missing exclusion list, and adding the maintenance cadence. The result is fewer junk submissions and better engagement from hunters who matter.

If your scope page hasn't been updated in over a year, or you're not sure it would survive a hunter reading it carefully, book an intro call. We'll give you a written audit within a week.