Skip to main content

EASM — Guardrails & Access

What EASM is allowed to touch, and the controls that keep it non-intrusive and scoped to the organization's own assets.

Access: what EASM needs from the customer​

Nothing. EASM is fully external and agentless:

  • No credentials, no agents, no installs. The customer provides domains; EASM works from the public internet.
  • Stable egress identity. All EASM traffic leaves from the platform's NAT Elastic IP 13.50.172.131 — the single source address customers can allow-list. (See Production Deployment.)
  • Attributable user-agent. Target-facing tools send a branded S.E.T-Scanner/... user-agent (authorized-scan) so the activity is identifiable in the target's logs (an opt-in browser-blend-in UA exists for WAF-blocked targets). Source: app/scanners/fingerprint.py.

Guardrail 1 — non-intrusive by design (no payloads)​

EASM observes and infers; it never sends an attack payload. The Nuclei template selection excludes every intrusive tag (app/scanners/manifests.py, INTRUSIVE_TAGS):

sqli · xss · rce · lfi · rfi · ssrf · xxe · ssti · crlf · injection · oast · deserialization · traversal · prototype-pollution · fileupload · command-injection · code-injection · auth-bypass · open-redirect · fuzz · dast · bruteforce

Those payload-based checks belong to the active DAST module. EASM's CVE detection is version/banner-based only.

Guardrail 2 — ownership-aware active scanning​

The one stage that actively touches hosts — naabu port scanning — runs only on hosts the organization owns. Each resolved IP is classified (ASN + PTR + tags + an owned allow-list); a host that resolves only to third-party/cloud infrastructure (e.g. ec2-…amazonaws.com, a CDN) is never actively port-scanned, and host-level findings on it are down-ranked to INFO and flagged third_party_hosted.

Why: a host reached via the customer's DNS but owned by a provider isn't the customer's to fix — and isn't ours to actively scan. Source: app/finalize/ownership.py + InputKind.OWNED_HOSTS in app/engine/runner.py.

Guardrail 3 — run-to-completion, watchdog-bounded​

A scan runs to completion (no fixed time cap that could truncate a large surface). A genuinely hung tool is caught by the per-tool inactivity watchdog (app/scanners/_proc.py) — silence on both stdout and stderr past the threshold ends just that tool, not the scan. One scan per org per 14 days (cooldown); failed/cancelled scans don't burn the slot.

What EASM cannot do​

  • Cannot read any customer data — it has no access to the customer's environment at all (it's external).
  • Cannot send exploit/injection payloads (Guardrail 1).
  • Cannot actively scan infrastructure the customer doesn't own (Guardrail 2).
  • Cannot be triggered by anyone outside the org's authenticated API keys.

Who operates it​

EASM is on-demand, started by the customer (or their UI) via the authenticated API (POST /org/scans {"module":"easm"}). It is never auto-triggered. See the Getting started guide for the customer flow and the UI Implementation Guide for the controls.