How to Write Bug Bounty Scope That Prevents Noise

Scope is the single highest-leverage document in your bug bounty program. Every ambiguity in it gets converted, at internet scale, into reports, and every report, valid or not, costs triage time to close. A vague scope manufactures noise, then bills you for it.

The good news: scope quality is entirely within your control, and most scope problems are the same five mistakes repeated everywhere. Here's how to write scope that filters garbage at the source.

Start with an asset inventory you actually believe

You cannot scope what you haven't enumerated. Before writing a single in-scope line, build the list:

• External attack surface: every apex domain, subdomain, and IP range you own, including the ones marketing registered in 2019 and forgot. Researchers will find them with subfinder and certificate transparency logs whether you list them or not; better that you find them first and decide their status deliberately.
• Acquisitions: the assets of that company you bought last year are your assets now, and their dangling DNS is your subdomain takeover report. Decide explicitly whether they're in, out, or in-with-caveats.
• Third-party hosted services: your Zendesk, your Salesforce community, your marketing-agency-managed WordPress. You'll receive reports about them regardless. Scope must say whose problem they are.
• Mobile apps, APIs, desktop clients: each is a distinct scope entry with its own rules, not an implied appendage of the website.

The uncomfortable discovery step (running your own recon before researchers do) is also where you find the staging server with default creds. Do it before launch, not via a bounty invoice.

In scope: be literal, not gestural

Good in-scope entries are specific enough that a researcher (or a triager) can answer "is this asset covered?" without judgment calls:

• List exact hostnames where you can: app.example.com, api.example.com.
• If you use a wildcard, mean it. *.example.com includes jenkins-old.dev.example.com. If you're not prepared to pay for bugs on every subdomain that pattern matches, don't publish the pattern. Enumerate instead, or publish the wildcard with explicit exclusions.
• Mobile apps: name the exact package ID / bundle ID and store listing.
• APIs: state which versions and whether documented-only or all reachable endpoints.

For each asset, say what matters about it: does it hold production user data, is there a test environment, are test accounts provided? An asset entry with credentials for a sandbox tenant redirects researcher energy away from "testing on real users" (which your rules prohibit anyway) toward things you can safely reward.

Out of scope: two different lists

"Out of scope" conflates two things that deserve separate sections:

Out-of-scope assets are things researchers shouldn't test at all: corporate IT, third-party services, that acquisitions integration mid-migration. Be explicit about why where it helps ("vendor-managed; report to vendor's program").

Out-of-scope findings are issue classes you won't reward on otherwise in-scope assets. This is your noise filter, and it's where precision pays off most. The standard exclusion list, which exists because every program receives these weekly:

• SPF/DKIM/DMARC configuration observations
• Missing security headers or cookie flags without a demonstrated exploit
• Clickjacking on pages with no sensitive action
• Self-XSS and issues requiring an implausible victim-side setup
• Software version disclosure / banner grabbing without a working exploit
• Rate limiting on non-sensitive endpoints; password policy opinions
• Automated scanner output submitted without validation
• Anything requiring physical access, or social engineering of staff

Critical drafting rule: exclude findings, not techniques, and leave the door open for genuine impact. "Missing headers are out of scope unless chained into a demonstrated exploit" keeps the filter without telling the one researcher with a real clickjacking-to-account-takeover chain to go away.

Severity-capped assets: the middle tier scope writers forget

Not every asset deserves the binary of in/out. The marketing site on WordPress, the legacy portal being decommissioned next quarter, the acquired product still on its old stack: you do want to hear about an RCE there, but you don't want to pay critical-tier rates for every reflected XSS on a brochure page.

The tool for this is a severity cap: the asset is in scope, but rewards are capped at, say, Medium, or paid at a reduced tier. This keeps the intake channel open for genuinely bad findings while pricing the asset's real risk. It also gives your triage team an unambiguous rule instead of a per-report negotiation, which matters, because severity disputes are where researcher goodwill goes to die. Whether you rate with CVSS or the Bugcrowd VRT, publish which one you use per program, and note any per-asset environmental adjustments up front.

The five scope mistakes that generate garbage

1. The unqualified wildcard. *.example.com published casually, then reports on forgotten dev boxes get closed as "not important." You published the pattern; you own the pattern. Every such closure is a researcher who stops testing your program and tells others why.
2. Silence on third-party services. Say nothing about your Zendesk and you will receive Zendesk reports forever, each requiring an individually written rejection. One scope line ends the entire category.
3. Exclusion lists that exclude too much. Programs that blanket-ban "XSS on non-production," "issues requiring user interaction," and "anything involving email" have effectively banned most real web vulnerabilities. Top researchers read exclusion lists as a bid on their time: an over-broad one reads as "we don't actually want reports," and the people who leave first are the ones with options.
4. Scope that contradicts itself across pages. The policy page says one thing, the platform brief another, the FAQ a third. Researchers will quote whichever version favors their report, and honestly, fair enough. Single source of truth, versioned, dated.
5. Never updating it. Scope written at launch, untouched for two years, while the company shipped three products and two acquisitions. Stale scope means your riskiest new surface has zero coverage while researchers keep grinding the picked-clean original assets and generating duplicates. Review scope quarterly, and treat every "is this in scope?" question from a researcher as a bug report against the document itself.

An example scope table

Note the pattern: even "capped" rows leave an escape hatch for catastrophic findings, and every out-of-scope row says why. Both details measurably reduce argument volume.

Scope is a triage document

Researchers read scope once, but your triage team enforces it on every single report. Every judgment call the document leaves open becomes a per-report decision, made under time pressure, that must be consistent across triagers and defensible to the researcher. Tight scope is what makes fast, consistent triage possible, and it's the first document we ask for when we take over a noisy program, because it's usually where the noise is coming from.

If your queue is full of reports that a better scope document would have prevented, that's fixable, and the reports still in the queue are handleable. TRIAGERS™' on-demand teams triage per report and will tell you, bluntly, which scope lines are generating your noise. Get in touch.