Home / Security
Security and deployment
Updated 23 October 2026
Vardion runs on your own server or on our hosted console. This page sets out how it is deployed, where data is kept, how access is controlled and every outbound connection it makes.
Deployment
- One Docker service on a Linux server. State is kept in a Postgres server inside the container, reached on a local socket only, so Vardion holds no database password.
- The console listens on the loopback address and is reached through an SSH tunnel.
- To publish it, the bundled Caddy configuration adds automatic HTTPS. Until the first account exists, only a health check is served.
- The hosted console keeps active scanning switched off, so it sends no scan to your servers. To scan your servers, run Vardion on your own server, where the scans and findings stay.
- Backup and restore commands write the configuration and data as one archive. Credentials are included only on request.
Data
- Findings, records and reports are stored on your server, or in your own workspace on the hosted console.
- API keys and webhook addresses are never displayed, logged or exported. They are left out of backups unless requested.
- A credential or secret found by a scan is never stored. The finding records the fact and the location.
- The console's pages load no third-party scripts, fonts or images.
Access
- Five roles from viewer to owner, each limited to the workspaces it is granted.
- Passwords hashed with scrypt. Sessions end after 12 idle hours or 7 days.
- Two-step verification with recovery codes, which the sign-in policy can require.
- Single sign-on through OpenID Connect with PKCE, and provisioning through SCIM 2.0.
- Failed sign-ins are limited per account name and per address, and the limits survive a restart.
- Requests that change data are refused when they come from another site.
Audit
- Every change to scope, settings, approvals and accounts is written to the audit log.
- Each entry carries a hash of its contents and of the entry before it, so an edited, deleted or inserted entry is detected and named.
- On your own server, the log can be streamed to your own collector.
Scanning safeguards
- An address is scanned only after it is approved, or when it sits in a range or cloud account declared as yours. An express run, which you start, approves the addresses that show no sign of a CDN, WAF, cloud range or third-party reverse name; each approval it makes is listed under Approvals and in the audit log, and can be revoked.
- Private addresses are never included in an internet-facing scan.
- Scans leave out denial-of-service, intrusive and fuzzing checks. Vulnerability checks are capped at 50 requests a second per host by default, and every web request carries an identifying User-Agent.
- Widening the scope requires a typed confirmation of the exact change, writes an audit entry and backs up the previous file.
- The owner can pause every scan and block ranges for all workspaces. A scan window keeps unattended scans to set hours.
Outbound connections
| Destination | Purpose | When |
|---|---|---|
| Approved addresses | Port, service, certificate, web and vulnerability scans | Each scan |
| Discovery sources used by subfinder, and crt.sh | Names under the scope domains, lookalike domains and new certificates | Each discovery run, passive check and supplier watch |
| XposedOrNot and Hudson Rock | Leaked credentials for the scope domains (the domain is sent, never an address or a password) | Each passive check |
| IANA | The RDAP bootstrap file that names each registry | Passive DNS check |
| DNS resolvers and Team Cymru's DNS service | Name resolution and the network owner of each address | Discovery and passive checks |
| Domain registries over RDAP | Registration expiry, registrar and transfer lock | Passive DNS check |
| CISA, ENISA, OSV, NVD and MITRE D3FEND | Known exploited vulnerabilities, EUVD identifiers, package vulnerabilities and the countermeasure catalogue's release | Daily while enabled, or on request |
| GitHub, PyPI and the ZAP project | Scanner release check | Daily while enabled, or on request |
| The nuclei templates repository | Vulnerability check updates | When templates are updated |
| Shodan, Have I Been Pwned, WhoisXML and RIPEstat | Related assets and leaked credentials | Only with a key configured, or on request |
| GitHub and GitLab | Lockfiles in the repositories you connect, read with a read-only token | Each repository check |
| GitHub code search | Public code that names your domains or brand terms (the search terms are sent) | Each passive check, with a GitHub token configured |
| Amazon S3, Google Cloud Storage and Azure Blob Storage | Whether storage named after your brand is public | Each passive check, when switched on |
| CertStream | New certificates for names like yours, as they are logged | While the live certificate watch is switched on |
| The integrations you connect | Alerts, tickets, SIEM events, cloud and identity reviews, vulnerability imports and mail | Only when connected |
Reporting a vulnerability
Report a vulnerability in Vardion to support@getvardion.com. The contact is also published in security.txt.
Questions from your security review
Send us your vendor questionnaire, or walk through the deployment in a demo.