TL;DR: Truffle Security says secrets are leaking before pull requests open and across CI/CD logs, Slack, Jira, S3, Confluence, and Git history, which leaves PR-only scanning blind to exposure windows and makes verified revocation the real remediation test. The control problem is lifecycle coverage, not detection at a single gate.
At a glance
What this is: This article argues that PR-based secret scanning misses a large share of exposure because credentials can leak before review, outside code, and remain active after a scan flags them.
Why it matters: IAM, PAM, and NHI teams need coverage that follows the full Git lifecycle because a secret that is found is not a secret that is neutralised.
👉 Read Truffle Security's analysis of secret scanning gaps across the Git lifecycle
Context
Secret scanning is often treated as a pull-request control, but that model only covers one moment in a much longer Git lifecycle. The governance gap is that API keys, bearer tokens, and service account credentials can become exposed before review starts and can remain valid after a ticket is closed.
For identity teams, the question is not whether scanners exist. It is whether the programme can detect secrets in code, CI/CD logs, SaaS collaboration tools, and repository history, then prove that the underlying credential was actually revoked.
Key questions
Q: What breaks when secret scanning only covers public repositories?
A: Repository-scoped scanning misses secrets that leak through forks, issues, comments, build logs, open source contributions, and attacker-controlled exfiltration paths. That creates a false sense of coverage because the credential may already be validated and abused before the platform ever sees public exposure. Effective governance needs scanning plus containment, rotation, and revocation.
Q: Why does a blocked merge not prove a secret is fixed?
A: A blocked merge only proves the scanner saw the secret in that branch. It does not prove the credential was rotated or revoked at the provider, and the same key may still work in production or remain usable through Git history. The operational test is credential invalidation, not merge failure.
Q: How should teams handle secrets found in CI/CD logs or collaboration tools?
A: They should treat those locations as first-class secret sources, not side channels. If detection only covers repositories, secrets pasted into logs, chat, ticketing, or document systems will stay invisible even though they can still grant access. Coverage has to follow where developers actually work.
Q: How do organisations know whether secret scanning is actually working?
A: Look for fewer valid secrets left in circulation after detection, not just higher detection counts. Working programmes can show fast owner assignment, reliable false-positive suppression, and automated invalidation before a secret can be reused. If alerts do not change credential status, the control is informational rather than protective.
Technical breakdown
Why PR-only scanning creates a timing gap
Pull-request scanning only evaluates the state of a branch when a review event occurs. That leaves a window between the first push and the PR, during which the secret is already present on the remote repository. In practice, developers also create draft branches, pause work, and share code long before formal review. If a scanner only watches merge events, the exposure window exists outside its decision point. The issue is not scanner accuracy but scanner placement in the lifecycle.
Practical implication: move detection to push-time and pre-commit controls so exposure is caught before the repository becomes the source of truth.
Why non-code SaaS surfaces matter
Secrets rarely stay confined to source code. Teams paste API keys, tokens, and service account details into CI/CD logs, Slack, Jira, S3, and Confluence because those systems are part of how work actually gets done. Those surfaces are operationally relevant but often invisible to code-only scanning. Once a credential leaves the repository boundary, PR controls cannot see it. That turns secret exposure into a broader collaboration and workflow governance problem, not just a developer hygiene problem.
Practical implication: expand secret detection to adjacent SaaS and workflow systems, not just repositories and build pipelines.
Why caught does not mean fixed
A scanner can block a merge and still leave the credential live. If the developer removes the secret from the branch but does not rotate or revoke the key at the provider, the original credential may still work, and the old commit may still exist in Git history. That is a remediation mismatch: detection succeeded, but identity risk remained. In identity terms, the object that matters is the credential, not the ticket.
Practical implication: require verified revocation as the definition of remediation, not branch deletion or issue closure.
Threat narrative
Attacker objective: The attacker wants a still-valid credential that provides access to SaaS applications, repositories, or cloud resources before the owner revokes it.
- Entry occurs when a developer pushes a credential into a branch, draft commit, or external workspace before any pull-request scan runs.
- Credential exposure persists because the secret appears in remote repository history or in collaboration systems that PR-only controls never inspect.
- Impact follows when the exposed secret is discovered and used while it is still active, or when a false sense of remediation leaves the credential usable after a merge block.
Breaches seen in the wild
- 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.
- Red Hat Consulting GitLab breach 2025: Extortionists copied a Red Hat Consulting GitLab instance, exposing customer tokens, keys and database connection strings held in engagement reports.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Git lifecycle coverage is now the governing concept, not pull-request scanning. The article shows that secret exposure happens before merge, after merge, and outside code entirely. That means the control boundary is the lifecycle of the credential across developer workflows, not the review event. Teams that frame the problem as PR scanning will keep underestimating exposure.
Verified revocation is the only meaningful remediation state. Deleting a branch, closing a ticket, or passing a scan does not change whether the credential still works. This is a classic governance failure in NHI programmes: the control is judged by detection outcome instead of identity state. The practitioner conclusion is simple, if the secret is still live, nothing has been fixed.
Secret sprawl is the right named concept for this problem. Credentials now spread across code, build logs, collaboration tools, and long-lived Git history, which means the attack surface is a workflow graph rather than a repository. That makes inventory, detection, and revocation inseparable. Practitioners need to govern where secrets can appear, not only where they are committed.
Standing exposure windows are what attackers exploit, not scanner misses. The article makes clear that the problem is often delay, not invisibility. A secret can be discoverable for seconds or hours before the program notices, and automated scrapers do not wait. That shifts the field from after-the-fact detection toward reducing the time a credential remains reachable.
NHI governance has to extend beyond developer repositories into collaboration systems. The article names CI/CD logs, Slack, Jira, S3, and Confluence because those are where credentials are actually handled during delivery work. That is the practical lesson: identity risk now follows operational context, so the governance model must follow the same path.
What this signals
Secret scanning has become a lifecycle governance problem. The useful control question is no longer whether a scanner exists, but whether the programme follows the secret from creation to revocation across code, build systems, and collaboration platforms. Teams that keep detection at the PR gate will continue to miss the places where credentials are actually exposed.
Verified revocation is the control that separates signal from safety. A found secret is only useful if the underlying credential is invalidated and confirmed dead. Without that step, detection becomes a reporting function while the live access path remains open.
For practitioners
- Implement push-time secret detection Scan code the moment it reaches the remote repository so exposure is detected before a draft branch sits unreviewed for hours or days.
- Add historical repository scanning Search abandoned branches and commit history to find secrets that never passed through a pull request and may still be accessible in old content.
- Expand detection beyond source control Include CI/CD logs, Slack, Jira, S3, and Confluence in the scanning scope because those are common places where credentials leak during normal work.
- Require verified revocation before closure Treat remediation as complete only after the provider confirms the key, token, or service account credential is dead, not merely removed from code.
Key takeaways
- PR-only scanning leaves a large part of the exposure window untouched because secrets can leak before review and outside the repository.
- The article’s core operational point is that remediation is not complete until the credential has been verified dead at the provider.
- Secrets programmes need lifecycle coverage across code, CI/CD, collaboration tools, and history if they are to reduce actual identity risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article focuses on secrets leaking before PR review and across non-code surfaces. |
| NHI-01 — Improper Offboarding | The article shows that deleted branches do not equal credential offboarding or revocation. | |
| NHI-07 — Long-Lived Secrets | Secrets remain risky when they stay valid after discovery or merge-blocking events. | |
| Recommendation — Scan the full delivery lifecycle for leaked secrets and revoke exposed credentials immediately. Treat branch deletion as incomplete until the underlying secret is formally offboarded. Reduce secret lifetime and verify that exposed credentials are no longer valid. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article's remediation gap is about rotation and invalidation of authenticators. |
| Recommendation — Apply authenticator management controls to enforce rotation and revocation after exposure. | ||
| CIS Controls v8 | CIS-5 — Account Management | Credential exposure affects account and secret lifecycle governance across tooling. |
| Recommendation — Inventory accounts and secrets across collaboration and build systems, then remove stale access paths. | ||
Key terms
- Git Lifecycle Coverage: The scope of secret detection across the full path from local creation to remote repository history and surrounding workflow systems. It matters because a credential can be exposed long before a pull request exists, and the control only works if it follows where the secret can actually live.
- Credential Revocation: Credential revocation is the process of disabling a secret, token, or key so it can no longer authenticate or authorize action. It is the operational half of detection, because exposed credentials remain dangerous until they are invalidated and replaced across every dependent system.
- Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
- Standing exposure window: The standing exposure window is the period during which an identity keeps access that is already active and does not need fresh approval. In identity security, it measures how long privileges, credentials, or tokens remain usable before they are revoked, rotated, or expire, creating ongoing risk if misused.
What's in the full article
Truffle Security's full article covers the operational detail this post intentionally leaves for the source:
- The four-layer coverage model that separates PR scanning from push-time, historical, and closed-loop verification controls
- Examples of where secret exposure appears outside code, including CI/CD logs, Slack, Jira, S3, and Confluence
- The article's practical definition of remediation, including what it means to verify that a key is truly dead
- The maturity model that distinguishes teams measuring detections from teams measuring confirmed revocation
Deepen your knowledge
NHI governance, secrets management, and workload identity security 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 or identity security programme, it is worth exploring.
Published by the NHIMG editorial team on July 10, 2026.
Updated on October 5, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org