Topic starter
28/08/2026 12:04 pm
TL;DR: Truffle Security finds that secrets do not stay in code repositories; they also accumulate on hosts, in shell profiles, installer directories, logs, temp paths, and CI/CD workspaces. Host scanning is a governance problem, not just a detection task, because exposure often comes from ordinary engineering work rather than a single failure.
Editorial analysis by NHI Mgmt Group, based on content published by Truffle Security: “Beyond Laptops: What secrets to expect on your endpoints”.
Key questions
Q: What breaks when teams rely on repository scanning alone to find leaked secrets?
A: Repository scanning alone misses secrets that originate outside source code and follow credentials into laptops, chat tools, build outputs, and infrastructure configurations.
Q: Why do host filesystems and build agents create recurring secret exposure?
A: Because credentials are often written there as part of ordinary engineering work, not as a separate incident.
Q: How can security teams tell whether host scanning is complete enough?
A: Look for coverage across the host classes and paths where secrets are most likely to settle.
Practitioner guidance
- Broaden secrets discovery beyond repositories Add host filesystems, build workspaces, and service directories to the normal discovery scope so endpoint storage is reviewed alongside code and cloud sources.
- Prioritise high-yield directories first Start with /root, /home, /opt, /srv, /var/www, /tmp, /var/tmp, and /var/log on representative hosts before expanding to full-filesystem scans.
- Validate cleanup on self-hosted runners Check whether CI/CD jobs actually remove cached credentials and artefacts from GitHub Actions, GitLab, Jenkins, TeamCity, and Bitbucket workspaces.
Bottom line: Secrets exposure is not confined to source control, because hosts and build agents create additional places where credentials persist.
What's in the full article
Truffle Security's full blog post covers the operational detail this post intentionally leaves for the source:
- Platform-by-platform workspace paths for GitHub Actions, GitLab, Jenkins, TeamCity, and Bitbucket
- The directory shortlist for root, home, temporary, service, and log locations on endpoint hosts
- Practical scan-order guidance for choosing between representative host scans and full filesystem review
- Operational notes on permissions, runtime load, and when a root-level scan becomes necessary
👉 Read Truffle Security's analysis of host-level secrets sprawl beyond code scanning →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 days ago 2 times by NHI Mgmt Group
This topic was modified 2 days ago by NHI Mgmt Group
28/08/2026 12:04 pm
Host-level secrets sprawl is a coverage problem before it is a scanning problem: teams often assume the secrets estate is concentrated in repositories, but operational systems continuously generate new storage locations. Shell profiles, installers, log files, temp paths, and runner workspaces are part of the identity surface because they preserve credentials outside intended lifecycle controls. The practitioner conclusion is that discovery scope must extend across host classes, not just code.
A question worth separating out:
Q: Should organisations scan /root before running full filesystem discovery?
A: Yes, if load and runtime matter. /root often contains the same kinds of secrets as a user home directory, and the path is high value because it holds root-owned configuration and scripts. A staged approach lets teams find the obvious exposures first before committing to a full scan.
👉 Read our full editorial: Host-level secrets sprawl is broader than code scanning alone
This post was modified 3 days ago 3 times by NHI Mgmt Group