Security

DriftWise is designed around defense in depth — no single control is the only thing standing between an attacker and your data. This page summarises the controls we run in production. Exact implementation details (file paths, library versions, private endpoints, threat-model specifics) live in internal documentation; what follows is the posture we expect any security-minded customer to scrutinise.

Summary

Area	Control
Edge	TLS-only, edge rate limiting, bot management
Identity	OIDC, SAML SSO (Team+), SCIM (Enterprise), role-based access control
API authentication	HMAC-peppered API keys with scopes
Tenant isolation	Database Row-Level Security enforced with FORCE, dedicated least-privilege database role
Encryption in transit	HTTPS everywhere, managed database configured to reject plaintext connections, HSTS with preload
Encryption at rest	Cloud-provider-managed disk encryption, cluster Secrets wrapped with a customer-managed key, cloud credentials wrapped with AES-256-GCM before storage
Application defenses	SSRF allowlisting, LLM prompt-injection envelope, XSS sanitisation, strict CSP, request size limits
Platform	Strict admission controls, seccomp RuntimeDefault, hardened node images, keyless cloud-API authentication
Supply chain	SAST, SCA, SBOM generation, vulnerability scanning on every PR
Operations	Audit logging, structured logs, distributed tracing, managed database point-in-time recovery

Network and transport

• TLS-only in transit. All customer traffic reaches DriftWise over HTTPS. The managed database accepts encrypted connections only — plaintext handshakes are refused at the server.
• Edge protection. The public app is fronted by an edge network that provides TLS termination, rate limiting on authentication paths, and bot management. Origin traffic is restricted to the edge.
• Private database. The production database has no public IP — it is reachable only from inside the private network the application runs on.
• Restricted control plane. The cluster's control-plane API is gated to an allowlist of operator IP ranges.
• HSTS with preload. Strict-Transport-Security is served with a long max-age, includeSubDomains, and preload so that standards-compliant browsers refuse to downgrade to HTTP.

Identity and access

• OIDC sign-in. User authentication is handled through an identity broker that issues signed, short-lived JWTs. The backend validates tokens against the broker's public keys on every request.
• SAML SSO. Customers on the Team plan and above can connect their own identity provider via any SAML 2.0–compliant service (Okta, Entra ID, Google Workspace, JumpCloud, and others). See SSO & SCIM.
• SCIM provisioning. Enterprise customers can automate user and group lifecycle via SCIM.
• Role-based access control. Each organization has owner, admin, member, and viewer roles. Security-sensitive mutations (billing, identity provider configuration, role reassignment) require OIDC-backed owner/admin — API keys cannot perform them regardless of scope.
• API keys.
  • Keys are hashed with HMAC-SHA256 and a server-side pepper. Only the prefix is stored in plaintext for display; the full key is shown to the user exactly once.
  • Keys carry scopes (read / write / admin) that are enforced at the middleware layer.
  • Revocations propagate across the fleet quickly via short-lived caches; a revoked key stops working within seconds.

Tenant isolation

Tenant data is isolated at three independent layers — losing any one of them should not leak rows.

1. Application filter. Every repository query that touches a tenant table includes an explicit WHERE org_id = $N clause.
2. Database Row-Level Security with FORCE. Every tenant table has an RLS policy keyed on a per-transaction session variable. FORCE ROW LEVEL SECURITY is applied so the table owner does not silently bypass the policy.
3. Least-privilege database role. The backend connects as a role that owns nothing, has no direct privileges on tenant tables, and cannot inherit privileges from administrative roles. Every query enters a transaction-scoped role switch that carries the caller's org_id; a query that escapes that wrapper returns "permission denied" rather than silently running unscoped.

The combination means a missed WHERE clause no longer leaks data — RLS catches it. A compromised policy does not leak data either — the application filter still runs. And a raw-pool query that bypasses both still fails because the connecting role lacks privileges.

Encryption

• In transit. HTTPS for all client and internal traffic. The managed database is set to accept TLS-encrypted connections only.
• At rest.
  • Customer data lives on cloud-provider-managed persistent storage with envelope encryption enabled by default.
  • Cluster Secrets are additionally wrapped with a customer- managed key before being written to the cluster store. Every Secret decrypt is logged in the key management service's audit logs.
  • Cloud credentials (the AWS/Azure/GCP credentials you attach for scanning) are encrypted with AES-256-GCM using a separate application-layer key before being written to the database. A database-only leak does not expose them.
• Backups. Production databases have automated backups and point-in-time recovery enabled.

Application defenses

• SSRF protection. Every user-supplied URL (webhook endpoints, custom LLM endpoints, state-source URIs) is validated against a public-HTTPS allowlist before any request goes out. Private, loopback, link-local, CGNAT, and metadata-service addresses are rejected. Production boot refuses to start if this guard is bypassed — there is no per-request escape hatch.
• LLM prompt-injection envelope. Untrusted content sent to an LLM (Terraform plan JSON, resource names, webhook bodies, etc.) is wrapped in a clearly-delimited envelope. The paired system prompt asserts the envelope contract so the model distinguishes trusted instructions from untrusted data.
• LLM output is never auto-applied. Generated remediation and Terraform code are returned to a human for review. There is no path in the product where a model's response is automatically applied to infrastructure.
• XSS sanitisation. Markdown rendered in the UI is sanitised with an allowlist sanitiser before being inserted into the DOM.
• Strict Content Security Policy. The UI ships with a narrow CSP — no inline scripts, no eval, no object-src, no frame-src, with per-environment allowlists for network destinations. The CSP is generated at build time and covered by regression tests that guard against accidental loosening.
• Request body size limits. All HTTP endpoints enforce a hard request-body size cap.
• Rate limiting. Authentication paths and expensive endpoints are rate-limited via a distributed in-memory limiter. Platform- LLM usage and plan analyses are separately budgeted.
• Inbound webhooks. Webhooks are authenticated with HMAC signatures and protected against replay by a delivery-dedupe table. Replayed bodies return 200 already_processed without re-running side effects.

Platform hardening

• Strict admission controls. The application namespace rejects privileged, host-path, and capability-bearing containers at the admission controller.
• Seccomp RuntimeDefault. Every application container runs under the runtime's default seccomp profile.
• Hardened node images. Cluster nodes run with Secure Boot and integrity monitoring enabled.
• Keyless cloud-API authentication. Pods authenticate to cloud APIs via short-lived, federated credentials; no long-lived service-account keys live inside the cluster.
• Supply-chain-verified images. Every container image is built in CI (not on developer laptops), produces an SBOM, and is scanned for known vulnerabilities before being promoted. Production SBOMs are archived to durable storage for provenance.

Supply chain

Every pull request runs, as blocking checks:

• Dependency vulnerability scanning. Backend and frontend dependencies are checked against public vulnerability databases, and SBOMs are scanned against known CVEs on every build.
• Static analysis. Multiple complementary SAST tools cover both backend and frontend source trees, surfacing unsafe patterns and security smells before they merge.
• SBOM generation. Software bills of materials are produced for backend and frontend on every build. Production releases archive their SBOM to durable storage.
• Integration tests against a real database. Every PR that touches the backend runs the full integration suite against an ephemeral database container — exercising real row-level security, real schema migrations, and real tenant isolation.
• End-to-end tests. A separate E2E suite drives the real server binary and the real UI via browser automation on every PR.
• CI-built artifacts only. Production container images are built and pushed by the CI/CD pipeline — never from a developer's laptop. The deploy pipeline is gated on all of the above.

Observability and auditability

• Audit log. Security-sensitive mutations (API key create/revoke, cloud account changes, billing state changes, identity provider swaps, role changes) write to an append-only audit log. Entries record the actor, action, target, and timestamp; secrets and raw credentials are never logged.
• Structured application logs. Every request is logged with a request ID, HTTP method, path, status, and latency.
• Distributed tracing. HTTP handlers and LLM calls emit tracing spans for end-to-end request tracing.
• Platform audit logs. Key-management decrypt events, IAM changes, and database admin operations are captured by the cloud provider's audit logging.
• PII scrubbing in telemetry. Client-side telemetry strips emails, UUIDs, JWTs, API keys, and cloud access key IDs before events leave the browser.

Response and recovery

• Point-in-time recovery. Production databases retain backups with PITR enabled.
• Rollback playbook. Every deploy can be reverted via the pipeline without manual surgery.
• Key rotation. Credential peppers, webhook-signing secrets, and database passwords are rotatable without downtime.

Responsible disclosure

Found something? Email [email protected]. We respond within one business day and will work with you to coordinate disclosure.

What's not on this page

This page describes production security. Items we are actively tracking but have not yet shipped — IAM-based database authentication, database mTLS, CSP violation reporting, image digest pinning — are managed on our internal roadmap. We'll move them to this page once they land.