What we do
What we actually do to your systems
Most security vendors describe outcomes and leave you to guess what will hit your servers on Tuesday. This page answers that instead.
What we check
These are the same category names that appear in your reports. The site does not invent marketing names for things the product calls something else.
Known Vulnerabilities & Exposures
Published vulnerabilities and exposures matched against what your systems actually run.
Web Application Testing
Your web application: injection, cross-site scripting, misconfiguration, exposed administrative surfaces.
Attack Surface Discovery
Subdomains, certificate transparency logs, forgotten hosts, and domains registered to resemble yours.
Encryption & TLS
Certificate validity and expiry, protocol versions, cipher configuration.
Email & DNS Security
SPF, DKIM, DMARC, DNSSEC and CAA — the records that decide whether someone can send mail as you.
Network & Exposed Services
Which ports answer, what is listening on them, and which versions they report.
API Testing
Your documented API, exercised against its own schema.
Cloud Posture
Cloud account configuration, read through credentials you supply and never modified.
What the scanner does to your systems
Four tiers, in plain terms. This is the same account we gave our lawyers, written for you.
| Tier | What it does | When it runs |
|---|---|---|
| Passive | Reads public DNS records and public sources. Nothing reaches your website or applications. Like any lookup, the query itself reaches whoever runs your DNS. | Always. This is the free check. |
| Active, bounded | Sends real requests to detect problems, rate-limited. Disruptive and intrusive test categories are excluded at every depth — not only the shallow ones. | After you prove you control the domain. |
| Can change data | Full-depth web scanning sends genuine attack-style requests. Form submission and API testing with mutations can create or modify records. | Off by default. Each one needs your explicit, recorded consent. |
| Exploitation | Actively attempts to prove a finding by exploiting it. | Not offered. We would rather say so than quietly omit the row. |
Rate limits, request timeouts and per-scan time limits apply at every tier, and every tool runs in an isolated container that can be stopped.
What is off by default, and why
Four things can change data on your systems or make a lot of noise. Each is off until you turn it on, per target, and here is the actual reason.
Full-depth web scanning
Sends real injection and cross-site-scripting requests. Your servers will log it as an attack and a firewall may block us. Enable it per target, after confirming you are authorised.
Form submission
Off because it once created six records on a real site during an anonymous crawl. Turning it on buys coverage of what sits behind your forms, and it is your decision to make.
API testing with mutations
By default the API scan only issues GET requests. Allowing POST, PUT, PATCH and DELETE tests far more of your API and sends real requests that can change live data.
Port and service scanning
A noisier, more distinctive probe than the HTTP checks, so it stays a deliberate choice rather than running automatically.
What happens to a finding
Deduplicated and triaged
A thousand raw results become the handful worth acting on, grouped across runs so the same issue is one item with a history rather than a new row every week.
Evidence, with secrets removed
Each finding carries what proves it — the request, the response fragment, the record — with credentials redacted before storage.
Verify a fix without waiting
Re-run one check against one location in seconds, with no scan credit charged. Asking “did that work?” should not cost anything.
Where the work already happens
Jira, GitHub, GitLab, Linear, ServiceNow, PagerDuty, Opsgenie, Splunk and webhooks — plus a findings API and a CI gate that can fail a build on a new critical. Cloud account findings do not yet reach the trackers, pagers or webhooks; they reach the API and the exports.
Where we stop
The section most vendors leave out.
- This is automated testing with AI triage. It is not a human penetration test, an audit, or a certification.
- The API check currently looks for server errors. Passing it is not evidence that your API is secure or that its business logic is correct.
- Scanner-generated finding text, vulnerability summaries and the AI-written narrative are produced in English, whatever language you read the interface in.
- We do not claim complete security, and we do not claim to find every vulnerability — here, in the contract, or anywhere else.