Security & Compliance Overview

Security posture & guiding principles

Versus connects to a customer's most sensitive infrastructure — firewalls, load balancers, routers, and the credentials that operate them. That places security at the center of the product. Four principles recur through every control below:

Compliance frameworks

Versus is engineered against the control families common to the major frameworks. Standing is stated honestly — several items are formal-audit-in-progress rather than certified today.

The data Versus handles

Effective controls start from knowing what is being protected. Versus handles infrastructure operational data, not consumer PII datasets.

Data in transit Implemented

All communication with and within Versus is encrypted — no plaintext transport of customer data at any hop.

• Client ↔ platform: HTTPS over TLS 1.2+ (1.3 preferred), modern cipher suites, HSTS.
• Collector ↔ control plane: outbound HTTPS/WSS on 443, authenticated with a short-lived signed ES256 bearer token the collector signs with its enrollment key (CSR proof-of-possession, CA-signed enrollment certificate; the token is verified against its public key); the collector also verifies the gateway's server certificate.
• Service ↔ service: private network with TLS; encrypted database connections.
• Device ↔ collector (on-prem): native secure protocols (HTTPS/iControl-REST, SSH); private-LAN traffic stays inside the customer network.
• Signed payloads: task dispatch and update manifests are Ed25519-signed — integrity and authenticity independent of the transport.

Data at rest Implemented

Protected in layers, strongest around the most sensitive data:

• Storage-level encryption of the primary datastore (PostgreSQL) and backup object storage (server-side encrypted).
• Field-level encryption — sensitive columns (device credentials, connection secrets) are encrypted at the application layer before they touch the database, so a raw read never yields plaintext.
• Secret envelope encryption — Vault secrets use AES-256-GCM with a unique data key (DEK) per secret, each wrapped by a key-encryption key (KEK). Compromise of one secret never exposes another.
• Signed license & artifacts — license keys and release manifests are Ed25519-signed; on-prem images verify integrity before activation/update.

Secrets management — the Versus Vault Implemented

Because Versus's crown jewels are infrastructure credentials, secret handling is its most engineered subsystem — a HashiCorp-style secrets engine built for least privilege and tamper-evidence.

• Envelope encryption & key hierarchy: AES-256-GCM, per-secret DEK wrapped by a KEK; key resolution fails closed — if key material can't be established, the secret is denied, never returned degraded.
• Path-based, capability-scoped policies: path-glob policies bound to roles and capabilities, including a distinct session capability disjoint from read (use a secret without seeing it, via PSM). Per-user templating (personal/${user}/*) gives true least privilege; a controlled, audited super-admin break-glass path exists.
• Programmatic access & audit: services fetch via an authenticated service-account API — never by embedding secrets in code — and every access is written to a hash-chained, tamper-evident audit log.

Privileged session management (PSM) Implemented

PSM lets an operator act through a privileged credential without ever seeing it. Versus brokers SSH and HTTPS sessions, injecting the secret at the broker so it never reaches the operator's screen, clipboard, or client.

• Credential injection using the disjoint session capability — the actor drives the session without possessing the secret.
• Session recording for audit and forensic review.
• Tamper-evident trail — session events are hash-chained.
• Rotate-on-close — credentials can be rotated when a session ends, so a captured secret has no lasting value.

Identity, MFA & access control Implemented

• Dedicated IdP (OIDC): a purpose-built identity provider issues asymmetrically-signed (RS256) tokens; applications are relying parties that verify without a shared secret.
• Multi-factor authentication: TOTP plus passkeys / WebAuthn, enforceable as mandatory at the IdP.
• SSO & BYO-IdP: enterprises federate their own identity provider, so access follows their joiner/mover/leaver process.
• RBAC: module- and action-level roles gate what an authenticated user can do — distinct from the row-level data isolation below.
• Session security: short-lived signed tokens, server-side session lifecycle, MFA step-up challenges.

Tenant isolation Implemented

In multi-tenant SaaS, tenant data is separated in the database itself with fail-closed, forced PostgreSQL Row-Level Security. Every tenant-scoped table carries a tenant discriminator and a policy that constrains every read and write to the caller's tenant — a database guarantee, not an application convention. The tenant is derived from a signed token claim, applied per transaction, and the policy errors rather than leaks if context is missing.

Database security

• Least-privilege roles Implemented — tenant traffic uses a non-owner, non-BYPASSRLS role subject to forced RLS; privileged operations use a separate connection.
• Encryption in transit & at rest — encrypted DB connections, encrypted volumes, application field-level encryption for sensitive columns.
• Parameterized access — an ORM/parameterized layer structurally resistant to SQL injection; RLS caps the blast radius of any injection to one tenant.
• Controlled schema change — reviewed, versioned migrations; the RLS policy shape comes from one shared definition so it cannot drift.

Audit logging & tamper-evidence Implemented

Security-relevant events are recorded in hash-chained logs: each entry incorporates a hash of the previous one, so any retroactive alteration or deletion breaks the chain and is detectable — a stronger guarantee than an ordinary append log. Covered: secret access (Vault fetch/reveal), privileged sessions (PSM), administrative actions, and authentication events. Access to audit data is restricted and, in multi-tenant deployments, tenant-scoped.

Application security & secure development Implemented

Recurring automated security scanning runs across code, dependencies, containers, and the running application:

• Standard web defenses against XSS, CSRF, and injection built into the framework and API layer.
• Change management — reviewed, version-controlled changes; traceable deployments.
• Secret hygiene in build — secrets excluded from source, images, and logs; secret scanning enforces it.
• On-prem source hardening Implemented — on-prem images ship compiled bytecode rather than readable source.

Collector / agent security Implemented

The on-prem agent is designed so a customer can grant Versus operational reach without surrendering control of credentials or exposing devices to inbound access. It is outbound-only over bearer-authenticated TLS on 443 (short-lived ES256 token signed with its CA-issued enrollment cert's key, no inbound listener), executes only Ed25519-signed, verified, replay-protected instructions, updates only from signed, checksum-verified manifests (with health-check and rollback), and resolves/injects credentials locally so they never leave the network. A demo Data Mask mode pseudonymizes IPs and object names on the collector. Full detail: Collector Security Architecture.

Cryptography — algorithms & key management

Key management principles: keys are separated by purpose (encryption vs signing; dispatch vs release) and never reused across roles; key material is kept out of source and logs; DR-critical keys are handled under strict custody and never printed or written to shared files; key resolution fails closed.

Infrastructure, hosting & data residency

• SaaS hosting — managed cloud with private inter-service networking, encrypted storage, and a hardened edge (TLS termination, WAF-class protections). Tenant isolation is enforced in-app and in-database.
• On-premises / air-gapped — ESXi OVA, KVM qcow2, or Kubernetes/Helm; the customer controls the full environment and data never leaves their network. Air-gapped installs never phone home; licensing supports fully offline activation.
• Data residency — satisfied by where you deploy: regional SaaS or on-prem in the customer's own jurisdiction.
• Network posture — outbound-only collector connectivity, no inbound exposure to devices, segmented service network, least-privilege service credentials.

Backup, business continuity & DR

• Encrypted backups Implemented — device and platform backups stored in S3-compatible object storage with server-side encryption and a local-disk fallback; access is credential-controlled.
• High availability & DR (on-prem) In progress — a detailed HA/DR and Kubernetes design exists; production HA topology is delivered per engagement.
• Restore validation — backups are restorable; DR runbooks accompany on-prem deployments.

Vulnerability management & incident response

• Continuous scanning Implemented — recurring SAST, dependency/container, secret, and DAST scans surface vulnerabilities on an ongoing basis.
• Patch management — findings drive remediation; the signed auto-update pipeline delivers agent fixes with integrity guarantees.
• Incident response In progress — the tamper-evident audit trail provides the forensic record; a formal IR policy with severities and notification SLAs is part of the SOC 2 formalization.
• Responsible disclosure — a channel for researchers and customers to report issues is maintained.

Data lifecycle, retention & deletion

• Tenant offboarding — data can be exported and then deleted across the platform.
• Retention — telemetry and logs retained per configurable policy; audit logs retained to meet evidentiary needs.
• Secret lifecycle — rotation supported (including rotate-on-close via PSM); revoked secrets are removed from active use.
• On-prem — the customer owns the full data lifecycle within their environment.

Questions a compliance officer will ask — answered