Notifications
Clear all
Topic starter
28/08/2026 12:04 pm
TL;DR: Secrets do not stay in code repositories; they also accumulate on hosts, in shell profiles, installer directories, logs, temp paths, and CI/CD workspaces, according to TruffleHog. Host scanning is a governance problem, not just a detection task, because exposure often comes from ordinary engineering work rather than a single failure.
NHIMG editorial — based on content published by TruffleHog: Beyond Laptops: What secrets to expect on your endpoints
By the numbers:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
Questions worth separating out
Q: How should security teams find secrets on endpoint hosts before they become reusable credentials?
A: Start with the directories where normal administration and engineering work leave traces, then scan build agents, temporary locations, and logs with the same discipline you apply to repositories.
Q: Why do host filesystems increase the risk of secret exposure in modern infrastructure?
A: Host filesystems turn short-lived activity into durable storage.
Q: What do teams get wrong about secrets scanning and malicious code detection?
A: They often treat secrets scanning as a standalone control when it is only one layer of a broader trust problem.
Practitioner guidance
- Expand discovery beyond repositories Add filesystem scanning for /root, /home, /opt, /srv, /var/www, /tmp, /var/tmp, and /var/log so host-level secret exposure becomes visible in the same programme that watches code and cloud storage.
- Prioritise build agent workspaces Scan runner homes and job workspaces on GitHub Actions, GitLab, Jenkins, TeamCity, and Bitbucket because persistent agent storage often holds the exact credentials used during build execution.
- Sample one representative host per class Start with one server, one VM, one cloud instance, one container image, and one build agent, then widen the scan based on where secrets actually surface in your environment.
What's in the full article
TruffleHog's full article covers the operational detail this post intentionally leaves for the source:
- Specific host path shortlist by operating system and workload type for first-pass scanning.
- Directory-by-directory guidance for root, home, temp, log, and service locations.
- CI/CD runner path examples across GitHub Actions, GitLab, Jenkins, TeamCity, and Bitbucket.
- Practical scan sequencing advice for representative hosts before running full-fleet scans.
👉 Read TruffleHog's analysis of where secrets accumulate on endpoint hosts →
Secrets on hosts and build agents: what IAM teams miss?
Explore further
28/08/2026 12:04 pm
Host-level secrets sprawl is a coverage problem before it is a detection problem. Most secrets programmes still over-focus on source repositories and vault hygiene while leaving host filesystems under-scanned. That misses the everyday places where credentials accumulate: profiles, logs, /tmp, /opt, and runner workspaces. The practical conclusion is that a secrets estate cannot be governed if host coverage is excluded from the inventory model.
A few things that frame the scale:
- 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, according to The State of Secrets Sprawl 2026.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to the same report, which shows why discovery without revocation leaves risk intact.
A question worth separating out:
Q: What should organisations do immediately when a secret is found on a shared host?
A: Revoke the credential, identify where else it may have been written, and inspect adjacent paths such as logs and workspace directories before the exposure is assumed to be isolated. Shared hosts can hide multiple copies of the same secret, so containment has to account for persistence and reuse, not just the first file that was found.
👉 Read our full editorial: Host-level secrets sprawl is broader than code scanning alone
