Security

• The platform runs on Google Cloud in Frankfurt, Germany: the application, the database, the file store for exploit evidence and the keys that protect them. The website and dashboard are served from Vercel, with server functions in Frankfurt.
• The database accepts only TLS connections and has no public address. Every customer's rows are separated by database row-level security, so a query made for one organization cannot return another's data.
• Data is encrypted in transit with TLS, and at rest by the cloud provider's storage encryption. Browsers are told to use HTTPS only for two years (HSTS), and the whole .devdomain is already on the browsers' built-in HTTPS-only list.
• The providers that process customer data, and where, are listed on the subprocessors page.

• Every run executes in its own container sandbox, with a time limit and resource limits, and it is torn down when the run ends. A reconciliation process finds and removes any sandbox an interrupted workflow leaves behind.
• The credentials a run needs (test accounts, custom headers) are read from the secrets vault when the run starts and handed to that run alone as a one-off secret, which is deleted with it.
• Vulnix only tests domains you have proven you own, by a DNS record or through a Cloudflare or Vercel connection. Internal networks and Active Directory are out of scope.

What is not built yet. Isolation is enforced at the container and credential level. A run does not sit in its own virtual machine, and the cluster does not yet enforce a network policy around it. If either matters for your threat model, talk to us before running Vulnix against that target. Both are on our list.

• Test-user credentials, custom headers, DNS provider tokens and your GitHub connection are kept in a dedicated secrets vault, not in the application database. The vault's master key is held in a cloud key management service and the vault is backed up daily.
• The GitHub App sees only the repositories you choose to track, never your whole account.
• Secrets are not written to logs, and error reports are stripped of credentials and request data.

• Customers sign in with a password or Google, with roles per organization (Roles & Access). Session cookies are HTTP-only, secure and bound to the host that issued them.
• API tokens carry scopes and can never exceed the role of the person who created them. AI apps connect through OAuth, and owners and admins can turn that off or cap what a connection may do.
• Vulnix staff use a separate console on its own host, with two-factor authentication that has no grace period, and every staff action is written to an audit log.

• The dashboard runs under a strict Content-Security-Policy with per-request nonces, so injected scripts do not run. Framing is denied, and the security headers are checked by automated tests.
• Mail from vulnix.dev is authenticated with SPF, DKIM and a DMARC policy that quarantines forged messages.
• Webhooks we send are signed, and the demo account is read-only by construction.

• Live service status and incident history are on status.vulnix.dev, probed from outside our own network.
• Metrics and logs are watched by automated alert rules that email the team, and errors are tracked with credentials removed.

Vulnix Dev, Inc. does not hold a SOC 2 report or an ISO 27001 certificate today, and we do not display badges we have not earned. What we can give a security review now:

• This page, the subprocessor list and our data processing terms.
• Written answers to your security questionnaire, sent to hello@vulnix.dev.
• On request, a walk-through of how a run is isolated and how credentials are handled.

The pentest report Vulnix produces is evidence of testing, not an attestation: it names no human tester, so treat it as supporting evidence for an audit and check with your auditor first.

Please report a suspected vulnerability in Vulnix privately to support@vulnix.dev rather than opening a public issue. Include what you found, the steps to reproduce it and the impact you see. Our contact details are also published in security.txt. Please do not test against other customers' data or degrade the service.