Security & Trust

How we protect the platform and your data

A training range runs untrusted code by design, so the platform around it has to be held to a higher standard. Here is what that looks like in practice — each item is in production today.

verified_user

Every change is tested and scanned

  • • Continuous integration runs the full test suite on every commit before it ships.
  • • Dependencies are pinned and hash-checked; a scanner blocks any fixable known vulnerability.
  • • Every commit is scanned for leaked secrets.
  • • Challenge images are vulnerability-scanned, and a signature policy can require a trusted publisher.
cloud_sync

Your data is backed up and recoverable

  • • The database, accounts and configuration are exported nightly.
  • • Backups are encrypted to a key the operator holds — the private half never sits on a server.
  • • They are shipped off the main host to a separate machine, with retention.
  • • Recovery is drilled, not assumed: a restore has been performed end to end.
admin_panel_settings

Administrative access is controlled and recorded

  • • Administrators can require two-factor sign-in (TOTP); the secret is set up with the identity provider, never with us.
  • • Sensitive actions — granting access, publishing content, banning an account — are written to an append-only log that even the service cannot rewrite.
  • • The highest-privilege actions are gated to a separate super-admin role, a boundary verified in testing.
lan

Challenges are isolated from each other

  • • Challenge containers cannot talk to one another — inter-container traffic is off by default.
  • • Range networks are default-deny: nothing is reachable unless a rule explicitly allows it.
  • • Instance identifiers are keyed, so one player's environment cannot be discovered or addressed from another's.
notifications_active

Failures are noticed

  • • Background jobs — cleanup, expiry, backups — report a heartbeat; a missed one raises an alert.
  • • The challenge host publishes its own faults, and they are watched rather than left to be discovered.
  • • Alerting was proven by stopping a job on purpose and confirming the alert fired.
report

Found something? Tell us

We welcome reports of security issues in the platform itself (as opposed to the challenges, which are meant to be broken). Report privately to security@qvanguard.org and give us a reasonable window to fix it before any public disclosure.

This page describes controls that are live in production. It is a summary, not a compliance attestation; we are happy to walk teams through the details on request.