The first objection to any external scanner is reasonable: will this break my site? A tool that hammers production into the ground has negative value. Here is how we stay read-only and gentle by design.
Read-only by default
The baseline external scan observes. It reads headers, inspects TLS, resolves DNS, checks for exposed paths from a fixed list, and parses what the server already returns. It does not submit forms, mutate data, or attempt destructive payloads. Active checks that go further are gated and scoped, never the default.
Server-side target validation
Before a single request leaves, we resolve the target host server-side and reject private IPs, localhost, and the cloud metadata endpoint. The worker re-checks at run time too, so a DNS record that flips after verification cannot redirect the scan at an internal system. This is the same SSRF defense we recommend to customers, applied to ourselves.
Bounded concurrency and timeouts
Each scan runs with a capped number of concurrent jobs and per-tool timeouts. A slow target does not get pounded by retries; it gets a bounded budget and a clean result. The worker isolates each scan so one bad run cannot crash the others, and if a scan is interrupted by a deploy, the queue requeues it rather than leaving it half-done.
Honest results over scary ones
The last safety property is about output, not traffic. A passive probe that finds a header missing is reported as exactly that, not inflated into a critical. Severity ceilings keep passive findings honest, and a critical without supporting evidence is downgraded. Safe to run, and safe to trust.