Prove you own the target first
Scanning a system you do not control is illegal in most jurisdictions and useless as evidence. So the platform will not run active checks against a host until ownership is verified. Verification is per target and is recorded with a signature in a tamper-evident chain, so an auditor can see who authorised what and when. The decision to skip verification is never made by the person requesting the scan.
Passive reconnaissance can proceed on an unverified target, but the active and aggressive phases are held until one of the methods below succeeds. Verification is fail-closed: if it does not pass, the intrusive checks do not run.
- DNS TXT: add a record with the token we give you.
- Well-known file: serve a token file from a fixed path on the site.
- Meta tag: place the token in the page head.
- Admin override: a workspace admin can record a signed, attributed manual authorisation, which is itself an audit event.
What a scan does
A scan is staged. Passive checks read headers, cookies, TLS configuration and the responses your recorded flows already produced. Active checks send crafted requests for injection, authentication and authorisation flaws, misconfiguration and the API-specific classes. Out-of-band checks confirm blind classes such as server-side request forgery by watching for a callback to a listener the platform controls, so the finding rests on observed behaviour rather than a response pattern.
Exploitation beyond confirmation is server-gated. A tenant cannot enable it for itself; it is decided per authorisation record and every decision is an audit event.
What an evidence bundle contains
Findings without this evidence are labelled as unconfirmed observations. They are still shown, because a pattern is worth a look, but they do not count toward a gate and they are not called vulnerabilities.
- The finding: class, severity with the CVSS vector, the engine that produced it, and the affected URL and method.
- The proving request and the response it received, with the exact payload.
- A proof of concept a reviewer can replay, and, for out-of-band classes, the callback record.
- Remediation guidance specific to the class, and a link back to the recorded request it came from (for example req_0012).
Gates and reports
A quality gate can fail a pipeline on any confirmed finding above a severity you choose. Reports export with the evidence attached so a developer can fix the issue without re-running the scanner, and a security reviewer can check the claim without trusting the tool.
Limits
- Automated scanning does not replace a manual penetration test. It finds the classes it has engines for and confirms what it can reproduce.
- Business-logic flaws (price manipulation, workflow bypass) need a person who understands the business. The recorder helps by giving that person the flows and requests to work from.
- Scans generate real traffic against your target. Run them against staging, or rate-limit them, and tell your operations team.
Questions people ask about this
- Does scan data leave our network?
- On cloud tenants, targets, results and evidence are stored in the Mumbai region. Enterprise customers can run the scanner inside their own network so nothing leaves it.
- Which standards do reports map to?
- OWASP Top 10 (2025), OWASP API Security Top 10, CWE identifiers and CVSS scores on every confirmed finding.
Source: /documentation/security-scanner-and-evidence-bundles, updated 2026-09-18. Answers are checked against the shipped product on that date.
Found something out of date? The people who build the module answer the contact form on the home page, and corrections to this guide are dated above. Tell us.