Security
Last updated: April 22, 2026
Veriva analyzes the most sensitive asset your team produces — source code. This page documents the controls, practices, and commitments that protect it. If any part of this is unclear, or you need a detailed security questionnaire, email security@veriva.dev.
1. Compliance roadmap
We are pre-certification. SOC 2 readiness is underway: our security program has been designed from the start to map cleanly to the SOC 2 Trust Services Criteria, with Type I targeted for Q4 2026 and Type II targeted for Q2 2027. Each of the practices below is in force today — certification will attest to them, not introduce them.
- SOC 2 Type I (target Q4 2026): Security, Availability, and Confidentiality criteria.
- SOC 2 Type II (target Q2 2027): Six-month observation window immediately following Type I.
- GDPR + UK GDPR: See our Privacy Policy and DPA. Standard Contractual Clauses available on request.
- Customer security reviews: We complete vendor questionnaires for Enterprise customers. Contact sales to start a review.
2. Tenant isolation
2.1 PostgreSQL row-level security
Every customer-facing database query runs through a restricted veriva_app Postgres role under row-level security (RLS) policies keyed on current_setting('app.current_org_id'). The application layer cannot bypass RLS — even an internal bug in a tRPC procedure that omits an orgId filter cannot return rows belonging to another tenant.
A separate withSystemContext privileged path exists for cross-tenant platform operations (daily rollups, admin dashboards, queue workers). Every use is logged to the append-only audit trail.
2.2 Authorization model
Roles: OWNER, ADMIN, MAINTAINER, REVIEWER, DEVELOPER. Each tRPC procedure declares a minimum role and an optional per-resource scope. Super-admin operations require a second typed confirmation and are audit-logged with actor, IP, and request ID.
2.3 Org impersonation (support)
Super-admins can impersonate an organization for support. Impersonation requires typed confirmation, is audit-logged, and displays a persistent banner to every user in the impersonated org for the duration of the session. Exiting impersonation is a single click from the top bar.
3. Source code handling
Source code is the most sensitive data we touch. Our posture is analyze in memory, persist only what is necessary to explain findings.
- Full source is never persisted. PR diffs and file contents are fetched through your GitHub App installation and processed in-memory during analysis.
- Finding snippets are capped at 200 characters and scrubbed for obvious secret patterns (API keys, private key blocks, AWS access tokens) before persistence.
- Audit-trail artifacts (JSONL files that record the pipeline stage timings per PR) are archived to S3 after 24h and purged from local disk after 30 days.
- GitHub OAuth access tokens are encrypted at rest and used for user-scoped discovery, such as listing GitHub App installations available to your account. Repository analysis runs through your organization's GitHub App installation credentials, which you can revoke at any time from GitHub.
4. Encryption
- In transit: TLS 1.2+ (1.3 preferred) on every public endpoint. HSTS with
max-age=31536000; includeSubDomains; preload. Certificate management via Let's Encrypt / ACM with automatic rotation. - At rest: AES-256 on all Postgres volumes (RDS / Railway managed). S3 buckets enforce
SSE-S3and block all public access. - Secrets: Environment secrets are stored in Railway / Vercel protected environment variables and never committed to source control. Database credentials, Stripe keys, and Bedrock credentials rotate on a schedule and on suspected exposure.
- Session cookies: httpOnly, Secure, SameSite=Lax, signed JWT, short TTL, with CSRF double-submit tokens on every write path.
5. Network and platform controls
- GitHub webhook IP allowlist: The
/webhooks/githubendpoint accepts traffic only from GitHub's published CIDR ranges, refreshed daily from the/metaAPI. - Signed webhooks: Every inbound webhook is verified against its HMAC signature before the request body is parsed. Outbound webhooks to customer endpoints are signed with
Veriva-Signature: t={ts},v1={sig}(HMAC-SHA256). - Rate limits: Per-user 600/min + per-org 2000/min baseline with plan-tier burst windows, enforced at the edge. Abuse triggers exponential backoff and out-of-band alerting.
- SHELL hook sandbox: Custom shell hooks execute inside ephemeral
alpine:3.20containers with--network=none --memory=128m --cpus=0.5 --user nobodyand a 30-second wall-clock SIGKILL. Per-plan invocation caps prevent resource abuse. - AI provider failover: When the primary Bedrock region becomes unhealthy, a circuit breaker fails over to the secondary region within seconds and emits a monitored event.
6. Secure software development lifecycle
- We dogfood. Every Veriva PR is analyzed by Veriva. We cannot ship a regression past our own rule catalog, AI review, or Deep Audit without a human override — and overrides are audit-logged.
- Mandatory review. No PR merges to production without at least one reviewer approval and a green trust score. Branch protections enforce this at the GitHub level.
- Dependency hygiene. Dependabot + our internal slopsquatting / typosquat detector gate new dependencies. We pin versions in lockfiles and reject unpinned ranges for direct dependencies.
- Secret scanning. GitHub Secret Scanning + pre-commit hooks + a CI job that scans the diff for credential patterns. Confirmed leaks trigger immediate rotation.
- Static analysis and types. TypeScript strict mode with
exactOptionalPropertyTypeseverywhere. ESLint, tsc, and the engine's 73+ unit tests must pass before merge. - Change management. Infrastructure and schema changes go through the same PR workflow as product code, with owner-level approval required for destructive migrations.
7. Availability and resilience
- Target availability: 99.9% monthly on the control plane. Published status and 90-day uptime history at status.veriva.dev.
- Backups: Managed Postgres point-in-time recovery with 7-day retention and daily logical backups retained for 30 days. Quarterly restore drills.
- Multi-region AI: Bedrock primary + secondary regions with automatic failover when the circuit breaker opens.
- Graceful degradation: If an AI layer is unreachable, static analysis continues and PRs receive a partial score clearly marked as degraded, rather than blocking the queue.
8. Logging and monitoring
- Append-only audit log. Every write action in your organization (policy change, dismissal, impersonation, role edit, merge override) is recorded with actor, IP, request ID, and before/after diffs. The
veriva_approle has INSERT-only privileges on the audit table — the app cannot delete or rewrite history. - Error monitoring: Sentry with PII scrubbers and short-snippet redaction. 30-day retention.
- Real-user monitoring: PostHog (DNT-respected) for product analytics only; not used for cross-site tracking or advertising.
9. Personnel
Every employee and contractor signs a confidentiality agreement and completes security awareness training on start. Production access is scoped to least privilege, secured by MFA, and revoked within 24 hours of role change or departure. Background checks are run on engineering staff with production access in jurisdictions where permissible.
10. Data subject rights
We support export and deletion of personal data per the Privacy Policy. When an organization uninstalls the GitHub App, operational data is soft-deleted immediately and purged 30 days later. Deletion is cascading across Postgres + S3; we can provide a written confirmation on request.
11. Responsible disclosure
If you believe you have found a security vulnerability, please report it privately to security@veriva.dev. We commit to:
- Acknowledging receipt within 2 business days.
- A first-pass triage assessment within 5 business days, with a target resolution window based on severity (Critical: 7 days, High: 30 days, Medium: 60 days, Low: 90 days).
- Crediting reporters in our release notes, with your permission, once a fix is deployed.
- Safe harbor: We will not pursue legal action against researchers who act in good faith, avoid privacy violations or service disruption, and give us reasonable time to remediate before public disclosure.
Please do not test against other customers' organizations, exfiltrate data beyond what is needed to demonstrate the issue, or run denial-of-service tests.
For PGP-encrypted reports, request our public key from the same address.
12. Contact
Security inquiries: security@veriva.dev. Vendor questionnaires and SOC 2 evidence packages (under NDA) are available to Enterprise customers through their account representative.