Somewhere in your organization, right now, there is an API key in a place it should not be. A config file committed in a hurry, a token pasted into a chat to help a colleague, a database password in a CI log.
Secrets management for developers is the discipline of making those slips rare, catching them fast, and making sure that when one does happen, it cannot do much damage. Start with where secrets leak from, then how to keep them out of code, and finally what to do on the day one escapes.
How often this happens
GitGuardian, which scans public code for credentials, reported finding 28.6 million new secrets in public GitHub commits during 2025, up 34% on the year before. These are not test keys in tutorials; they include cloud credentials, database passwords and keys for AI services, which alone accounted for 1.3 million of the leaks, up 81% in a year. Most are still valid long after they are pushed: 64% of the secrets GitGuardian confirmed valid in 2022 still worked in January 2026.
The consequences are not abstract either. In 2016, attackers found credentials for Uber's cloud storage in a GitHub repository used by Uber engineers and downloaded personal data on about 57 million riders and drivers, according to the US Federal Trade Commission. One key in one repository.
Where secrets leak from
Developers tend to picture the leak as a key in a source file. That is the most common route, but it is one of many.
Source code and config files. A key hard-coded for a quick test, a
.envfile committed because it was not in.gitignore, a settings file with production values.Git history. Removing a secret in a later commit does nothing. It is still in the history, and in every clone and fork made since.
Client-side bundles. Anything in a frontend build is public, including the "private" key in an environment variable prefixed for the browser.
Logs. A request logger that prints headers prints the authorization header. A debug line that dumps the config dumps the password.
CI output. Build logs are visible to everyone with repository access, and sometimes to the public. A command that echoes its environment is a leak.
Container images. A secret copied in during a build stays in a layer even if a later step deletes the file.
Chat and tickets. "Here's the key, don't share it" in a channel with 40 members and a searchable history.
Laptops. Long-lived cloud credentials in a home directory, on a machine that gets stolen or sold.
Keeping secrets out of code
Load them from the environment or a secrets manager
The application reads secrets at runtime from environment variables or a secrets manager such as AWS Secrets Manager, Google Secret Manager, HashiCorp Vault, Doppler or 1Password's developer tools. The code contains only the name of the secret, never its value. Local development uses a .env file that is listed in .gitignore from the first commit, with a committed .env.example that holds the names and nothing else.
Scan before the push, not after
Pre-commit hooks with a tool like gitleaks catch a key before it enters history. GitHub's push protection blocks a push that contains a recognizable credential, and GitLab has an equivalent. Turn both on. A scan that runs after the fact tells you about a leak that has already happened; a scan at push time prevents it.
Prefer short-lived credentials to stored ones
The best secret is one that expires in an hour. Cloud providers let a CI workflow or a running service prove its identity and receive temporary credentials, so there is no long-lived key to store or leak. GitHub Actions can do this with OpenID Connect to AWS, Google Cloud and Azure. Where a long-lived key is unavoidable, give it the narrowest permissions the job needs and nothing more.
Separate environments
Development, staging and production each get their own secrets. A key that leaks from a developer's laptop should open the development database and nothing else.
Rotate on a schedule, and prove you can
Rotation is the control that limits how long a leak matters. It is also the one most teams discover they cannot do under pressure, because nobody knows every place a key is used. Rotate each secret at least once in calm conditions so the procedure exists before the emergency.
Keep secrets out of logs by design
Redact known secret fields in the logging layer rather than trusting every developer to remember. Mask values in CI so they appear as asterisks in output. Never log request headers or full configuration objects.
The day a secret leaks
It will happen. What matters is the order of operations.
Revoke first. Before anything else, invalidate the key at the provider. Do not start by deleting the commit; attackers scan public repositories within minutes, and the key is already copied.
Issue a replacement and deploy it, which is where the rotation practice pays off.
Check what the key could reach and what it was used for during the exposure window. Cloud audit logs will show unfamiliar calls.
Then clean the history if it is a public repository, knowing this is hygiene rather than containment.
Write down how it happened and add the control that would have stopped it. Usually that is push protection or a redaction rule.
Treat a leak that reached a public repository as compromised regardless of how quickly it was removed. The scanners are faster than you are.
What good looks like
A team with secrets under control can answer four questions without looking anything up: where does each secret live, who and what can read it, when was it last rotated, and what would we do if it leaked tonight. None of those answers requires expensive tooling. They require a decision to treat credentials as infrastructure instead of as something that lives in whoever set up the project last.
That is the standard we apply when we build a SaaS product for a client, because their enterprise buyers ask exactly these questions in a security review. Our process starts every project with a secrets manager, separate environments and scanning on every push, so the answers exist before anyone asks.
Where to start with secrets management
Run a secret scanner across your repositories, including history, and turn on push protection today. If the scan turns up more than you expected, or you want help moving to a secrets manager and short-lived credentials, book a 30-minute call. We can also provide developers who work this way by default.
