Secrets Management for SaaS Teams FAQ

Secrets management is the security topic most teams know they should handle better but defer until it becomes urgent. These are the questions that come up when teams start taking secrets management seriously — answered directly.

❓ Frequently Asked Questions

What counts as a secret?

A secret is any value that grants access to a system or resource and must be kept confidential: API keys, database connection strings, OAuth client secrets, JWT signing keys, encryption keys, webhook signing secrets, service account credentials, and TLS private keys. Not a secret: database hostnames, public API endpoints, feature flags, non-sensitive configuration values. The distinction matters because over-classifying values as secrets creates unnecessary operational burden, while under-classifying creates security gaps.

Can I use .env files in production?

No. Environment files checked into version control is a security incident waiting to happen — a public repository exposure or a compromised developer machine exposes every secret in the file. Even .env files excluded from git via .gitignore are insecure in production: they persist on disk, are not auditable, and cannot be rotated without SSH access to each server. Use a secrets manager (AWS Secrets Manager, Doppler, Vault, Infisical) in production and load secrets at runtime, not from disk.

Which secrets management tool should I use?

For pre-seed and seed teams: Doppler is the fastest to adopt — 15-minute setup, works with every cloud provider, syncs secrets to environment variables without code changes. Infisical is the open-source alternative with self-hosting option if data residency is required. For teams already on AWS: AWS Secrets Manager integrates natively with ECS, Lambda, and RDS. For enterprise-grade requirements (audit logs, secret leasing, dynamic secrets): HashiCorp Vault — significantly more complex to operate but the most capable option.

How often should I rotate secrets?

Rotate immediately when: a team member with secret access leaves the company, a secret may have been exposed (leaked in logs, committed to git, visible in error messages), or a vendor notifies you of a breach. Rotate on a schedule for: database passwords (90-day rotation is the SOC 2 standard), JWT signing keys (annually or when you suspect key compromise), and API keys for critical integrations. Do not rotate on a fixed schedule just for rotation's sake if your secrets manager provides access logging — instead, monitor for unexpected access patterns as the signal for rotation.

How do I handle secrets in CI/CD pipelines?

Use your CI/CD platform's built-in secrets storage (GitHub Actions Secrets, GitLab CI Variables, CircleCI Contexts) for pipeline secrets. Never hard-code secrets in workflow files or pass them as plain-text environment variables in pipeline configuration. Scope secrets to the minimum required environment — production deployment secrets should not be available in the pull request pipeline where contributors without production access might see log output. Audit which secrets each pipeline job has access to quarterly.

What do I do if a secret is leaked?

Treat every potential secret leak as a confirmed incident until proven otherwise. The response sequence: (1) revoke the exposed secret immediately — do not wait to investigate whether it was actually accessed; (2) generate a new secret and deploy it to all systems that use it; (3) audit access logs for the exposed secret for the period between exposure and revocation; (4) document the incident: what was exposed, when, for how long, and what systems had access; (5) if customer data was potentially accessed, initiate your breach notification process. Speed of revocation is the most important factor — a secret revoked within minutes has a dramatically lower impact than one revoked after days.

How do I control which team members have access to production secrets?

Implement least-privilege access: each developer should have access only to the secrets their role requires. A frontend engineer does not need database credentials. A QA engineer does not need production payment processor keys. Use your secrets manager's access control to scope access by role or environment. Log all secret access — audit logs of who accessed which secret and when are required for SOC 2 and are invaluable during incident investigation.

What to Do Next

If you are still using .env files in production: migrate to Doppler or Infisical this week — the migration is a half-day task and eliminates your most common secret exposure vector. If you do not have a secret rotation process: define the two scenarios that trigger immediate rotation (team member departure, suspected exposure) and document the rotation runbook for each critical secret before you need it. If you do not have access logging for production secrets: add it before your first SOC 2 audit — auditors will ask, and "we do not have logs" is a finding that delays certification.