The Dangers of Exposed Secrets in Enterprise Source Code
Modern enterprise software relies on authentication tokens, API keys, encryption keys, certificates, and other sensitive credentials to enable secure communication between applications, microservices, APIs, and DevOps pipelines. However, these secrets often end up hardcoded in source code during the development process, whether unintentionally or as a shortcut for quick development (because hardcoding access credentials is simply the fastest and easiest way to write and test code).
When exposed in public or internal repositories, these credentials become prime targets for attackers, who can exploit them to gain unauthorized access to critical systems, sensitive data, or cloud infrastructure. Even private repositories aren’t immune – compromised developer accounts, insider threats, or misconfigured access controls can all lead to unintended exposure.
This fascinating Wired article describes the staggering number of credentials leaked daily in GitHub and other accessible locations: A single security researcher uncovered 15,000 publicly exposed secrets and confirmed they were exploitable. These credentials granted access to, among others, the private assets of a state supreme court, a major university’s Slack channels, and thousands of OpenAI customer accounts.
The consequences of exposed secrets can be severe: data breaches, service outages, financial loss, regulatory fines, and reputational damage. Once attackers gain access, they can move laterally within systems to exfiltrate data, deploy malware, or launch further attacks.
83% of organizations report at least one security incident caused by hardcoded secrets in the past year (source: Thales Group), and breaches involving exposed secrets cost an average of $4.5 million per incident, factoring in downtime, fines, and remediation costs (source: IBM).
Examples of Known Cyberattacks Enabled by Exposed Secrets
Exposed secrets have been at the center of numerous high-profile cyberattacks, underscoring the critical need to secure the software supply chain against this threat. Here are some notable examples:
- Uber (2016) – Hackers exploited leaked AWS credentials to steal the personal data of 57 million users.
- Slack (2017) – Tokens exposed on GitHub exposed the sensitive private messages of hundreds of companies.
- Capital One (2019) – A hacker used a leaked access token to extract the personal data of over 100 million customers.
- Microsoft (2020) – Attackers used exposed account credentials to access private Microsoft repositories.
- GitHub (2022) – Stolen OAuth tokens allowed attackers to access private source code and exfiltrate data.
- Mercedes-Benz (2023) – An employee inadvertently uploaded a GitHub access token to a public repository, exposing source code, API keys, cloud access credentials, and design documents.
- Football Australia (2024) – Leaked credentials enabled unauthorized access to 127 storage repositories holding customer purchase details, player contracts, and passport data.
- Schneider Electric (2024) – Hackers used exposed credentials to steal 40GB of sensitive data, including the names and email addresses of 75,000 employees and customers.
How to Prevent the Leakage of Exposed Secrets
Traditional security tools aren’t designed to detect or prevent leaks of secret credentials. To mitigate this risk, enterprises must enforce secure coding practices, adopt automated secrets detection, and integrate preventive controls into their software development lifecycle. Without these measures, a single leaked credential could lead to a catastrophic security incident.
To minimize the risks of exposed secrets, enterprises should implement a four-pronged approach:
1. Developer Training
The first line of defense is developer awareness. Companies should invest in security training that educates developers about how dangerous hardcoded secrets are—even within internal repositories—emphasizing that sensitive credentials should never appear in source code, configuration files, or documentation. The training should convey clear guidance regarding company policies and best practices.
However, time pressure and development shortcuts often lead to mistakes. Even with first-rate training, secrets will occasionally end up in code. That’s why additional safeguards are essential.
2. Secrets Management Tools
Organizations should adopt secrets management solutions to securely store and handle credentials. Each enterprise needs to evaluate the various types of solutions available and adopt the most relevant ones for their environment. Common examples include:
- Cloud-based secrets management services integrate seamlessly with development environments and offer automated secrets rotation. Examples: AWS Secrets Manager, Azure Key Vault, Google Secret Manager.
- Self-hosted secrets vaults are on-premises or private cloud deployments that provide enterprises with advanced access controls and audit logging. Examples: HashiCorp Vault, CyberArk Conjur, Doppler.
- CI/CD and DevOps-integrated secrets managers integrate with CI/CD pipelines to securely inject secrets into applications, keeping them out of repositories. Examples: GitHub Actions Secrets, GitLab CI/CD Secrets, Kubernetes Secrets.
- API gateway & identity-based secrets management solutions secure authentication credentials at the network layer instead of within applications. Examples: AWS IAM Roles, Google Workload Identity, HashiCorp Boundary.
3. Continuous Secrets Scanning
Even with secrets management tools, enterprises must continuously scan their repositories to detect and remediate exposed secrets. An effective scanning tool should:
- Accurately identify hundreds of different types of secrets (e.g., authentication tokens, certificates, encryption keys, API keys), while minimizing false positives (to reduce noise and prevent alert fatigue).
- Automatically verify whether discovered secrets are still valid (and thus potentially exploitable) to help prioritize remediation efforts.
- Allow developers to initiate their own scans from within the IDE before pushing code, to ensure that hardcoded secrets don’t reach the repository.
- Provide developers with remediation guidance within the IDE, pinpointing exactly where secrets were found.
- Enable managers to trigger automatic scans at critical stages in the development, build, and deploy lifecycle.
4. Preventing Secrets from Reaching Repositories
Once secrets are pushed to a shared repository, the risk skyrockets. Enterprises must prevent exposure by implementing pre-commit and pre-push hooks that:
- Scan for secrets before commits are made.
- Block repository pushes if secrets are detected.
- Integrate with CI/CD pipeline security checks to enforce policies automatically.
By combining developer training, robust secrets management, continuous scanning, and proactive blocking, enterprises can dramatically reduce the risk of exposed secrets and protect their software supply chain.
Keep Your Secrets Secret with Checkmarx Secrets Detection
Checkmarx Secrets Detection proactively prevents the exposure of sensitive credentials by blocking any Git commit containing hardcoded secrets, ensuring that they never reach shared repositories. Automatic secrets identification and validation help developers quickly locate and remove exploitable secrets from their code, preventing leakage.
A part of the Checkmarx One enterprise application security platform, Secrets Detection accurately identifies 170+ types of secrets. Scans can be initiated on demand or triggered via source control integrations (e.g., upon pull requests or builds), ensuring continuous protection throughout the development lifecycle, helping you:
- Keep your secrets secret – Prevent the unintended exposure of sensitive credentials, tokens, keys, certificates, or URLs that can endanger your organization.
- Secure your software supply chain – Make secrets leakage prevention a core component of your comprehensive software supply chain security (SSCS) strategy.
- Improve regulatory compliance – Avoid fines and reputational damage by fully meeting regulations that require organizations to safeguard sensitive data (e.g., GDPR, HIPAA, PCI DSS, SOX, FISMA, CCPA).
To learn more about Checkmarx Secrets Detection, read the solution brief.