Security

Last updated: April 21, 2026

This page describes the security controls that are actually in place today. We don't list controls we plan to build or certifications we're pursuing as if they already apply. If something isn't here, it isn't in production yet — see Compliance Roadmap for what's coming.

1. Session and Authentication

• HttpOnly session cookies. Session tokens live in an HttpOnly, Secure, SameSite=Lax cookie (ra_session). JavaScript running in the browser cannot read them, so an XSS payload cannot exfiltrate the session.
• HMAC-SHA256 signed tokens. Session tokens are signed with HMAC-SHA256 and verified on every authenticated request using constant-time comparison.
• Idle and absolute session timeouts. Authenticated sessions end after 60 minutes of no user activity and are hard-capped at 24 hours from login regardless of activity. Both limits are enforced server-side on every authenticated request. The values are informed by current NIST session guidance (SP 800-63B Rev. 4, §4.2).
• Recent-auth gate for sensitive actions. Reconnecting Salesforce, rotating credentials, modifying tenant-user roles, live credential tests, and destructive bulk actions require re-verification within the last 15 minutes. If too much time has passed since your last sign-in, the server rejects the request and prompts you to re-verify via magic link. Background polling by the dashboard does not count as activity and cannot keep a session open.
• Instant session revocation on logout. Every user has a monotonic session_epoch counter. Logout increments the counter, so any copy of the session cookie stops working immediately — not just when the token expires. This means a leaked cookie can be killed in one click.
• Identity Platform for login. Authentication runs through Google Identity Platform with magic-link email login and multi-factor authentication support.

2. Role-Based Access Control

Three roles are enforced at the API layer:

• platform_admin — our operations team. Authors scripts, workflows, pipelines, environments, and schedules.
• tenant_admin — your team's admin. Manages users within your tenant, approves coverage requests, views runs and incidents.
• tenant_user — your team's read-only users. Views runs, incidents, and morning briefings.

Every API endpoint that creates, modifies, or triggers runs is gated by the platform_admin role — operator work is never exposed to tenant users even by accident.

3. Salesforce Authentication

• JWT Bearer flow. We connect to your Salesforce org using OAuth 2.0 JWT Bearer — no long-lived refresh tokens stored on our side.
• Per-tenant signing keys supported. Each environment can be configured with its own JWT private key, mounted as a separate Secret Manager secret. This means one tenant's credential exposure has zero blast radius on another tenant's Salesforce org.
• Fail-closed key resolution. If an environment is configured to use a per-tenant key but the key is missing or unreadable, the system refuses to fall back to a shared default — it returns an authentication failure. You cannot accidentally end up signing with the wrong key.
• Access tokens never persisted. Short-lived Salesforce access tokens are held in memory only. We do not write them to the database.

4. Data at Rest and in Transit

• TLS in transit. All client connections terminate on Google Cloud Load Balancer with managed TLS certificates.
• Encryption at rest. Database rows, Cloud Storage objects, and Secret Manager values are all encrypted at rest with Google-managed keys.
• Cloud SQL is not publicly reachable. The Postgres instance has no public IPv4 — the API server reaches it through the Cloud SQL Auth Proxy socket only.
• Tenant isolation at the query level. Every read and write against application tables includes a tenant_id predicate. This is our regression guard against one tenant ever seeing another tenant's data, and it is covered by a dedicated integration test suite.

5. Verification Artifacts

Test runs produce screenshots, HTML reports, and browser video recordings. Because these are captures of a live Salesforce session, they may incidentally contain business data visible on screen at the time. We treat them as sensitive:

• Tenant-scoped. Artifacts are stored in a Cloud Storage prefix keyed by tenant ID, accessed only by authenticated users inside that tenant.
• Default 7-day retention. Our run-cleanup sweep deletes artifacts and their DB rows together after your plan's retention period (default: 7 days).
• 90-day hard ceiling. A Cloud Storage lifecycle policy on the artifact bucket permanently deletes every object at 90 days of age, independent of the application-level sweep. If our cleanup job fails silently, orphans can only survive up to this ceiling.
• Signed URLs with short TTL. Artifact downloads use GCS-signed URLs with a 15-minute expiry, so share-of-link cannot replace share-of-access.

6. Uploads and Input Validation

• MIME allow-list on every upload path. Coverage-request attachments and other file uploads validate Content-Type against an explicit allow-list on the server side. Unknown types are rejected with 415.
• Filename sanitization. Uploaded filenames are normalized on the server to strip path traversal, null bytes, and other shenanigans before they reach Cloud Storage.
• Per-file size cap. Coverage-request uploads are capped at 25 MB per file on the server.
• AST validation on authored scripts. Browser automation test scripts we author pass through an AST validator that rejects dangerous Node APIs — process spawning, filesystem access, dynamic evaluation — before they ever reach the bundle-build step.

7. Content Security Policy

Our web surface ships a strict Content Security Policy. script-src is restricted to 'self' plus the Cal.com embed domain — we do not permit 'unsafe-inline' for scripts. Combined with the HttpOnly session cookie, this means even a successful XSS payload cannot execute arbitrary JavaScript or read the session. (We still permit inline style attributes in our marketing HTML; tightening style-src is on our roadmap.)

8. Logging, Monitoring, and Incident Detection

• Structured logging. The API emits Pino JSON logs with per-request, per-tenant correlation, ingested by Cloud Logging.
• Operational alerting. We run log-based metrics + Cloud Monitoring alert policies on dispatch failures, Salesforce JWT exchange failures, token refresh failures, timeout sweeps, and runner errors. Alerts are routed to our on-call email channel.
• Uptime monitoring. /api/health is probed every minute from three Google regions with a failover alert. An external uptime monitor provides an independent signal during Google Cloud-wide incidents.
• Error tracking. When operators enable it, application errors are captured by Sentry with request, user, and tenant correlation fields, so a given Sentry issue can be traced back to the Cloud Logging line that triggered it.

9. Subprocessors

We use the following service providers to operate Release Assurance. Each one is bound by its own terms of service and data-processing commitments.

• Google Cloud Platform — infrastructure (Cloud Run, Cloud SQL, Cloud Storage, Cloud Logging, Identity Platform, Secret Manager).
• Resend — transactional email delivery (morning briefings, incident alerts, run-completion notifications).
• Cal.com — demo scheduling on our /contact page only. Cal.com does not see any of your Salesforce data.
• Sentry — error tracking (only when enabled by our operations team; the SDK is present in our code but inert when no DSN is configured).

10. Incident Response and Vulnerability Disclosure

If you believe you've found a security vulnerability, email security@ReleaseAssurance.com. We aim to acknowledge within one business day and provide an initial triage within three.

If a security incident affects your data, we will notify affected tenants within 72 hours of confirmed impact. We do not currently operate a public bug bounty program; this may change as the platform matures — see the roadmap below.

11. Data Processing Agreement

A Data Processing Agreement (DPA) aligned with GDPR Article 28 is available on request. Email dpa@ReleaseAssurance.com and we will return a signed copy within one week.

12. Compliance Roadmap

We are pre-launch. No third-party compliance certifications apply today. What we are actively working toward:

• SOC 2 Type I: target Q4 2026 — scoping with auditor underway.
• Full CSP tightening: remove the remaining 'unsafe-inline' on style-src once the marketing HTML is refactored away from inline style="..." attributes.
• Tighter MFA posture: enforce MFA on all platform_admin accounts by default.
• Bug bounty: under evaluation once SOC 2 scoping is complete.

Questions? See our Privacy Policy and Terms of Service, or contact security@ReleaseAssurance.com.