On this page0
Guide
Run a Security Lab scan
Tell Security Lab which of your hosts it may test, run a scan, work through what it finds, and re-test until each finding is cleared.
Before you start
- This guide assumes you know what a host name and a DNS record are and can have a DNS record added for your domains; if not, do this together with the person who looks after your company’s websites and servers.
- Your role must let you run security scans. In the built-in set, administrators have that permission, and so do members of the “Security & Compliance” group. The “security_analyst” role has it too; no group carries it, so an administrator gives it to a person by hand, as Roles, groups and permissions shows. To register targets, triage findings or set a schedule, it must also let you manage security scopes and findings; otherwise those buttons do not appear.
- A list of the hosts you want tested, and written permission to test every one of them. Only test systems your company owns or is authorised to test.
- Access to the DNS settings for those domains, so you can prove you control them.
Turn it on
Step 1: Check Security Lab is active
Go to Security & ComplianceSecurity SettingsSecurity Lab. Under “LAB ACTIVATION”, the line “Attack Simulations” shows “ACTIVE” or “NOT ACTIVE”. It follows your subscription and cannot be changed on that page, so there is nothing to switch on or save.
When it reads “ACTIVE”, Security & ComplianceSecurity Lab appears in the menu.
Authorise your targets
Step 2: Register a scope
In Security Lab, go to ConfigureScopes & targets. Under “Register new scope”, give it a “Name” and list your hosts in “Allowed hosts (comma-separated)”.
Pick a “Max profile (rules of engagement)”. This is the most intensive scan ever allowed against these hosts: “Safe — passive checks only”, “Standard — passive + active probes” (the default) or “Aggressive — includes destructive (DoS) probes”. You can change it later: click “Edit” on the scope’s row, change the fields and click “Save changes”. Saving asks you to sign in again and is recorded in the audit log. If you change the allowed hosts, you must prove ownership again (step 3).
Two optional sets of fields decide what a remote scan can test in your own app. Without them, a remote scan runs no SQL injection, XSS or object-authorisation test at all:
- “Injectable URL (optional — for SQLi/XSS probes on your app)”: a URL with a query parameter to test, such as a search page. This switches on the SQL injection and XSS checks for remote scans of this scope.
- “BOLA resource URL” with “Owner (B) credential” and “Attacker (A) credential”: a resource that belongs to user B, plus a sign-in token for B and one for a different user A. The check confirms A cannot read B’s resource. It needs both credentials; they are stored encrypted.
Tick “I attest ownership / authorization (required)” and click “Create scope”.
Step 3: Prove you own the domains
The new scope shows “Unverified” with a line beginning “Add DNS TXT: zonitix-site-verification=”. Add that exact value as a TXT record on the domain of each host, then click “Verify”.
The scope then shows “Ownership verified”. Only hosts under a domain that actually carries the record are covered. If some hosts are missing the record, add it there too and verify again.
Step 4: Optional: set rules of engagement
Open “Rules of engagement” under the scope to limit “Max requests/sec”, “Max concurrent hosts”, and a “Window start” and “Window end” for queued external scans. The window is read in your organisation’s time zone, which is set on the Branding page; if none is set it is UTC. You can also set a “Deep-scan cadence (days)” and tick “Back off on 429 / WAF challenge” so scans slow down when your site pushes back. Click “Save rules”. Empty means no limit.
Run the scan
Step 5: Choose the target and profile
On the “Console” view, choose a “Scan profile”: “Safe”, “Standard” or “Aggr.” (Aggressive).
Choose “Internal” to check your instance itself, or “Remote host” to test one of your hosts. For a remote host, enter its address, and tick “I am authorized to security-test this target (or it is within an attested scope).” The box clears whenever you change the target.
Two more options appear for a remote host. To test pages that need a sign-in, paste a credential for that host into “Target auth (optional, e.g. Bearer eyJ… or a cookie)”; it is used for that scan only. If the host’s certificate is expired or self-signed, tick “Scan even if the TLS certificate is untrusted (expired / self-signed) — verification is skipped for this run.” A scan run this way is marked in the audit log.
Step 6: Start it
Click “Run scan”. Aggressive scans ask you to sign in again first, and are the only ones that run the long deep checks (code scanning, CVE matching on open ports, UDP and IPv6, container images), which can take up to 45 minutes each. Only one scan runs at a time. Progress shows at the top, and “Stop scan” cancels the check that is running. To run one check on its own, click it in the list on the left.
Work the findings
Step 7: Read the results
“Needs attention” lists open findings, worst first. Each carries a severity: Critical, High, Medium or Low. “Unknown” means the check could not run; treat it as not checked, not as a pass. Passing checks are under “Compliant”.
Click a finding to open “Finding detail”: the evidence, the “Recommended remediation”, a risk score, and a “CISA KEV — actively exploited” tag when it applies. The “Findings” view shows the same set as a sortable table.
Step 8: Assign and track the fix
In “Finding detail”, type an owner and a ticket reference. Use “Set status…” to mark it “Acknowledge” or “In remediation”. “False positive…” asks for a written justification. “Re-open” puts it back.
“Risk accept…” asks for a justification and an “Accepted until” date, because every accepted risk must expire. For a Low or Medium finding it takes effect when you click “Save”. For a Critical or High finding it only sends a request: the finding stays open until a second person opens the “Exceptions” view and clicks “Approve”. You cannot approve your own request. When the date passes, or someone clicks “Revoke”, the finding reopens.
None of these clears the finding. An acknowledged finding still counts against your score.
Step 9: Re-test to clear it
Once the fix is in, click “Re-test”. There is no “mark as fixed” button: for a finding that came from one of the checks in the list on the left, a clean re-test is what marks it “Remediated (re-scanned)”. If it comes back later, it is flagged “Regressed”.
Some findings do not come from those checks, and “Re-test” tells you so instead of running. Re-check them where they came from: a device finding with Scan moreScan hosts after patching the device; a finding from a software list (SBOM) by uploading the updated file under Scan moreScan SBOM; a cloud or attack-path finding by refreshing the cloud map for that account; a subdomain-takeover finding by running “Discover now” on the “Assets” view.
To re-test on a timer, go to ConfigureSchedule, turn on “Run scheduled scans automatically” and set the “Interval (hours)”, from 1 to 168. Scheduled scans always use the Standard profile.
The same dialog has three more options: “Email the report after each scheduled scan” with a list of recipients, “Continuously scan external scopes” to re-scan every host named in your verified remote scopes each interval (one host at a time; anything not reached carries over), and “Container images to scan (one per line)”, which are checked during an Aggressive scan. To open a Jira issue or ServiceNow incident for each new Critical or High finding, go to ConfigureTicketing; connect Jira or ServiceNow under Integrations first.
What you should see
Your scope reads “Ownership verified”, and the posture header shows a score, the time of the last scan and who ran it.
After two scans, the “History” view compares them as “New”, “Regressed” and “Fixed”.
The other views are “Risk”, “Attack paths”, “Remediation”, “Exceptions” (every accepted risk, who asked, and when it lapses) and “Assets”. The “Export” menu saves the latest report as Markdown, SARIF 2.1.0 or CSV. The Security Lab reference describes each of them.
If something goes wrong
- "Target … is not within an enabled scope whose ownership is verified for this host."
- Add the host to a scope and verify the DNS record (steps 2 and 3). Or tick the authorisation box for this scan, which allows passive checks only.
- "A per-scan attestation (no verified scope) permits only passive/safe checks …"
- A single active check against an unverified host is refused. A full scan in the same situation is quietly lowered to Safe. Verify the host’s scope to run Standard or Aggressive.
- "Scope "…" permits at most the "…" profile …"
- The scan profile is above the scope’s Max profile. Pick a lower profile, or go to Configure, then Scopes & targets, click Edit on the scope, raise Max profile and click Save changes.
- "No matching DNS TXT record found."
- The record is missing or has not spread yet. Check the value matches exactly, wait for DNS to update, and click Verify again.
- Security Lab is missing from the menu.
- In Security Settings, open Security Lab and check Attack Simulations reads ACTIVE. If it reads NOT ACTIVE, your subscription does not include Security Lab (it is part of the Advanced plan). Your role also needs permission to view findings or run scans.
- "Separation of duties: a Critical/High risk acceptance must be approved by someone other than the person who requested it."
- You asked for this risk to be accepted, so you cannot approve it. Ask another person who can manage findings to approve it in the Exceptions view.
- "This finding already has a … exception. Revoke it before creating another."
- A finding can have one accepted-risk entry at a time. Open the Exceptions view, withdraw or revoke the existing entry, then accept the risk again with the new date.
Still stuck? See When something goes wrong, or Contact Zonitix support.