Leaked credentials are one of the cheapest ways into a startup. GitGuardian counted 23.8 million secrets leaked on public GitHub in 2024, up 25% on the year before, and found that 70% of secrets leaked in 2022 were still valid. This guide explains where secrets leak, what the OWASP Secrets Management Cheat Sheet recommends, and how a small team can put a working system in place quickly.
What counts as a secret
A secret is any value that grants access: database passwords, cloud access keys, API tokens for payment or messaging providers, signing keys, webhook secrets and OAuth client secrets. GitGuardian's 2025 report found that generic secrets, such as hardcoded passwords and custom tokens without a known pattern, made up 58% of leaked credentials. That matters because pattern-based scanners catch those least well. Startups accumulate secrets fast. Every new integration, environment and contractor adds more, and few teams keep a list of what exists, who can read it and when it was last rotated.
Where startup secrets actually leak
Public repositories get the headlines, but GitGuardian's data shows private systems are often worse. The figures below come from its 2025 report, which analysed 1.4 billion commits. The pattern is clear: secrets spread wherever engineers work, including tickets, chat and container images, so scanning only new code misses much of the exposure.
| Location | Finding | What to do |
|---|---|---|
| Public GitHub | 4.6% of public repositories contain a secret | Push protection and pre-commit scanning |
| Private repositories | 35% contain secrets; AWS IAM keys appear in 8% | Scan full history, not just new commits |
| Commit authors | 15% of commit authors leaked a secret | Developer training and IDE checks |
| Slack | 2.4% of corporate channels contained secrets | Share access, never values, in chat |
| Jira | 6.1% of tickets exposed credentials | Scan and clean ticket systems |
| Docker Hub images | 98% of detected secrets were in image layers | Never bake secrets into images |
Centralise secrets in one managed store
The OWASP Secrets Management Cheat Sheet's first recommendation is to standardise on a central secrets manager, so secrets stop living in code, config files and chat. A cloud provider's managed secrets service is usually the easiest choice for a startup already on that cloud; a dedicated vault suits multi-cloud teams.
Separate production and development stores, scope access to individual secrets rather than whole folders, and document what each secret is for. OWASP also notes that engineers should not be able to read every secret: most should deploy code that reads secrets at runtime without ever seeing the values.
Prefer short-lived credentials over static keys
A key that expires in an hour is far less useful to an attacker than one that lasts for years, which is why the 70% still-valid figure is so worrying. OWASP recommends dynamic, short-lived credentials where possible, with expiry dates on everything else.
For CI/CD, both OWASP and GitHub recommend OpenID Connect federation instead of storing long-lived cloud keys as pipeline secrets. The pipeline proves its identity to the cloud provider and receives a temporary token scoped to that job. For services, have them fetch their own secrets at runtime rather than passing values through the pipeline.
Scan before and after commit
Detection works best at several points. OWASP recommends scanning in the IDE or with a pre-commit hook, so a secret never reaches the repository. GitHub push protection blocks pushes that contain recognised secrets; it is free for public repositories, and GitHub reported that developers blocked 17,000 potential leaks between the April 2022 beta and May 2023.
For private repositories, GitHub split Advanced Security in April 2025, making Secret Protection available on its own for USD 19 per active committer per month, including to Team plan customers. GitHub also offers a free secret risk assessment for Team and Enterprise organisations, a sensible first step before buying anything.
Containers, environment variables and logs
OWASP advises against putting secrets in Docker ENV or ARG instructions, because they persist in image definitions, and GitGuardian's Docker Hub finding shows how often that happens. Environment variables are common but visible to every process and can leak into crash dumps and logs. Mounted files from the orchestrator or a sidecar that fetches secrets into memory are safer. Never log secret values. GitHub's Actions guidance warns against storing JSON or YAML blobs as a single secret, because log redaction relies on exact matches, and recommends registering derived values such as encoded tokens as secrets too.
What to do when a secret leaks
Assume it will happen and write the steps down now. OWASP's incident guidance for leaked secrets is short and practical. Keep the runbook next to the code, name the person who can rotate each critical credential, and make sure at least two people know how to do it.
- Revoke the exposed secret immediately; deleting the commit is not enough
- Issue and deploy a replacement, ideally through automated rotation
- Check provider logs for any use of the old credential
- Remove the value from code history, tickets, chat and logs
- Record who had access, when it was used and when it was rotated
- Find the root cause and add a scanner or control that would catch it
A 30-day plan for a small team
Week one: list every secret and owner, and turn on push protection. Week two: run a full-history scan across repositories, tickets and chat, then rotate anything found. Week three: move production secrets into a managed store and switch CI to OIDC. Week four: add pre-commit hooks for every developer and write the leak runbook. XDQ Labs helps teams audit and fix secret handling on systems they own, as part of its authorised AI security engineering work.
Frequently asked questions
Is it safe to store secrets in environment variables?
It is better than hardcoding, but not ideal. OWASP notes environment variables are visible to all processes and can leak into logs or dumps. Prefer a secrets manager, with secrets mounted as files or fetched into memory at runtime, and never set them through Docker ENV or ARG.
What should I do if I pushed an API key to GitHub?
Revoke the key at the provider straight away, because removing the commit does not make it safe and copies may already exist. Issue a new key, check the provider's logs for misuse, then clean the history. GitGuardian found 70% of secrets leaked in 2022 were still valid years later.
Is GitHub push protection free?
Push protection is free for public repositories. For private repositories it is part of GitHub Secret Protection, sold since April 2025 at USD 19 per active committer per month and available to Team and Enterprise plans.
Do small startups really need a secrets manager?
Yes, once you have more than one environment or developer. Cloud providers offer managed secret stores that are quick to adopt. The bigger gains come from habits: no secrets in code, short-lived credentials, scoped access and a written plan for rotating a leaked key.
Sources
- The State of Secrets Sprawl 2025, GitGuardian, 2025
- Secrets Management Cheat Sheet, OWASP Cheat Sheet Series, 2025
- Secure use reference for GitHub Actions, GitHub Docs, 2026
- Push protection is generally available, and free for all public repositories, GitHub Blog, 2023
- Introducing GitHub Secret Protection and GitHub Code Security, GitHub Changelog, 2025
- Verizon 2025 Data Breach Investigations Report: news release, Verizon, 2025
- OWASP Top 10 CI/CD Security Risks, OWASP Foundation, 2022
