Enable secret scanning and push protection
Implementation Effort: Low – Turning on secret scanning and push protection is mostly an administrator toggle at the organization or repository level. User Impact: Medium – A developer who pushes a detected secret is prompted to remove it or justify a bypass, so committers are directly affected. Lifecycle Stage: Code
Overview
Enable secret scanning and push protection so credentials are detected before they can spread through repository history and downstream systems. This task directly mitigates OWASP CI/CD-SEC-6 (Insufficient Credential Hygiene) by reducing the chance that API keys, connection strings, tokens, certificates, and passwords enter a repository in the first place.
Once a secret is pushed to a repository, it is preserved in the Git history even if the file is subsequently deleted or overwritten. Threat actors routinely scan public and compromised private repositories for credential patterns, and a single leaked secret can grant immediate access to cloud subscriptions, databases, third-party services, or production infrastructure. The window between a credential being committed and a threat actor using it can be measured in minutes.
On GitHub, secret scanning for supported patterns is available across all plans for public repositories. For private repositories, secret scanning requires GitHub Advanced Security, and push protection for private repositories requires GitHub Advanced Security with the push protection feature enabled. For public repositories, secret scanning is available on all plans, and push protection for users is enabled by default for supported secrets.
Secret scanning continuously monitors repository content and commit history for patterns that match credentials from hundreds of service providers. When a match is detected, an alert is generated for repository or organization administrators when secret scanning alerts are enabled. For supported partner patterns, GitHub may also notify the service provider so the secret can be revoked and rotated.
Push protection evaluates commits before they are accepted by the repository. On GitHub, push protection prompts the developer when a secret is detected and requires them to either remove the secret or explicitly bypass the protection with a documented justification. Organization administrators can review bypass requests and revoke bypassed secrets. Configure organization settings to prevent developers from disabling push protection at the repository level. In GitHub organizations, push protection can also use custom patterns to detect proprietary credential formats.
In Azure Repos, these controls are provided through GitHub Advanced Security for Azure DevOps. When enabled, repository scanning runs in the background to detect existing exposures, and push protection can block pushes that contain supported secrets before they are accepted by the repository. Pair the feature with branch policies, alert response SLAs, and rapid secret rotation so any exposed credential is remediated quickly.
Secret exposure also occurs through pipeline logs and build output. Configure CI/CD systems to mask secrets in log output and scan build artifacts for accidentally embedded credentials.
Organizations that rely solely on post-commit scanning accept a window of exposure during which leaked credentials are exploitable. Push protection reduces exposure for supported secret patterns by catching credentials before they enter repositories, but it does not eliminate every leakage path or remove the need to rotate exposed credentials. Local clones, logs, screenshots, unsupported patterns, and earlier copies of the secret can still preserve exposure.
Combined with continuous scanning, push protection addresses a primary credential-exposure path in supply chain attacks and gives teams a faster remediation loop. By treating any committed credential as already exposed and requiring rotation, this control reflects Assume breach and shrinks the window a threat actor has to exploit a leaked secret.