Runbook 01 — Bug Bounty Program Intake and Scope Validation

Purpose

Use this runbook whenever you begin work on a new Bug Bounty program or return to a program after a significant period of time.

The objective is to ensure that you know:

What Is Authorized

What Is Not Authorized

Which Testing Methods Are Allowed

Which Assets Are Third Party

Which Restrictions Apply

Which Targets Should Be Prioritized

before performing:

Reconnaissance

Scanning

Application Testing

API Testing

Mobile Testing

Cloud Testing

This runbook establishes the first operational control in Bug Bounty research:

Authorization
Before
Interaction

When to Use This Runbook

Use this runbook:

• when joining a new Bug Bounty program.

• before starting a new research engagement.

• when program scope changes.

• when returning to an old target.

• when a new asset is discovered.

• when wildcard scope is unclear.

• when third-party infrastructure appears.

• before configuring automated reconnaissance.

• when testing restrictions have changed.

• before expanding testing into mobile, cloud or API assets.

Runbook Outcome

At completion, you should have:

Validated Program Profile

Current Scope Snapshot

In-Scope Asset Register

Exclusion Register

Testing Restrictions

Third-Party Register

Automation Limits

Scope Decision Log

Target Priority List

Research Authorization Decision

Required Inputs

Before starting, obtain:

Program Policy

In-Scope Asset List

Out-of-Scope Asset List

Testing Restrictions

Disclosure Policy

Safe-Harbor Language

Automation Rules

Vulnerability Exclusions

If any of these are unavailable, document the missing information.

Required Records

Create or update:

01 Program_Profile.md

02 Scope_Register.csv

03 Exclusion_Register.csv

04 Testing_Restrictions.md

05 Third_Party_Register.csv

06 Scope_Decision_Log.md

07 Target_Priority_Matrix.csv

08 Scope_Snapshot.md

Phase 1 — Program Intake

Step 1 — Open the Official Program Policy

Use only the current official program source.

Do not rely solely on:

Old Notes

Screenshots

Search Results

Community Posts

Previous Scope

as the authoritative source.

Step 2 — Record Program Identity

Document:

Program Name

Program Platform

Program URL

Date Reviewed

Researcher Account

Disclosure Type

Example:

## Program Information

Program:

NovaCloud Security Research Program

Reviewed:

YYYY-MM-DD

Program Type:

Public Bug Bounty

Status:

Active

Step 3 — Record Business Context

Document what the organization provides.

Examples:

SaaS Platform

Financial Services

E-Commerce

Cloud Storage

Developer Platform

Mobile Application

Ask:

What Does
This Organization
Protect?

Phase 2 — Extract Explicit Scope

Step 4 — Identify Explicit In-Scope Assets

Copy every explicitly authorized asset into:

02 Scope_Register.csv

Recommended fields:

Asset	Type	Scope Basis	Restrictions	Status

Possible asset types:

Domain

Subdomain

Wildcard

IP Range

Web Application

API

Mobile Application

Cloud Asset

Step 5 — Mark Explicit Scope

Use:

Explicit

when an asset appears directly in the program policy.

Example:

api.example.com

should be recorded as:

Scope Basis:
Explicit

Step 6 — Identify Wildcard Scope

Look for entries such as:

*.example.com

or:

*.labs.example.com

Document them separately.

Do not immediately interpret wildcard scope as:

Everything
Related to
the Organization

Phase 3 — Validate Wildcards

Step 7 — Interpret the Wildcard Boundary

For:

*.labs.example.com

potentially covered hosts may include:

api.labs.example.com

dev.labs.example.com

But it does not automatically include:

example.net

vendor.example

cloud-provider infrastructure

Step 8 — Record Wildcard Questions

Document uncertainties such as:

Does the wildcard
include the root host?

Are newly discovered
subdomains covered?

Are cloud aliases
covered?

Step 9 — Use Unknown When Necessary

If the answer is unclear:

Scope Status:
Unknown

Operational decision:

Do Not
Actively Test

until clarified.

Phase 4 — Extract Exclusions

Step 10 — Identify Explicit Out-of-Scope Assets

Copy all excluded assets into:

03 Exclusion_Register.csv

Recommended fields:

Asset	Type	Exclusion Reason	Action

Use:

Do Not Test

as the operational action.

Step 11 — Record Vulnerability Exclusions

Programs may exclude findings such as:

Self-XSS

Missing Headers

Rate Limiting

Username Enumeration

Clickjacking

Informational TLS Issues

depending on policy.

Record these separately from:

Asset Scope

because:

In-Scope Asset
      ≠
Every Vulnerability
Eligible

Phase 5 — Identify Third-Party Boundaries

Step 12 — List Third-Party Services

Applications may use:

Payment Providers

Analytics

Authentication Providers

Support Platforms

CDNs

Cloud Services

Customer Integrations

Create:

05 Third_Party_Register.csv

with:

Domain/Service	Purpose	Relationship	Scope	Action

Step 13 — Apply the Ownership Rule

Ask:

Does the Target
Operate This Asset?

Is It Explicitly
Authorized?

If not:

Do Not Test

Step 14 — Do Not Follow Third-Party Chains

Avoid:

Target Application
      ↓
Vendor
      ↓
Vendor Infrastructure
      ↓
Cloud Provider
      ↓
More Systems

unless each stage is explicitly authorized.

Phase 6 — Extract Testing Restrictions

Step 15 — Identify Prohibited Testing

Look for restrictions such as:

Denial of Service

Social Engineering

Password Spraying

Credential Stuffing

Physical Testing

Destructive Actions

Data Exfiltration

High-Rate Scanning

Create:

04 Testing_Restrictions.md

Step 16 — Convert Policy into Technical Controls

Example:

Policy:

Maximum 10
requests per second

Operational setting:

Recon Rate:
≤ 10 requests/sec

Policy:

No Customer Data Access

Operational control:

Use Researcher-Controlled
Accounts and Objects

Phase 7 — Automation Validation

Step 17 — Determine Whether Automation Is Allowed

Classify:

Allowed

Allowed with Limits

Not Allowed

Unclear

Step 18 — Configure Safe Defaults

If automation is permitted, use:

Low Concurrency

Explicit Scope Filtering

Limited Retries

Reasonable Timeout

No Exploit Automation

Step 19 — Configure Exclusion Filters

Before automated discovery, ensure:

Excluded Domains

Third Parties

Unknown Assets

are filtered.

Step 20 — Apply the Automation Gate

Use:

Candidate Asset
      ↓
Scope Validation
      ↓
In Scope?
     / \
   Yes  No
    ↓    ↓
Process Stop

Phase 8 — Review Data Handling Rules

Step 21 — Determine Permitted Data Access

Look for language covering:

Customer Data

Personal Information

Credentials

Secrets

Production Data

Step 22 — Prefer Controlled Test Data

Use:

Account A

Account B

Tenant A

Tenant B

Test Objects

whenever possible.

Avoid:

Unknown Customer
Data

Step 23 — Define Data Stop Condition

Example:

If Real Customer
Data Appears,

Stop Testing,

Do Not Enumerate,

Preserve Minimal Evidence.

Phase 9 — Review Safe Harbor

Step 24 — Identify Safe-Harbor Conditions

Record whether the program protects good-faith research when performed:

Within Scope

Within Rules

Without Intentional Harm

With Responsible Disclosure

Step 25 — Do Not Treat Safe Harbor as Unlimited Authorization

Safe harbor does not override:

Scope

Restrictions

Third-Party Ownership

Data Rules

Phase 10 — Classify Assets

Step 26 — Assign Business Function

For each in-scope asset classify:

Marketing

Authentication

Main Application

API

Admin

Files

Payments

Developer

Mobile

Cloud

Legacy

Step 27 — Record Authentication Requirement

Classify:

Public

Authenticated

Privileged

Unknown

Step 28 — Record Data Sensitivity

Use:

Low

Medium

High

based on likely functions.

Step 29 — Record Complexity

Consider:

Number of Roles

Number of Objects

Workflow Complexity

API Usage

Cloud Integration

Multi-Tenant Behavior

Phase 11 — Prioritize Targets

Step 30 — Build Target Priority Matrix

Create:

07 Target_Priority_Matrix.csv

Recommended fields:

Asset	Function	Auth	Sensitive Data	Complexity	Priority

Use:

P1 — Immediate Research

P2 — Secondary Research

P3 — Low Priority

Step 31 — Prioritize Security Boundaries

Increase research priority for areas involving:

Authentication

Private Data

Tenant Isolation

Administrative Access

Payments

File Sharing

Account Recovery

Cloud Identity

Step 32 — Do Not Confuse Priority with Severity

Remember:

P1 Target
      ≠
Critical Vulnerability

Priority only means:

Spend Research
Time Here First

Phase 12 — Create Initial Research Questions

Step 33 — Convert Business Functions into Questions

Example:

Private Files

becomes:

Can User B
Access User A's
Files?

Example:

Organizations

becomes:

Can a Member
Perform Admin
Actions?

Step 34 — Create Initial Hypotheses

Use:

Actor

Action

Target

Expected Control

Potential Failure

Example:

A standard user
may be able to access
another tenant's project
if the API fails to
validate tenant ownership.

Phase 13 — Scope Decision Logging

Step 35 — Record Every Ambiguous Asset

Create:

06 Scope_Decision_Log.md

Example:

## Decision 001

Asset:

cdn.example.com

Observation:

Referenced by the
main application.

Policy:

Not explicitly listed.

Decision:

Scope unclear.

Action:

Do not actively test
until confirmed.

Step 36 — Record Third-Party Decisions

Example:

## Decision 002

Asset:

analytics.vendor.test

Observation:

Loaded by application.

Classification:

Third-party analytics.

Decision:

Out of scope.

Action:

Exclude from recon
and testing.

Phase 14 — Scope Snapshot

Step 37 — Save a Current Scope Snapshot

Create:

08 Scope_Snapshot.md

Include:

Date

In-Scope Assets

Out-of-Scope Assets

Restrictions

Automation Rules

Safe-Harbor Notes

This gives you:

Historical
Authorization Context

Phase 15 — Final Authorization Gate

Before technical testing, answer:

Is the Target
Explicitly Authorized?

Is the Testing Method
Allowed?

Are Restrictions
Configured?

Are Third Parties
Excluded?

Are Data Rules
Understood?

If every answer is:

Yes

proceed.

If any answer is:

No
or
Unknown

stop and resolve it first.

Operational Decision Tree

Use:

New Program
      ↓
Read Policy
      ↓
Extract Scope
      ↓
Extract Exclusions
      ↓
Extract Restrictions
      ↓
Check Third Parties
      ↓
Check Automation
      ↓
Check Data Rules
      ↓
Check Safe Harbor
      ↓
Classify Assets
      ↓
Prioritize Targets
      ↓
Authorization Gate
      ↓
Proceed to Recon

New Asset Decision Tree

Whenever recon discovers a new asset:

New Asset
      ↓
Explicitly In Scope?
     / \
   Yes  No
    ↓    ↓
Check  Related by
Rules  Wildcard?
        / \
      Yes  No
       ↓    ↓
   Validate  Unknown
   Wildcard    ↓
       ↓      Stop
   Authorized?
      / \
    Yes  No
     ↓    ↓
   Test  Stop

Third-Party Decision Tree

Referenced Service
      ↓
Target Controlled?
     / \
   Yes  Unknown/No
    ↓        ↓
Explicitly    Third Party
Authorized?      ↓
 / \            Stop
Yes No
 ↓   ↓
Test Stop

Scope Drift Indicators

Stop and review if you notice:

Testing New Root Domains

Following Vendor Infrastructure

Scanning Shared IP Ranges

Following Cloud Provider Ranges

Testing Acquired Companies

Testing Customer Integrations

Testing Related but
Unlisted Assets

Scope Drift Recovery Procedure

If scope drift occurs:

Stop Activity
      ↓
Identify Last
Confirmed Asset
      ↓
Record What Happened
      ↓
Remove Unauthorized
Targets from Queue
      ↓
Review Policy
      ↓
Resume Only
Within Valid Scope

Escalation Conditions

Seek clarification from the program when:

Wildcard Interpretation
Is Ambiguous

Cloud Alias Ownership
Is Unclear

Mobile Backend Scope
Is Unclear

API Domain
Is Not Listed

New Acquisition Asset
Appears

Program Rules
Conflict

Stop Conditions

Immediately stop testing a target if:

Asset Is Explicitly
Out of Scope

Asset Is Third Party

Ownership Is Unclear

Testing Method
Is Prohibited

Real Customer Data
Is Exposed

Unexpected Operational
Impact Occurs

Program Scope
Changes

Evidence to Preserve

For program intake, preserve:

Program Policy Snapshot

Scope Snapshot

Restriction Notes

Scope Decisions

Priority Matrix

Do not collect vulnerability evidence yet unless a security issue appears incidentally.

Quality Checklist

Before closing the runbook, confirm:

[ ] Program policy reviewed

[ ] Program profile created

[ ] Scope extracted

[ ] Wildcards reviewed

[ ] Exclusions extracted

[ ] Vulnerability exclusions recorded

[ ] Third parties identified

[ ] Testing restrictions recorded

[ ] Automation rules recorded

[ ] Data handling rules recorded

[ ] Safe harbor reviewed

[ ] Assets classified

[ ] Priorities assigned

[ ] Scope decision log updated

[ ] Scope snapshot saved

[ ] Final authorization gate passed

Runbook Success Criteria

This runbook is complete when you can clearly state:

What I Can Test

What I Cannot Test

Which Methods
I Can Use

Which Services
Are Third Party

Which Restrictions
Apply

Which Assets
I Will Research First

and

Why I Am
Authorized to Proceed

Common Failure 1 — Testing Before Policy Review

Incorrect:

Join Program
      ↓
Run Recon
      ↓
Read Rules Later

Correct:

Policy
      ↓
Scope
      ↓
Rules
      ↓
Recon

Common Failure 2 — Scope by Ownership

Do not assume:

Organization Owns It
      =
Program Authorizes It

Program authorization is the deciding factor.

Common Failure 3 — Scope by Association

Do not assume:

Application Uses It
      =
It Is In Scope

This is especially important for:

Payments

Analytics

Cloud

Authentication Providers

Common Failure 4 — Wildcard Overreach

Do not turn:

*.example.com

into:

All Company Infrastructure

Common Failure 5 — Ignoring Testing Restrictions

An in-scope asset does not mean every technique is permitted.

Example:

api.example.com

may be in scope while:

DoS Testing

remains prohibited.

Common Failure 6 — Unlimited Automation

Do not interpret:

Automation Allowed

as:

Unlimited
Traffic

Common Failure 7 — Testing Unknown Assets

Use:

Unknown

as a legitimate status.

Unknown means:

Stop

not:

Probably Safe

Common Failure 8 — Ignoring Customer Data Rules

A confirmed vulnerability does not justify:

Mass Data Access

Use controlled evidence wherever possible.

Operational Principle

The most important principle in this runbook is:

Authorization
      ↓
Scope
      ↓
Method
      ↓
Testing

Never reverse that sequence.

Professional Workflow

Your operating model should be:

Program Intake
      ↓
Policy Review
      ↓
Scope Validation
      ↓
Third-Party Review
      ↓
Restriction Review
      ↓
Automation Configuration
      ↓
Data Handling Controls
      ↓
Asset Classification
      ↓
Target Prioritization
      ↓
Authorization Gate
      ↓
Reconnaissance

Key Takeaways

Remember:

Owned
      ≠
In Scope

Related
      ≠
Authorized

Wildcard
      ≠
Unlimited

Referenced
      ≠
Target

Automation Allowed
      ≠
Unlimited Automation

In-Scope Asset
      ≠
Every Technique Allowed

Safe Harbor
      ≠
No Boundaries

The first responsibility of a professional Bug Bounty Hunter is not:

Find a Bug

It is:

Know the
Authorization Boundary

Runbook Output

At completion, archive or update:

01 Program_Profile.md

02 Scope_Register.csv

03 Exclusion_Register.csv

04 Testing_Restrictions.md

05 Third_Party_Register.csv

06 Scope_Decision_Log.md

07 Target_Priority_Matrix.csv

08 Scope_Snapshot.md

Handoff to Next Runbook

Once the authorization gate passes:

Program
      ↓
Scope
      ↓
Restrictions
      ↓
Priority
      ↓
Authorized to Proceed

move to:

Next Runbook

➡️ Runbook 02 — Reconnaissance and Attack Surface Discovery

The next runbook will operationalize:

Scope-Aware Asset Discovery

Subdomain Collection

DNS Validation

HTTP Validation

Technology Mapping

API Discovery

JavaScript Recon

Cloud Signal Analysis

Third-Party Separation

Attack Surface Prioritization

The transition is:

Runbook 01
Program Intake
and Scope Validation

      ↓

Runbook 02
Reconnaissance
and Attack Surface Discovery

➡️ Next: Runbook 02 — Reconnaissance and Attack Surface Discovery