Your attack surface, scopes, and why scanning needs proof of ownership

Before Perimeter scans anything, it has to know two things: what your assets are, and that you’re allowed to scan them. This page covers the inventory, the scope model, and the safety guard that refuses to scan unverified targets.

1 · The attack-surface inventory

Open the Attack surface tab. It lists every discovered asset, split into External (reachable from the internet, found by the hosted ASM runner) and Internal (inside your network, inventoried by the Lookout agent). The demo tenant has 15 assets.

Column	What it tells you
Asset	The hostname / IP / image / repo. A new tag means it appeared since the last discovery (drift).
Type	host, service, cert, container image, IaC repo, internal host, domain controller, etc.
Criticality	How important the asset is. crown jewel assets weight findings higher in the risk score.
Ports / tech	Open ports, detected technologies, and service banners.
Discovery	How it was found: crt.sh (certificate transparency), passive DNS, naabu port sweep, ASN expansion, or Lookout agent inventory.
Open	Count of open findings on that asset (red if non-zero).
Notes	Certificate expiry + issuer for TLS assets.

The seed inventory is realistic sample data. Live discovery (subfinder/httpx/naabu externally, the agent internally) is part of the hosted tier — see Feeds & scheduling for what’s live vs deferred.

2 · Scopes — the roots you’re authorized to scan

A scope is a root you own and have authorized Perimeter to discover and scan under. There are three kinds:

Scope type	Example	Verify method
domain	acme-clinic.com	DNS-TXT record, or a hosted file challenge
cidr (IP range)	203.0.113.0/27	Reverse-DNS match, or ASN attestation
asn	AS64500	RIR (registry) contact attestation

Internal ranges (e.g. 10.0.0.0/16) are “agent-attested” — the Lookout agent runs inside your network, so its presence proves you control the range; scans run on the agent, outbound-only.

Every scope carries a verified flag. In the Attack-surface tab the scope table shows it as either verified or unverified · scan blocked. In the demo, acme-labs.io is deliberately left unverified so you can see the gate in action.

3 · Why scanning needs ownership proof

Actively scanning a target you don’t own is the one thing a vulnerability scanner must never do. It is hostile traffic, and for external targets it can be unlawful. It’s also a classic SSRF / abuse vector: if anyone could type in any domain or IP and have a hosted scanner blast it, the scanner becomes an attack tool. Perimeter prevents this by gating all active scanning on verified ownership.

The rule: an unverified scope is scan-blocked. No discovery, no scanning, and no ingesting of results happens under a scope until you’ve proven you control it.

4 · Proving ownership (DNS-TXT / file challenge)

When you add a domain scope, Perimeter issues a verification token (you can see the shape in the seed: perimeter-verify=9f3a1c7e). To verify:

Copy the token Perimeter gives you for the scope.
Publish it one of two ways:
- DNS-TXT: add a TXT record on the domain containing the token.
- File challenge: host a file at a well-known path on the domain containing the token.
Click verify. Perimeter performs the lookup; on a match it flips the scope’s verified flag to true and active scanning is unlocked.

Deferred / hosted The live DNS-TXT / file-challenge flow runs server-side and is part of the hosted tier. In the local-first console the verification state is modeled and fully enforced — verified scopes scan, unverified scopes are blocked — but the challenge that actually flips the flag is hosted. The demo seed ships scopes already in their verified/unverified states so you can see both sides of the gate.

5 · The scan-authorization guard (defence in depth)

Verification gates scanning at the server. Perimeter adds a second, independent guard right at the engine boundary so that even a misconfigured or compromised runner can’t sneak unauthorized results in. This lives in app/js/scanauth.js and does two things:

Function	What it enforces
assertScannable(scope)	Throws an error if a scope is missing or unverified — nothing can begin a scan against it.
filterIngest(results)	When raw scan results arrive, drops any result whose asset is unknown (not in your inventory) or whose scope is unverified, before the normalize/scan pipeline ever sees it. Returns the kept results plus the dropped ones with a reason for the audit trail.

You can watch this live in the Ingest scan tab: the Trivy sample payload deliberately includes an out-of-scope row, and the ingest summary reports it as dropped (“asset not in inventory — out of scope”). A result under an unverified scope is reported as blocked (unverified scope — ownership not proven).

Two drop reasons you may see: out_of_scope_unknown_asset (the asset isn’t in your inventory) and scope_unverified (the asset’s scope hasn’t been verified). Both are explained in the Error reference.

6 · Drift — what’s new on your attack surface

When continuous discovery finds an asset that wasn’t there before (a new subdomain, a newly exposed port), it’s flagged new. This is how you catch shadow IT and accidental exposures. In the seed, drift is flagged in the data; the live re-discovery scheduler that produces “what changed this week” is Deferred / hosted — see Feeds & scheduling.

Next: Findings & de-noising — how Perimeter ranks and filters the results, or Troubleshooting: scan won’t run.