Secrets like API keys, passwords, and tokens committed to repositories can be exploited by unauthorized users, creating security, compliance, and financial risk to your organization.
Secrets are credentials that grant access to sensitive systems and data. Common examples include:
When secrets are committed to repositories, they become hardcoded credentials that are embedded directly in your source code or configuration files. These hardcoded secrets become part of your Git history and remain accessible even after being removed from the latest commit. This means that addressing a credential leak requires more than deleting the file; you must also revoke and replace the credential to prevent unauthorized access.
Secret sprawl occurs when credentials proliferate across repositories, teams, and systems without centralized management or visibility. This makes it difficult to track which secrets exist, where they're used, and whether they've been exposed. Secrets typically enter repositories through several common patterns.
.env files or infrastructure-as-code templatesExposed secrets can lead to several types of security incidents.
Credential leaks give unauthorized users direct access to your systems. Once exposed, hardcoded secrets can be exploited to:
Credential leaks give unauthorized users direct access to your systems, leading to data breaches. Once attackers gain access using exposed credentials, they can exfiltrate sensitive data, modify or delete critical information, and compromise customer trust. Data breaches require immediate incident response, including credential revocation, system remediation, and assessment of the breach's scope and impact.
Exposed package registry tokens can be used to publish malicious versions of your software, affecting downstream users and organizations that depend on your packages.
Exposed secrets can cost your organization money in several ways.
GitHub provides tools to help you prevent, detect, and remediate secret leakage:
Enable Push protection to scan code during git push operations and block commits containing detected secrets before they enter your repository. This prevents hardcoded credentials from being added to your codebase and provides real-time feedback to developers at the point of risk, covering both provider patterns for known services and generic patterns such as private keys and generic API keys. Please note, not all secret types are push protected by default and must be configured by your organization, based on your tolerance for risk vs. noise.
Encourage individual developers to enable push protection for their personal accounts to protect all their pushes across GitHub, regardless of organization policies. This helps prevent secret sprawl by catching leaked credentials before they reach your repositories.
Use secret scanning to continuously monitor your repositories for hardcoded secrets and generate alerts when credentials are detected, enabling you to revoke and rotate compromised credentials quickly. Beyond default detection of provider patterns, you can expand scanning to generic patterns and define custom patterns for organization-specific secrets. This helps you gain visibility into secret sprawl across your organization.