Secret scanning pre-commit + push
Demonstrate that automated secret scanning mechanisms are enforced at both pre-commit and pre-push stages to prevent hardcoded credentials and sensitive data from entering version control systems.
Description
What this control does
Secret scanning pre-commit and push controls integrate automated tooling into developer workflows to detect and prevent hardcoded credentials, API keys, tokens, certificates, and other sensitive data from being committed to version control repositories. These tools scan code changes locally before commit and on the server side before push completion, blocking commits or pushes that contain pattern-matched secrets. This control reduces the attack surface by preventing credential exposure in repository history, which is difficult to remediate after the fact and frequently exploited by adversaries scanning public and private repositories.
Control objective
What auditing this proves
Demonstrate that automated secret scanning mechanisms are enforced at both pre-commit and pre-push stages to prevent hardcoded credentials and sensitive data from entering version control systems.
Associated risks
Risks this control addresses
- Developers inadvertently commit plaintext credentials, API keys, or tokens to repositories where they persist in version history and become accessible to unauthorized parties
- Attackers systematically scan public and private repositories for exposed secrets to gain unauthorized access to production systems, cloud accounts, or third-party services
- Secrets committed to feature branches remain discoverable even after branch deletion due to Git's immutable history model
- Contractors or temporary personnel with repository access extract credentials from commit history after their access period ends
- Automated bots harvest newly-pushed credentials within minutes of exposure, leading to immediate exploitation before detection or rotation
- Leaked database connection strings or encryption keys enable data exfiltration or ransomware attacks against backend systems
- Revoked or rotated credentials remain in historical commits, creating shadow credentials that bypass rotation procedures
Testing procedure
How an auditor verifies this control
- Obtain and review the organization's secret scanning policy document identifying approved tools, enforcement scope, and remediation procedures.
- Interview development team leads to identify all active version control repositories and the secret scanning tools deployed for pre-commit and pre-push protection.
- Select a representative sample of repositories across business units and verify that pre-commit hooks or IDE integrations for secret scanning are configured and active.
- Review configuration files for pre-commit scanning tools (e.g., .pre-commit-config.yaml, .git/hooks/pre-commit scripts) to verify pattern libraries, rule sets, and blocking behavior.
- Examine server-side repository settings or CI/CD pipeline configurations to confirm pre-push or pre-receive secret scanning enforcement at the centralized repository level.
- Perform a test commit containing a synthetic secret (e.g., dummy AWS access key) to a non-production repository to validate that the pre-commit scanner detects and blocks the attempt.
- Execute a test push containing a pattern-matched secret to verify server-side scanning intercepts and prevents the push from completing.
- Review audit logs or scanning tool dashboards for the past 90 days to identify detected secret attempts, remediation actions taken, and any bypass incidents or exceptions granted.
Where this control is tested