The idea
Non-destructive detection means establishing that a weakness exists using evidence that does not require exploiting it: response headers, protocol behavior, version fingerprints, error signatures, reflected inputs that are observed but not weaponized, configuration visible from the outside. It is how experienced testers work on live systems anyway — the swarm just does it systematically, on everything, all the time.
The S0–S3 safety scale
Every tool and every test in the SWR7 swarm carries a safety level. The level decides where it may run and what approval it needs.
| Level | What it does | Where | Approval |
|---|---|---|---|
| S0 · Passive | Observes what is public: DNS, certificates, headers, subdomains, breach corpora — plus the read-only edge analytics you grant access to. Sends no crafted input. | Production | Covered by the RoE, always allowed |
| S1 · Non-destructive active | Lightweight requests that reveal configuration and behavior: TLS handshake analysis, header checks, benign probes for exposed paths, version detection. | Production | Covered by the RoE |
| S2 · Controlled | Targeted tests that send crafted but safe inputs: authentication flow checks, injection detection with non-persistent payloads, directory enumeration within rate limits. | Staging; production only in a window you authorize in writing | Explicit go, logged |
| S3 · Intrusive | Exploitation-grade testing: brute force, fuzzing, exploit verification, load-like patterns. | Staging only | Signature on the RoE for the specific target and window |
What "gated" means in practice
The gate is not a checkbox in a report. Before any tool runs, the orchestrator checks three things: is the target on the signed allow-list, is the tool's level allowed for that target, and is a valid authorization token 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.
Why this is enough to find most of what matters
A surprisingly large share of real incidents does not come from exotic zero-days but from exposure and drift: an expired certificate, a missing HSTS header after a CDN change, a .git folder or a backup left on the web root, an admin panel on a forgotten subdomain, a dependency with a public CVE, credentials that appeared in a breach dump. All of these are detectable at S0–S1, on production, without risk.
What non-destructive detection cannot fully establish is impact — how far an attacker could actually get. That is what S2–S3 (controlled and intrusive) are for, on staging, when you decide you want that depth.
From finding to fix
Each finding is triaged (is it real, is it reachable, how severe), scored, and turned into a remediation proposal: the concrete configuration or code change, on the root cause. After you apply it, the swarm re-runs the same detection and closes the finding only when it is no longer observed — never on a promise.
Frequently asked questions
Can non-destructive tests still cause problems on a fragile system?
Any external request is a request; SWR7 keeps S0–S1 to a handful of lightweight calls per cycle with per-tool timeouts and rate limits, and the RoE lets you define blackout windows. If a target behaves unexpectedly, the run stops and you are told.
How is a false positive handled?
Each finding is verified before it reaches the report; unverified signals stay internal. If you contest a finding, it is re-checked, and a confirmed false positive is closed with the reason recorded.
Do you keep exploit code?
S3 tooling exists for verification on staging, under signature. It never runs on production, and nothing is weaponized or retained beyond what the report needs.