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 25, 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 Metadata: Read, Contents: Read, and Actions: Read. Actions: Read is used only for Power CI/CD log scanning. GitLab integrations use the api scope (required to register webhooks for auto-scan on push and read pipeline logs) and read_repository. Bitbucket connections use repository read, webhook management, and pipeline read access for Power CI/CD log scanning. SecretSweep never writes to your source code and scans only repositories you explicitly enable in the app.
  • 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

  • Production TLS. Production traffic is served over HTTPS with HSTS on the public domain. The production database connection is required to use PostgreSQL SSL (sslmode=require, verify-ca, or verify-full), and the RDS launch checklist requires rds.force_ssl=1.
  • 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.
  • Production access path. Production infrastructure is launched from AWS SSM Parameter Store secrets. The launch checklist requires no public SSH port for the application host and administrative access through AWS Systems Manager Session Manager.
  • Pre-launch retest gate. SecretSweep is pre-launch. The launch checklist requires production security re-testing, including HTTPS/HSTS, cookie flags, webhook signature checks, RDS SSL refusal for non-SSL connections, CSP validation, rate limits, and external OWASP testing before public launch.

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.