Secrets in Source Code

Secrets in source code , hardcoded credentials, API keys, database connection strings, private keys, and authentication tokens committed to version control repositories , represent one of the most prevalent and most consequential software supply chain vulnerabilities. They are prevalent because developer workflows under time pressure frequently take shortcuts that include credentials directly in code or configuration files. They are consequential because once committed to a repository, credentials become accessible to everyone with repository access , and in public or semi-public repositories, to anyone who can access or clone the repository, even after the credentials are removed from the current codebase.

The git history problem is the specific persistence mechanism that makes 'remove the credentials from the code' an insufficient response. Git version control systems maintain a complete history of every commit made to a repository. A credential committed and then removed in a subsequent commit is still present in the repository's git history , accessible by anyone who clones the repository and examines past commits. The credential may have been removed from the current branch tip, but it remains in the immutable commit history. Proper remediation requires not only removing the credential from the current code but also either rewriting the git history to expunge the commit (which is destructive and disruptive) or rotating the exposed credential immediately.

The public repository scan threat is the automated discovery mechanism. Automated tools continuously scan public GitHub, GitLab, and Bitbucket repositories for credential patterns , searching commit histories including historical commits for API key formats, private key headers, connection strings, and other credential patterns. A credential committed to a public repository in 2021 that was 'removed' by a subsequent commit in 2021 is still discoverable in 2024 by anyone running a repository scan. The time elapsed does not reduce the credential's validity unless it has been rotated.

Why this matters

Secrets in source code matter for TPRM because your vendors' development repositories may contain credentials that provide access to systems that process your data , production database credentials, cloud provider keys, API tokens for services that handle your data. A compromised vendor repository credential is a supply chain attack vector that does not require exploiting any vulnerability in the vendor's running software.

• Policy confirmation accepted without technical verification
• Git history not included in secrets scanning scope
• Public repository scan not conducted as part of vendor assessment
• Credential rotation not confirmed as response to past exposure
• Repository access control not assessed alongside secrets management

What good looks like

Mature secrets management programmes implement pre-commit secret detection hooks that prevent secrets from reaching version control, continuous scanning of repository histories for credential patterns, immediate rotation as the required response to any discovered credential exposure, and explicit git history review as part of vendor assessment.

• Pre-commit hooks preventing secrets from reaching version control
• Continuous repository scanning including git history
• Immediate credential rotation as required response to any exposure
• Git history review for exposed credentials , not just current code
• Public repository scan as part of vendor software supply chain assessment

Tooling

Secret Detection , GitLeaks, TruffleHog, GitHub Secret Scanning for repository and history scanning

Secret detection tools can scan entire repository histories , not just current code , for credential patterns. GitLeaks and TruffleHog both support historical commit scanning. GitHub's secret scanning alerts are available for public repositories. For TPRM practitioners, running GitLeaks or TruffleHog against a vendor's public repositories as part of software supply chain assessment provides a specific credential exposure check that questionnaire confirmation cannot replace.

Pre-commit Hooks , detect-secrets, git-secrets for pre-commit credential detection

Pre-commit hooks that scan staged changes for credential patterns before they are committed provide the prevention mechanism that prevents credentials from reaching version control in the first place. For TPRM practitioners, asking whether vendors use pre-commit secret detection hooks alongside post-commit scanning provides a specific prevention versus detection question.

Governance challenges

The governance challenge with secrets in source code is the git history remediation complexity. Once a credential has been committed to a repository with multiple contributors, rewriting the git history to remove it is disruptive , it requires all contributors to rebase or re-clone. The pragmatic resolution is immediate credential rotation, which renders the historically committed credential useless regardless of whether the git history has been scrubbed, combined with pre-commit hooks to prevent future commits.

• Implement pre-commit secret detection , prevention before version control
• Scan full repository history , not only current code
• Require immediate credential rotation for any discovered exposure
• Run public repository scans for critical software vendors
• Include git history scope in vendor secret management assessment**

If you are a small team

Run GitLeaks against the public GitHub repositories of your three most critical software vendors. The command takes minutes per repository and searches the complete git history for credential patterns. Review the findings , any credential pattern found in the history should be treated as a potential exposure and verified with the vendor whether the credential has been rotated. That scan will tell you more about the vendor's historical credential hygiene than any questionnaire confirmation.

• Run GitLeaks against critical vendor public repositories
• Review findings and verify credential rotation for any discovered exposures
• Ask vendor about pre-commit hook implementation for development repositories
• Require credential rotation disclosure as part of vendor assessment

What to require

Ask directly:

"Do you use pre-commit secret detection hooks across your development repositories , and have you scanned your repository histories, including historical commits, for exposed credentials? And can you confirm that any credentials discovered in repository history have been rotated?"

Expect as evidence

• Pre-commit secret detection hook implementation
• Repository history scanning coverage
• Credential rotation confirmation for any historical exposures
• Secret management policy and enforcement

A vendor who confirms no hardcoded credentials should be asked specifically about git history scope and pre-commit hook implementation. Policy prohibits. Pre-commit hooks prevent. History scanning detects. Rotation remediates. All four are required for complete secrets management coverage.

How to evidence it

• Public repository scan records for critical vendors
• Pre-commit hook implementation verification
• Credential rotation confirmation process
• Repository history scanning coverage

Key Takeaway

Policy: no hardcoded credentials. Code: credentials removed. Git history: AWS key, database connection string, private RSA key , 31 months, still accessible to anyone who clones the repository. The policy was real. The removal was incomplete. Removing credentials from the current code leaves them in git history. Git history scanning finds them. Pre-commit hooks prevent the next commit. Immediate rotation renders the historical credential useless regardless of scrubbing. Policy plus prevention plus detection plus rotation is complete secrets management coverage. Policy plus removal of the current code is incomplete.

More on Third-party oversight

• Build Pipeline Integrity
• Vendor Patch Cadence Reality
• Artifact Registry Security