← research
Public-source retrospective30 September 2026Checked 11 October 20265 min read

Public Discovery Is Not Permission to Scan

Why RedBlue keeps public asset research separate from direct testing, and what NIST and bug-bounty scope guidance say about authority.

AuthorisationEASMResearch ethics
Public asset discovery stopping at an authorisation gate before direct testing
Public asset discovery stopping at an authorisation gate before direct testing. Editorial illustration.

Finding an internet-facing asset answers “what exists?” It does not answer “what am I allowed to do to it?”

This distinction sounds basic until an automated discovery pipeline returns a plausible domain, certificate name, or cloud endpoint. The technical next step is easy to imagine. The authorised next step may be to stop.

Question

What boundary should separate public-source asset research from direct exposure testing, especially when automation can move from one to the other in seconds?

Method

I compared three kinds of primary guidance: NIST’s technical testing guide, HackerOne’s asset-scope model, and Bugcrowd’s safe-harbour guidance. I looked for the minimum information that turns a discovered asset into an authorised testing target.

This is an engineering interpretation, not legal advice. Programme terms and applicable law require qualified review in their own context.

Evidence

NIST SP 800-115 defines rules of engagement as the guidelines and constraints established before a security test. Its template calls for purpose, scope, assumptions, limitations, and risks. The sequence matters: authority and boundaries exist before intrusive activity.

HackerOne’s scope guidance models programmes as explicit assets with identifiers, submission eligibility, bounty eligibility, and attached instructions. An organisation may choose open scope, but that is a declared programme property, not something a researcher can infer from ownership.

Bugcrowd’s safe-harbour guidance is equally direct about the relationship. It asks programme owners for an exhaustive list of in-scope properties covered for good-faith testing and notes that properties outside that grant lack the same authorisation or safe harbour.

Finding

I use a two-stage boundary in RedBlue. Public research may collect passive facts, candidate domains, ownership evidence, and programme references. Direct checks require an exact asset, an approval record, and explicit authorisation for the intended activity.

The boundary also improves data quality. A candidate can remain pending while ownership or programme scope is resolved. That is more honest than quietly promoting a related hostname into a tested asset because a certificate or search result mentioned it.

Limitations

Public and passive are not perfect synonyms. Some data sources impose their own terms, rate limits, or privacy considerations. Operators must review those constraints separately.

Scope can also change. A previously authorised asset may be removed, and an organisation can own infrastructure that is still excluded from a programme. Current programme terms and a recorded approval take precedence over historical discovery.