Why a scale
"Safe" is not a property of a test; it is a property of a test on a given target, at a given time, with a given approval. A scale makes that explicit. It lets a client authorize exactly the intensity they want, lets an operator see at a glance what is about to run, and lets an auditor read afterwards what ran and why it was allowed.
The four levels
S0 · Passive
What it does: observes what is already public or already granted. DNS records, certificate transparency, TLS handshake parameters, HTTP response headers, subdomain discovery from public sources, breach corpora for the client's domain, and the read-only edge analytics the client grants access to. Sends no crafted input.
Where: production. Approval: covered by the signed Rules of Engagement; always allowed for targets in scope. Typical findings: expiring certificate, missing HSTS, forgotten subdomain, leaked credentials.
S1 · Non-destructive active
What it does: lightweight requests that reveal configuration and behavior without exploiting anything: TLS configuration analysis, header checks on real pages, benign probes for commonly exposed paths, version detection, uptime and latency measurement from outside. Per-tool timeouts and a request budget per cycle.
Where: production. Approval: covered by the signed Rules of Engagement. Typical findings: exposed .git or backup, debug endpoint, outdated component with a public CVE, weak TLS protocol.
S2 · Controlled
What it does: targeted tests that send crafted but safe inputs: authentication flow checks, injection detection with non-persistent payloads, directory enumeration within rate limits, business-logic probes that create no lasting state.
Where: staging. On production only inside a window the client authorizes in writing, with rate limits and blackout periods set in the Rules of Engagement. Approval: explicit go per target and window, logged in the audit trail.
S3 · Intrusive
What it does: exploitation-grade verification — brute force, fuzzing, exploit confirmation, load-like patterns. It exists to establish impact: how far an attacker could actually get.
Where: staging only. Never on production. Approval: signature on the Rules of Engagement for the specific target and window, plus an explicit go before each run. Nothing is weaponized or retained beyond what the report needs.
Summary table
| Level | Nature | Production | Staging | Approval |
|---|---|---|---|---|
| S0 | Passive observation | Yes | Yes | Rules of Engagement |
| S1 | Non-destructive active | Yes | Yes | Rules of Engagement |
| S2 | Controlled, crafted but safe inputs | Only in a written window | Yes | Explicit go, logged |
| S3 | Intrusive, exploitation-grade | Never | Yes | Signature per target and window + explicit go |
How the levels are enforced
The level is not a label in a report. Before any tool starts, the orchestrator checks three things: the target is on the signed allow-list, the tool's level is allowed for that target, and a valid authorization token is present for the run. If any answer is no, the tool does not start and the refusal is written to the audit trail. A kill switch stops everything, on every target, with one action. The default for every engagement is S0–S1: find without breaking. Moving up is a decision the client takes, in writing, for a target and a window — not a mode the swarm drifts into.
Using the scale in your own program
The scale is deliberately vendor-neutral. You can use it to classify your own tooling, to write the intensity clause of any testing contract, or to answer a regulator's question about what was tested in production and what was not. If you cite it, cite this page: it is the definition.
Frequently asked questions
Is S2 ever run on production?
Only inside a window the client authorizes in writing, with rate limits and blackout periods set in the Rules of Engagement, and with an explicit go logged before the run. By default S2 runs on staging.
Who decides the level of a tool?
SWR7 classifies every tool once, by what the tool can do at its most intense setting, not by how it is usually configured. The classification is part of the Rules of Engagement so the client sees it before anything runs.
Can we authorize S3 on production if we accept the risk?
No. S3 is exploitation-grade and runs on staging only. If you need impact established on a production-identical system, the answer is a production-identical staging environment, not production.