Notifications
Clear all
Topic starter
10/07/2026 9:15 pm
TL;DR: Secret exposure is happening before pull requests open, and credentials now leak through CI/CD logs, Slack, Jira, S3, and Confluence as well as repositories, according to TruffleHog. The operational gap is not discovery alone, but whether leaked secrets are revoked, verified dead, and covered across the full Git lifecycle.
NHIMG editorial — based on content published by TruffleHog: Your PR scan is missing half the problem
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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.
👉 Read TruffleHog's analysis of why PR scanning misses pre-merge secret exposure →
Secret scanning beyond PRs: what IAM teams need to fix?
Explore further
10/07/2026 9:38 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: PR scanning misses pre-merge secret exposure across Git lifecycle
