Secrets Management Vibe Code Cleanup

What AI Gets Wrong in Secrets

AI generates code with secrets inline. const API_KEY = "sk-live-abc123" directly in the source file. DATABASE_URL=postgres://admin:password@... in a .env file that gets committed because AI didn’t add .env to .gitignore. Every prompt that includes “connect to the database” or “call the API” produces code with credentials embedded in it.

The duplication is worse. AI generates the same API key in three different files. The database connection string appears in the application config, the migration script, and the seed file. When a secret needs to rotate, nobody knows every location that needs updating. Some locations get updated, others don’t, and parts of the application break silently.

Environment separation doesn’t exist. Development and production use the same database credentials. The test suite runs against production data. A DROP TABLE in a test file runs against the production database because the connection string is the same everywhere.

Our Secrets Cleanup Process

We scan the entire git history for exposed secrets. Every credential found is inventoried: what it accesses, whether it’s still active, and where it appears. Active exposed secrets are rotated immediately - new values generated, old values invalidated. The git history can’t be cleaned, so rotation is the only remedy.

A secret store replaces scattered credentials. Doppler for most startups - it provides excellent developer experience with pull-based secret injection. AWS Secrets Manager for teams already in the AWS ecosystem. The application reads secrets from the store at runtime. No more .env files, no more credentials in code.

Environment separation ensures development can’t touch production. Separate credentials per environment. Development uses a local database. Staging uses a staging database. Production credentials are accessible only to the production deployment pipeline. A mistake in development is embarrassing, not catastrophic.

Before and After

Before: API keys in source code. Database passwords in git history. The same credentials everywhere. No rotation procedures. One repository clone away from a security incident.

After: All secrets in a centralized store with access controls. Environment-specific credentials. Pre-commit hooks preventing future exposure. Rotation procedures documented and scheduled. The application is one security audit away from passing instead of one breach away from failing.

Automated Rotation and Least-Privilege Access

Secrets that never rotate are ticking time bombs. A leaked credential with no expiration gives an attacker permanent access. We set up automated rotation schedules for database passwords, API keys, and service account tokens. For AWS workloads, IAM roles replace long-lived access keys entirely, so there is no static credential to steal. For third-party APIs that support it, we configure OAuth2 client credentials flows with short-lived tokens instead of permanent API keys. Access to the secret store itself follows the principle of least privilege: developers can read development secrets, the CI pipeline can read staging secrets, and only the production deployment system can access production credentials. Every secret access is logged and auditable. When an employee leaves or a service is decommissioned, their access is revoked in one place, not scattered across dozens of configuration files.