Scope model
A usable scope is an intersection of asset identity, environment, researcher access, permitted action, data boundary, and time. Payment eligibility is a separate decision. An asset can accept vulnerability reports without authorizing active testing, or permit testing without offering a bounty.
Program and access dimensions#
| Dimension | Values | Consequence |
|---|---|---|
| Visibility | Public, unlisted, invite-only/private | Knowing a private program exists does not enroll you |
| Reward model | Paid bounty, discretionary reward, unpaid VDP, contest prize, contracted assessment | Each uses different eligibility and duplicate/judging rules |
| Knowledge | Black box, gray box, white box | Source or credentials improve visibility; neither expands asset scope |
| Deployment | Vendor SaaS, provided sandbox, own self-hosted instance, customer deployment, offline artifact | The same codebase can have different authorized environments |
| Identity | Unauthenticated, self-registered user, issued researcher account, tenant admin, device owner, local low-privilege user | The starting privilege is part of the finding |
| Lifecycle | Supported release, prerelease/beta, exact commit, version range, fixed contest snapshot | Record exact versions and exclusions |
| Timing | Ongoing, limited campaign, live event, private window, paused, closed | Permission can expire even while a queue or old policy remains visible |
| Disclosure | Confidential, coordinated release, platform-approved disclosure, public advisory | Report submission is not permission to publish |
Asset taxonomy#
| Scope type | Identity to record | Do not infer | Primary test boundary |
|---|---|---|---|
| Exact URL or path | Scheme, hostname, effective port, path and stated matching rules | Other paths, ports, redirected hosts or API origins | Server-side handling of the permitted resource |
| Exact hostname | Canonical hostname and permitted protocols/ports | Sibling hosts, parent domain, origin IP, all ports | Application/service on that named asset |
| Wildcard domain | Literal expression, apex rule, depth rule, exclusions | Apex inclusion, acquired domains, third-party service takeover | Included hostname with ownership and policy confirmed |
| Apex/root domain | Literal root hostname; separate wildcard if provided | Every descendant host | Listed root service |
| IP/CIDR | Exact IPv4/IPv6 prefix, protocols, ports, allocation date | Every virtual host, tenant, or CDN customer on that IP | Authorized network listener or service |
| API | Base URL, version, paths, methods, authentication context | Mobile or partner backend because it uses similar tokens | Object/property/function and tenant authorization |
| Repository | Owner/repo, branch, commit, paths, submodules, releases | Git host infrastructure, all organization repos, deployments | Product code and relevant build/runtime behavior |
| Package/library/SDK | Ecosystem, exact package identity, version, artifact digest | Similar package names, downstream users, registry infrastructure | Caller/input privileges and vulnerable execution path |
| Self-hosted product | Product edition, release/image digest, supported configuration | Every publicly reachable installation | Reachable product flaw in a permitted deployment |
| Mobile application | Store URL, package/bundle ID, version/build, platform | All network endpoints contacted by the application | App/OS/user boundary plus separately scoped backend |
| Desktop/native application | Product, platform, version, architecture, signed artifact hash | Every helper, plug-in, online service or OS bug | Process, privilege, document, update or sandbox boundary |
| Browser extension | Extension ID, store, release, browser/version | Other extensions or arbitrary websites | Message origin, permissions and privileged APIs |
| Cloud resource | Account/project/subscription, region, resource ID, principal | Provider control plane or neighboring tenants | IAM/application authorization on permitted resources |
| Container/Kubernetes | Image digest, cluster, namespace, workload, identity | Host, adjacent namespaces, registry or nodes unless included | Workload/controller/host trust as explicitly scoped |
| AI/LLM/agent | Product/model/build, endpoint, tools, tenant, model artifact hash | All model behavior or all connected SaaS services | Data access, tool authority, action and isolation |
| Smart contract/protocol | Chain ID, address, proxy and implementation, block, source commit | Same-name deployments, all chains, every dependency | Listed impact and contract state invariant |
| Hardware/IoT | Model, board revision, firmware/build, interfaces, physical access assumptions | Cloud companion services or other hardware revisions | Boot, update, interface, identity and data trust |
| Firmware/binary artifact | Download provenance, digest, architecture, version | Permission to flash or test any deployed physical system | Artifact parser/runtime or trust mechanism |
| Organization-wide scope | Explicit ownership wording, acquisition exceptions, third-party clauses | Brand/name/certificate similarity proving ownership | Only assets that meet the program's actual definition |
These are common families, not a universal platform enumeration. A program might separately list browser engines, kernels, databases, cryptographic implementations, telecom equipment, vehicles, industrial systems, identity services, or AI model files. Map each to its precise artifact and execution boundary rather than forcing it into a domain-only scanner.
Wildcards and URL matching#
Treat wildcard semantics as a policy question. A program may define *.example.com to cover descendants broadly, while another may enumerate exclusions or interpret depth differently. Do not import TLS certificate wildcard semantics into bounty scope. If the apex is not explicitly covered or the policy is ambiguous, mark it for clarification instead of silently including it.
For your own approved hostname matcher, normalize case and a trailing dot, handle IDNA deliberately, and compare DNS label boundaries. The suffix example.com must not match notexample.com or example.com.attacker.invalid. Exclusions override the broad inclusion rule in your queue. Record the original source string alongside the normalized value.
For URL scopes, parse scheme, host, effective port, and path as separate fields. Do not use an unanchored regex or raw startswith comparison as the authorization engine. Encoded separators, normalization by proxies, path-segment boundaries, alternate ports, and redirect destinations require explicit handling. Even same-host redirects can leave a permitted path or port. A URL appearing in an archived page does not mean it still belongs to the organization.
Third-party boundaries#
An application may be in scope while its payment processor, email provider, identity provider, CDN management API, analytics service, or customer-hosted deployment is not. Test the application's handling of integration data where allowed; do not transfer the program's permission to the provider. HackerOne's safe-harbor text explicitly notes that organizations cannot authorize research on third-party infrastructure and that those parties are not bound by the statement. Gold Standard Safe Harbor.
Similarly, a DNS record pointing to a service is evidence of a dependency, not a license to claim the corresponding bucket, project, tenant, app name, or email domain. Some providers prohibit takeover testing independently of the target program. Use the current provider rules and a non-destructive proof path in the cloud chapter.
Permission to disclose versus permission to test#
security.txt identifies disclosure information. Its presence does not itself authorize testing; the RFC also says the file's domain/IP scope does not automatically extend to parents or subdomains. Follow its policy link and verify currency and provenance. RFC 9116, sections 3.1 and 5.5.
Public source code allows reading and use under its license; it does not grant permission to attack vendor infrastructure or customer installations. A self-hosted lab provides an environment you control, but a reward still depends on the program's accepted products, versions, configurations, attack assumptions, and reporting rules. An unrestricted source review is not necessarily an unrestricted bounty.
Actions are part of scope#
| Action class | Decision before use | Bounded alternative when unclear |
|---|---|---|
| Public source/documentation review | Applicable license, confidentiality, retrieval terms | Read official published artifacts |
| Third-party passive discovery | Provider terms and data handling | Keep candidates outside the active queue |
| DNS/HTTP/service probing | Approved destination, method, rate and testing window | Validate scope first; review existing evidence |
| Authenticated state changes | Owned accounts/data and allowed workflows | Synthetic records in issued test tenants |
| Out-of-band callbacks | Callback service approval and data controls | Owned callback with a non-sensitive unique marker |
| Concurrency, load, fuzzing | Explicit limits and service-impact tolerance | Local harness or small program-approved sequence |
| Credential/secret validation | Specific program rule and ownership | Report location and redacted structure without using it |
| Resource or subdomain takeover | Target and provider authorization | DNS/configuration evidence without claiming resources |
| Social engineering, physical entry, radio tests | Explicit applicable authorization | Do not run a generic bounty workflow against these surfaces |
| Destructive data, fund movement, persistence, pivoting | Usually restricted; exact program permission necessary | Local reproduction and minimum proof of the initial boundary |
Do not invent a default traffic allowance. An internal conservative request limit controls your own tools; it does not replace program permission. Handle 429, health degradation, or unexpected real user data as reasons to stop and reassess.
Turning all.txt into a scoped review queue#
The supplied file contains 5,520 unique nonempty hostname-like entries, predominantly associated by name with a single brand and related domains. This observation is a local string analysis. It establishes neither ownership nor active program status, and no network activity was performed against it.
- Preserve the original file and its hash. Normalize into a separate candidate table without discarding the original value.
- Add discovery source, discovery time, policy URL, policy review time, matching rule, exclusions, environment, allowed techniques, and decision reason. Unknown values stay unknown.
- Resolve the program policy through official sources. Compare exact rules to each candidate. Do not use a third-party scope aggregator as the final authority.
- Assign one status:
candidate,needs clarification,approved for specified actions,excluded, orstale. Approval includes a specific policy snapshot and expiry/review trigger. - Export only the approved subset required for the next action. Keep candidate discovery output separate from the tool input.
- Recheck policy and relevant ownership before a later session. Scope drift should invalidate queued actions, not merely update a dashboard label.
| Candidate example | Known from list | Missing | Decision |
|---|---|---|---|
A hostname containing stage |
A string suggesting an environment | Actual ownership, service, permission, excluded environments | Candidate only |
An api subdomain |
A name that might serve an API | API base paths, accounts, allowed test methods | Candidate only |
A mail or vpn hostname |
A service-like label | Whether network service testing is allowed | Candidate only |
| A regional brand domain | Similar naming | Legal/technical ownership and explicit inclusion | Candidate only |
The inventory is not embedded into this website as a clickable attack queue. The reusable scope template supports working on an approved subset when permission is established.
Admission checklist#
- Program is currently accepting the intended report type.
- Researcher eligibility and private-program enrollment are satisfied.
- Asset identifier, version, environment, and ownership match the policy.
- Exclusions and third-party dependencies have been reviewed.
- Intended techniques, rate, concurrency, and test window are permitted.
- Authentication identity and data used for proof are controlled or issued for testing.
- Safe harbor and disclosure terms have been read without assuming they bind third parties.
- Reward eligibility is recorded separately from permission to test.
- A stop condition and reporting route are recorded.
- Policy changes invalidate pending actions until re-reviewed.
Recheck policy changes before resuming work#
Keep a dated policy snapshot and a small decision log alongside the scope template. Recheck at the start of an active session, before a materially different technique, and before submission or retesting. The sequence below is an operational recommendation; the specific program determines when permission starts or ends.
| What changed | What to suspend or re-evaluate | What can remain in your notes |
|---|---|---|
| Asset removed, engagement paused, invitation revoked, or testing window closed | Pending probes and new interactions with the affected asset; confirm the applicable reporting route for existing evidence | Earlier evidence, its collection time and the policy that applied then |
| New exclusion, lower rate allowance, or narrower allowed method | Jobs using that method and shared worker budgets until their configuration matches the reviewed rule | Passive observations and hypotheses, labeled with their review status |
| Repository branch, product edition, deployment or contract implementation changes | Assumptions about affected versions, reachability and the proof environment | The original pinned reproduction; do not silently relabel it as the new version |
| Reward table, submission cap, deposit, KYC or proof requirements change | Commercial selection and submission readiness; read any transition/grandfathering language | Testing permission, only if the relevant policy still grants it independently |
| Policy cannot be loaded or two official instructions conflict | Actions whose permission depends on the missing or contradictory information | A needs clarification decision; absence of a readable page is not evidence of permission |
For example, Bugcrowd distinguishes an invitation received while an engagement is launching from an engagement that is in progress. GitHub’s July 2026 bounty announcement explicitly distinguished reports before and after its effective date. Treat such timing rules as program-specific evidence, rather than assuming every policy update retroactively changes earlier reports. Bugcrowd invitation and engagement timing, GitHub transition terms.
- The decision records policy URL, retrieval time, effective date when stated, asset/environment and planned action.
- A relevant change suspends affected queued jobs until reviewed.
- Previously collected evidence retains its original version and timestamp.
- Testing permission, open reporting intake and funded reward status are updated independently.
- Any unresolved question names the exact rule or action that needs clarification.
References#
- Foudil, E., and Y. Shafranovich / IETF. RFC 9116: A File Format to Aid in Security Vulnerability Disclosure. April 2022; accessed 11 September 2026. Used for security.txt location, scope and lack of implied testing permission.
- HackerOne. Gold Standard Safe Harbor Statement. 11 August 2025; accessed 11 September 2026. Used for third-party and policy-compliance limits.
- Uploaded all.txt. Local supplied copy; accessed 11 September 2026. Used only for line-level inventory analysis; no public URL or authorization evidence.