How LaunchGuard secures itself.
We treat the LaunchGuard SaaS as a high-value target because it sits next to our customers' source code. Every piece of the architecture is built with that in mind.
Architecture overview
LaunchGuard is a multi-tenant Next.js + Supabase SaaS. Tenant isolation is enforced through Postgres row-level security, with a service-role queue worker performing privileged operations. Scan engines run in isolated workers and produce normalized findings.
Data classification
Tier 0 (forbidden): raw secret values, customer source code beyond scoped excerpts, payment card data. Tier 1 (sensitive): integration tokens, encrypted at rest. Tier 2 (operational): findings, audit logs, scan metadata.
Access controls
Per-workspace roles (owner, admin, developer, security_reviewer, viewer) gate every API and database operation. Elevated actions (PR creation, Shannon authorization, integration writes) require explicit role checks plus an audit log entry.
Cryptography
AES-256-GCM for tokens and webhook secrets. SHA-256 fingerprints (truncated, salted per workspace) for secret matches. TLS 1.2+ for transport. JWT verification with the Supabase JWKS for session tokens.
Network policy
All scan workers run with egress restricted to GitHub, Supabase, the configured AI provider, and approved Shannon target URLs. No customer code is ever shipped to a third party we don't list as a subprocessor.
Secure SDLC
All commits ship through a CI gate that runs LaunchGuard against itself: Semgrep, TruffleHog, OSV, npm audit, and the Supabase RLS scanner. Pre-merge security review for changes touching auth, RLS, integrations, or scanner adapters.
Responsible disclosure
If you believe you have discovered a security issue in LaunchGuard, email security@launchguard.dev. We commit to acknowledging within 48 hours and to publishing a remediation timeline for confirmed reports. We do not pursue legal action against good-faith research that respects user privacy and does not disrupt service.