Revsnap Security Whitepaper
Status disclosure. Revsnap is operated by {{LEGAL_ENTITY}}. We hold no third-party security attestations today. We are actively working toward SOC 2 Type II readiness; ISO 27001 is on the longer-term roadmap. Where a control is fully operational it is described in the present tense; where it is in progress it is explicitly marked (roadmap).
1. Executive summary
Revsnap is a multi-tenant SaaS for regression testing Salesforce Revenue Cloud (CPQ) configurations. Customers connect their own Salesforce orgs over OAuth 2.0 (PKCE), capture point-in-time snapshots of pricing and configurator outputs, and run automated comparisons after deployments to detect regressions.
Our security model rests on five pillars:
- No customer secrets at rest in plaintext. Salesforce OAuth tokens are encrypted with
pgsodiuminside Supabase Vault and only decrypted inside the database via a SECURITY DEFINER RPC. - Workspace as the tenancy boundary, enforced by Postgres Row-Level Security (RLS) and corroborated by application-layer checks.
- Signed messages on every machine-to-machine path — Stripe, QStash, and our internal worker triggers all verify HMAC signatures.
- Managed platform primitives — we run on Vercel and Supabase and rely on their platform security (TLS termination, at-rest encryption, regional isolation) rather than building bespoke infrastructure.
- Defence in depth and a documented gap list. Our most recent internal audit (May 2026) is available under NDA, and its remediation roadmap is our backlog.
The audience for this whitepaper is enterprise security, procurement, and privacy reviewers. It answers most standard vendor security questionnaire items; gaps are tracked openly in §15.
2. About Revsnap and the data we handle
| Field | Value |
|---|---|
| Product | Revsnap (regression testing for Salesforce Revenue Cloud) |
| Operating entity | {{LEGAL_ENTITY}} ({{REGISTERED_ADDRESS}}) |
| Primary contact | {{SECURITY_EMAIL}} |
| Customers | Enterprise + mid-market Salesforce admin teams in UK, EU, US |
| Hosting region | {{HOSTING_REGION}} |
Categories of personal and customer data we process are listed in detail in Data Flow §1 and ROPA. At a glance: account identity, Salesforce OAuth tokens (encrypted), customer-captured Salesforce business data (quote/configurator JSON), test execution metadata, billing metadata, and consent-gated product analytics.
3. Architecture overview
Refer to Network Architecture for the diagram and detailed boundary description. In short:
- Frontend & backend: Next.js 15 (App Router) deployed on Vercel.
- Database & auth: Supabase Postgres, Supabase Auth, Supabase Storage, Supabase Vault.
- Asynchronous workloads: pgmq queues drained by a Next.js worker endpoint, triggered by Vercel Cron, Upstash QStash, and
pg_cron+pg_netas a triple-redundant scheduler. - Sub-processors: Vercel, Supabase, Stripe, Resend, Upstash, PostHog (see Sub-processors).
4. Tenant isolation
The full design is documented in Tenant Isolation. Headline properties:
- Every tenant-scoped table is RLS-protected with policies of the form
workspace_id = get_user_workspace_id(). - The application layer additionally verifies workspace membership before issuing queries.
- Supabase Storage objects are workspace-prefixed; access is server-only via the admin client.
- Salesforce tokens in Vault are accessed only via a SECURITY DEFINER RPC that itself filters by the caller's workspace.
A known transitional issue — legacy per-user policies still present on a subset of tables (audit finding H-3) — is being removed in Stage 0 of our roadmap. New tables use workspace policies exclusively.
5. Authentication and access control
Authentication Flow covers the protocol details. Summary:
| Surface | Mechanism |
|---|---|
| End-user web | Supabase Auth (email/password today; MFA via TOTP — roadmap; SAML/OIDC SSO via WorkOS — roadmap) |
| Salesforce org connection | OAuth 2.0 + PKCE-S256; scopes api, refresh_token, offline_access; supports production and sandbox |
| Programmatic / CLI | API keys (Bearer revsnap_<id>_<secret>); SHA-256 hashed at rest; per-key rate limits; revocable |
| Internal staff / admin | Separate ADMIN_HOSTNAME; admin workspace membership required; all admin writes audit-logged |
Role-based access control is workspace-scoped (users.role: admin / user). The Access Control Policy defines joiner/mover/leaver expectations for staff accessing production.
6. Salesforce data handling
- Connection: OAuth 2.0 with PKCE (RFC 7636, S256). The customer authorises the requested scopes against their own Salesforce org and is redirected back to a server-side callback.
- Token storage: Access and refresh tokens are stored in Supabase Vault (
pgsodiumauthenticated encryption). They are referenced fromconnected_orgsby UUID; the plaintext tokens never leave the database except briefly, in request-scoped memory inside our serverless functions, when an API call to Salesforce is being made. - Token refresh: Automatic, ~60 seconds before expiry. Refresh-token rotation is not yet implemented (audit finding L-7, roadmap).
- Customer Salesforce data: We only persist the JSON payloads a customer explicitly captures as snapshots (stored in the private
snapshotsSupabase Storage bucket, workspace-prefixed). Live test execution holds Salesforce response payloads only in request-scoped memory. - Revocation: A customer can disconnect any org from the UI at any time. On disconnect, the Vault secrets are cleaned up (a hardening item — audit L-2 — adds a trigger-based cleanup to prevent orphaned secrets).
7. Encryption
See Encryption Architecture. Highlights:
- In transit: TLS 1.3 everywhere — to the browser, between functions and Supabase / Salesforce / Stripe / Resend / Upstash / PostHog.
- At rest: Platform-managed AES-256 for Postgres and Storage;
pgsodiumauthenticated encryption for the Vault secrets layer. - Application secrets: API keys SHA-256 hashed; webhook secrets stored only as environment variables. Cookie security flags applied.
- Open items: HSTS, CSP, and other HTTP security headers (audit L-6) — planned in Stage 0; documented 90-day key-rotation cadence (audit H-4) — Stage 0.
8. Application security
| Control | Status |
|---|---|
| Input validation | Zod schemas in core API surfaces. Audit M-6: validation coverage being expanded across remaining routes. |
| Rate limiting | Upstash Redis sliding-window per principal on test-run start, status polling, and API-key creation. Admin endpoints — roadmap (audit M-4). |
| Webhook signature verification | Stripe (HMAC), QStash (Receiver.verify with current + next keys), internal worker (HMAC + timing-safe + 30s replay window). |
OAuth state integrity |
Currently includes userId; HMAC signing + nonce-cookie binding is in Stage 0 (audit H-2). |
| Open-redirect prevention | safeRedirect() helper rolling out across login + SSO callbacks (audit H-1). |
| Bot protection | Vercel BotID under evaluation. |
| Session management | Supabase Auth, cookie-bound, refreshed by middleware. |
9. Vulnerability management and SDLC
The Vulnerability Management Policy and Secure SDLC Policy cover this in full. Salient points:
- Code reaches production only via reviewed PR merges on a protected
mainbranch. - Planned CI gates:
gitleakssecret scanning, Dependabot +npm audit, GitHub CodeQL SAST, OWASP ZAP baseline against preview deployments. - Internal security audit cadence: at least annual; the most recent (2026-05-03) is the basis for the current Stage 0 backlog.
- External penetration test: planned annually once revenue justifies it; the first engagement is targeted before SOC 2 Type I.
10. Logging, monitoring, and incident response
- Audit log —
workspace_audit_logtable records workspace-lifecycle events (invite, role change, SSO, API-key creation, etc.). Coverage is being extended (audit M-5) to include billing, schedules, snapshot deletion, and org connection events. - Server logs — currently
console.*based. Migration to structured logging via Pino with sensitive-field redaction is in Stage 1 (audit M-2/M-3). - Product analytics — PostHog, consent-gated, served via a first-party
/ingestproxy. - Uptime / errors — Sentry + status page (Better Stack / Instatus) — Stage 0 roadmap.
Incident response is governed by the Incident Response Policy, including 72-hour controller notification per GDPR Article 33 and a published post-mortem template.
11. Backup and disaster recovery
See Backup & DR Policy.
| Metric | Target |
|---|---|
| RPO (Postgres) | ≤ 24 hours (Supabase PITR retention applies; verify against current plan) |
| RTO (full service) | ≤ 4 business hours |
| Restore test cadence | Quarterly (Stage 1) |
| Off-region replica | Roadmap |
Backups: Supabase PITR + database-backup.yml GitHub Action. Storage objects are part of Supabase's platform backup scope.
12. Sub-processors
The complete current list — Supabase, Vercel, Stripe, Resend, Upstash, PostHog — with purpose, data categories, and hosting regions, is maintained at Sub-processors. Customers receive at least 30 days' notice of any new sub-processor (see policy for the notification mechanism and objection window).
13. Privacy & GDPR
We act as the processor of customer data (Salesforce business data, end-user identifiers shared with us by the customer) and as the controller of our own account/identity data and operational telemetry.
- Lawful bases per processing purpose are documented in the Privacy Policy and the ROPA.
- International transfers rely on the EU SCCs (Module 2 — controller-to-processor) and the UK IDTA, included in the DPA Annex.
- Data subject rights (access, rectification, erasure, portability, restriction, objection) are fulfilled via the DSR Runbook.
14. Compliance roadmap
We claim no current certifications. Our roadmap (see also governance/CHANGELOG.md):
| Stage | Target | Status |
|---|---|---|
| Stage 0 | Customer-facing trust pack + audit-finding Highs resolved | In progress |
| Stage 1 | SOC 2 Type I scope frozen, evidence platform onboarded (Vanta or Drata) | Planned |
| Stage 2 | SOC 2 Type II report (6-month observation) | Planned |
| Stage 3 | ISO 27001 certification | Future |
| Stage 4 | Bug bounty, customer-specific addenda, regional residency options | Future |
15. Known gaps and remediations
We publish them rather than hide them. Each item below is tracked in the internal audit report (May 2026) and the Risk Register:
| Severity | Finding | Status |
|---|---|---|
| High | Legacy per-user RLS policies on a subset of tables (H-3) | Stage 0 — remediation in progress |
| High | OAuth state parameter not HMAC-signed (H-2) |
Stage 0 |
| High | Open-redirect parameters on login / SSO callback (H-1) | Stage 0 |
| High | Documented secret-rotation cadence + secret-scanning in CI (H-4) | Stage 0 |
| Medium | Audit-event coverage gaps (M-5) | Stage 0 |
| Medium | Structured logging with redaction (M-2/M-3) | Stage 1 |
| Medium | Admin endpoint rate limiting (M-4) | Stage 0/1 |
| Low | HTTP security headers (L-6) | Stage 0 |
| Low | Refresh-token rotation (L-7) | Stage 1 |
The full list with severities, code paths, and remediations is in governance/security/audits/2026-05-03-internal.md (available under NDA).
16. Contact
| Topic | Contact |
|---|---|
| Security vulnerabilities | {{SECURITY_EMAIL}} — see also the public SECURITY.md |
| Privacy and data protection | {{DPO_EMAIL}} |
| Legal / contracts | {{LEGAL_EMAIL}} |
| Sales / procurement | {{SUPPORT_EMAIL}} |
17. Document control
| Version | Date | Author | Summary of change |
|---|---|---|---|
| 0.1.0 | 2026-05-15 | Security | Initial public draft. |
Last reviewed: 2026-05-15