Security model, tenancy and data handling

Because Enterprise is a multi-tenant managed service, organization isolation is the load-bearing design requirement. Application scope, stored artifacts, background work, and database row-level security are intended to reinforce the same boundary. The Trust Center, not this architecture guide, is authoritative for production verification status.

• API and session design is organization-scoped. The active organization is carried in the session context and membership is rechecked by protected application workflows.
• PostgreSQL row-level security is the database boundary in the target architecture. Production enablement and effectiveness remain part of the control review published in the Trust Center.
• Stored files and background work carry organization context. Reports, exports, and queued scan jobs are designed to retain that scope through processing and delivery.

Switching organizations is designed to re-issue the active organization context rather than granting ambient cross-organization access.

CLI tokens

relixq login runs the device-code flow — you approve in a browser, and no password is typed into the terminal. Tokens are stored in the OS keychain, never on disk in plain text.

API keys

Created with a name, an explicit scope set, and an optional expiry. The full key is displayed once; only a hash is stored. Revocation is immediate through the JTI blacklist, not deferred to expiry.

Integration secrets

Sink credentials are written to the secret store and referenced by name. The raw secret is never persisted in the connection record and is never displayed back.

GitHub App keys

The App private key lives in the secret store. The token broker signs App JWTs, mints short-lived installation tokens, and caches them for 50 minutes.

Password storage

Argon2 hashing, a 12-character minimum with strength checking, lockout after 10 failed attempts, and full session revocation on password reset.

QAST is passive by default and sends zero packets. Active probing sits behind a hard consent gate with defense in depth at four levels. This is the part of the product most likely to appear in a security review.

1. 01

   Const invariants the engine enforces regardless of what anyone signs

   No denial of service. No mutation. Read-only handshake observation only. Automatic halt at any third-party boundary. These are not configurable.

2. 02

   A signed Rules of Engagement document

   A named signatory with a validity window, a scope allowlist where every entry carries a per-target authority attestation, exclusions that override allows, and at least one attested target required before signing. Signing seals the scope cryptographically; editing any sealed field invalidates the signature and re-closes the gate.

3. 03

   Server-side re-assertion

   The orchestrator independently re-checks the gate before any probe starts — an expired window, an active blackout, or an unsigned RoE refuses the run.

4. 04

   Connect-time re-verification

   The probe worker re-checks the resolved IP, the SNI, and any redirect at connect time, so a DNS change after signing cannot silently widen the scope.

• Findings are immutable facts. You never edit a finding, you supersede it. Triage state lives on separate rows, so the trail reconstructs what was known and decided at each point in time.
• The audit chain is hash-linked and verifiable. GET /api/v1/audit/verify-chain checks its integrity independently of the application.
• Closure requires evidence. In the QAST remediation lifecycle, verified fixed and accepted risk both require a rescan or retest confirmation, a scoped exception grant, or a documented compensating control — with a reference an auditor can follow.

A product that detects post-quantum risk should not become a source of it. The target SaaS architecture applies the same crypto-agility principles, while production-verified control claims remain governed by the Trust Center:

• TLS 1.3 target for service-to-service transport.
• Hybrid PQC key exchange target where the platform SDK supports it — the same transition the product recommends.
• Swappable signing and hashing abstractions, so the platform can change algorithms without a rewrite. This is the crypto-agility it measures in your code.
• Zero-trust service posture by design — row-level security, JWT validation against published JWKS, and mTLS between services.