Preview · SecretSweep is in private build · not accepting customers · launching Q2 2026

Security.

What SecretSweep does with your code, your credentials, and the connections between them.

Last updated: April 15, 2026

01Storage and data

  • No code stored. Repositories are cloned to an isolated temp directory, scanned, and immediately deleted. Your source code is never written to persistent storage.
  • Redacted secrets. Full secrets are never stored in plaintext. Only the first and last 4 characters are displayed (for example, AKIA************MPLE), with everything in between masked, along with a SHA-256 hash for deduplication. When a credential is verified as active, an encrypted copy (AES-256-GCM) is retained solely for automated re-verification and deleted when revoked.
  • AES-256-GCM at rest. Sensitive tokens are encrypted with AES-256-GCM before being stored. In production, encryption keys are injected from AWS Systems Manager Parameter Store at deploy time and are never committed to the repository.
  • Abuse-prevention carryover. Account data is deleted immediately upon account closure in a single database transaction. A minimal record is retained indefinitely to enforce free-tier lifetime limits on re-registered accounts: public GitHub user ID, irreversible hashed repository identifiers for distinct-repository counting, aggregate scan counters, and limited deletion metadata. No code, findings, email, or plaintext repository names are kept. See the Privacy Policy for details.

02Access and authentication

  • Read-only repository access. The GitHub App requests only read access to repository contents (Contents:Read). GitLab integrations use the api scope (required to register webhooks for auto-scan on push) and read_repository. Bitbucket connections use repository read plus webhook management. SecretSweep never writes to your source code.
  • Short-lived tokens. GitHub installation tokens expire after 1 hour and are generated on-demand. GitLab and Bitbucket OAuth tokens auto-refresh before expiry and are encrypted at rest.
  • Server-side sessions. Sessions are stored server-side in PostgreSQL with a random 64-character session ID. The browser cookie holds only an opaque identifier: HttpOnly, Secure, SameSite=Lax, 4-hour expiry. No session data is exposed to the client.

03Transport and validation

  • TLS everywhere. All connections use TLS. HSTS enforces HTTPS on the production domain. Internal services communicate over encrypted channels.
  • Verified webhooks. All incoming webhooks from GitHub, GitLab, Bitbucket, and Stripe are cryptographically verified before processing. GitHub, Bitbucket, and Stripe use HMAC-SHA256 signatures; GitLab uses constant-time token comparison. Unverified payloads are rejected.
  • Strict Content Security Policy. CSP includes object-src 'none', script-src 'self' (no inline scripts), and frame-ancestors 'none' to prevent embedding, plugin, and injection attacks.
  • CSRF protection. Double-submit cookie pattern on all state-changing endpoints. Webhook endpoints are exempt because they verify signatures independently.

04Hardening

  • Bounded external reads. All external HTTP response bodies are read through io.LimitReader to cap memory usage and prevent denial-of-service via oversized payloads. Webhook bodies are capped at 1 MB.
  • Rate limiting. Enforced on sensitive endpoints: authentication (10/min), webhooks (300/min), scan triggers (5/min), and data export.
  • Archive extraction safety. CI/CD log extraction includes zip-slip protection (path traversal prevention) and decompression-bomb limits to prevent resource exhaustion attacks.
  • Continuous scanning. SecretSweep runs govulncheck and Gitleaks against its own codebase in CI on every commit. The product is used on the product.
  • Parameterized queries and user scoping. All SQL uses pgx parameterized queries ($1, $2); write functions include user_id scoping as defense-in-depth against cross-tenant access.

Responsible disclosure

If you discover a security vulnerability in SecretSweep, please report it to security@secretsweep.com. We aim to acknowledge receipt within three business days and to triage and address issues as quickly as resources permit. Please do not test exploits against production data.