PR scanning misses pre-merge secret exposure across Git lifecycle

At a glance

What this is: This analysis argues that pull request scanning only covers one point in the Git lifecycle, leaving pre-merge exposure, abandoned branches, and unrevoked credentials outside the control plane.

Why it matters: IAM, PAM, and NHI teams need full lifecycle coverage because a secret that is detected but not revoked still functions as active access, regardless of where it leaked.

👉 Read TruffleHog's analysis of why PR scanning misses pre-merge secret exposure

Context

Secrets management fails when organisations treat pull request scanning as equivalent to secret governance. The control may detect some leaked credentials, but it does not see push-time exposure, abandoned branches, or secrets that remain valid after a ticket is closed.

For NHI programmes, the problem is lifecycle coverage rather than detection alone. API keys, bearer tokens, and service account credentials can exist across code, CI/CD, collaboration tools, and repository history, which means the identity boundary is much wider than the PR gate.

Key questions

Q: How should security teams handle leaked secrets that are found before a pull request opens?

A: They should treat pre-PR leakage as live exposure, not a lower-priority finding. Once a secret is pushed to a remote branch, automated scrapers may discover it before any review occurs. The right response is push-time detection, immediate revocation, and historical scanning so the credential cannot survive in branch history or downstream systems.

Q: Why do service account and API key leaks create more risk than a simple code review failure?

A: Because the leak is about active machine access, not just bad code. Service accounts, API keys, and bearer tokens can authenticate directly into SaaS or cloud services, so a missed secret can become operational access within seconds. The risk persists until the credential is revoked, even if the code is deleted.

Q: What do security teams get wrong about fixing leaked credentials?

A: They often equate deleting the exposed secret from code with eliminating the risk. That is incomplete because the original credential may still work, and the same value may remain in repository history or other copies. A real fix requires confirmed invalidation at the source and evidence that the secret no longer authenticates anywhere.

Q: Who is accountable when a leaked secret stays active after the ticket is closed?

A: The owning team remains accountable for proving revocation, not just marking the finding resolved. Governance frameworks expect a control outcome, which in this case is that the leaked credential can no longer be used. If the secret still authenticates, the incident is not actually closed.

Technical breakdown

Why pull request scanning misses secret exposure

Pull request scanning is a point-in-time control that examines code at review, not at the moment a credential first becomes reachable. Once a developer pushes a commit, the secret is already present on the remote repository and may be scraped by automated tools before a PR is even opened. That means exposure begins at push time, while many programs only inspect merge time. The failure is architectural: the detection window is narrower than the exposure window. Historical scanning and push-time scanning address different parts of the same lifecycle, but PR-only coverage leaves a blind spot that attackers and scrapers can exploit immediately.

Practical implication: extend detection to push-time and historical repository coverage, not just merge gates.

Why abandoned branches create hidden NHI risk

Abandoned branches are a governance problem because they can store valid credentials outside the normal review path indefinitely. If a branch is pushed and never opened as a PR, CI/CD scanning never sees it, yet the secret still exists in a reachable repository state. This is especially dangerous for NHI credentials because the identity is often machine-consumed and not tied to a human login event that would draw attention. The issue is not only that secrets leak, but that secret lifecycle and code lifecycle are misaligned. What looks like dead work in development can still be live access in production systems.

Practical implication: scan branch creation, branch history, and repository state, then tie cleanup to credential revocation.

Why detection without verified revocation is not remediation

A blocked merge is not the same thing as a dead credential. If a secret is found, the branch is deleted, and the ticket is marked fixed while the token remains active, the exposure persists in provider systems and often in commit history. Real remediation requires confirmed revocation at the source, not just removal from code. This distinction matters because many secrets are valid for long enough to be exploited even after a finding has been closed. For NHI governance, the control objective is not finding evidence of leakage. It is proving the leaked identity can no longer authenticate or authorise anything.

Practical implication: require verified revocation as the closure condition for every secret incident.

Threat narrative

Attacker objective: The attacker wants valid machine access that can be reused across the SaaS stack before defenders notice the leak.

1. Entry occurs when a credential is exposed in code, logs, tickets, or collaboration tools before merge, which makes it reachable to automated scrapers immediately.
2. Escalation occurs when the leaked key, token, or service account credential is still valid and can be used to authenticate into SaaS, cloud, or source control systems.
3. Impact occurs when that standing access is used to pivot across the SaaS stack, read data, or trigger further compromise before the secret is revoked.

Breaches seen in the wild

• Emerald Whale breach — exposed Git config files led to 15K secrets stolen and 10K repo compromises.
• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

PR-only scanning is a coverage illusion, not a secrets strategy. The control checks one lifecycle gate, but secret exposure starts earlier and often persists later in history, branches, and SaaS collaboration systems. That makes the programme appear operational while leaving active credentials outside the inspection window. The implication is that governance must be measured by lifecycle coverage, not by merge-stage detection counts.

Secret remediation is a revocation problem before it is a detection problem. A found secret that is still valid is still an identity. The article's core lesson is that many teams confuse removal from code with removal of access, which leaves a standing credential window open after the ticket closes. The implication is that NHI governance must treat revocation as the real closure criterion.

Credential leakage now spans the software delivery surface, not just source code. CI/CD logs, Jira, Slack, Confluence, and S3 are part of the identity attack surface because they can carry usable credentials. That widens the scope of OWASP-NHI concerns beyond repository hygiene into collaboration and pipeline governance. The implication is that secrets programmes must be designed around where developers actually work, not where policies assume they work.

Closed-loop secret governance is the new baseline for NHI control. Detection, validation, and verified revocation need to operate as one system if organisations want to reduce exploitability rather than simply increase alert volume. This aligns with NIST CSF expectations for protective and responsive control coordination, and it exposes why isolated scanners do not change the underlying risk. The implication is that practitioners should judge programmes by mean time to verified revocation, not by number of secrets found.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• The 52 NHI Breaches Analysis shows how leaked machine credentials repeatedly become live access when lifecycle controls fail.

What this signals

Secret governance is moving from point detection to lifecycle assurance. When developers leak credentials across code, logs, and collaboration tools, the programme needs a control model that proves revocation as well as discovery. That shift aligns naturally with the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0, because the issue is no longer whether a secret was seen but whether it was neutralised.

Mean time to verified revocation will become a more useful board-level metric than alert volume. If the organisation cannot prove that a leaked credential is dead, the exposure remains active regardless of how quickly the scanner fired. For practitioners, the next maturity step is to tie secrets telemetry to identity lifecycle workflows and to use the Guide to the Secret Sprawl Challenge as the operational baseline for that transition.

For practitioners

• Add push-time and historical repository scanning Scan commits the moment they land on a remote branch, then sweep abandoned branches and commit history so exposure is not limited to the PR gate. This closes the timing gap the article describes.
• Treat verified revocation as the only closure state Do not close a secret incident until the credential is confirmed dead at the provider and retested after remediation. A deleted branch is not proof that the key no longer works.
• Expand secret coverage beyond source control Include CI/CD logs, Slack, Jira, Confluence, and object storage in your discovery scope because those systems can contain live API keys and bearer tokens. Use the same response workflow across all of them.
• Measure mean time to verified revocation Track how long it takes from first detection to confirmed invalidation, then separate that metric from alert volume or merge-block rates. If the credential still works, the incident is not closed.

Key takeaways

• PR scanning alone leaves a large part of the secrets lifecycle uncovered, especially before merge and after branch creation.
• A secret is not remediated until it is verified dead at the provider, because deletion from code does not equal loss of access.
• Teams should measure success by lifecycle coverage and verified revocation, not by how many secrets the scanner caught.

Key terms

• Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials across code, logs, collaboration tools, storage, and pipeline outputs. In practice, it means the organisation no longer knows where valid secrets exist, so detection and revocation become fragmented instead of governed as one lifecycle.
• Verified Revocation: Verified revocation means proving that a leaked credential no longer authenticates anywhere, not merely removing it from code or marking a ticket complete. For NHI governance, this is the real closure condition because exposure remains live until the identity is invalidated at the source.
• Push-Time Exposure: Push-time exposure is the period beginning when a commit reaches a remote repository and ending when a later control inspects it. That window matters because automated scrapers can find and exploit secrets before pull request scanning or manual review ever happens.
• Closed-Loop Secrets Management: Closed-loop secrets management connects discovery, triage, rotation, and revocation so that findings are not just logged but neutralised. It is the difference between observing leakage and actually reducing the chance that leaked credentials can be used.

What's in the full article

TruffleHog's full article covers the operational detail this post intentionally leaves for the source:

• A four-layer coverage model showing where PR scanning, push scanning, historical scanning, and pre-commit hooks each fit in the Git lifecycle.
• Concrete examples of how a secret can remain valid after the branch is deleted, including the difference between detection and verified revocation.
• Practical guidance on defining remediation so that a closed ticket actually means the credential is invalid at the provider.
• A discussion of what mature programs measure instead of alert counts, including mean time to remediation and confirmed revocation rate.

👉 TruffleHog's full post covers the lifecycle gaps, remediation mismatch, and coverage model in detail

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.