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.
At a glance
What this is: This article maps where secrets accumulate on hosts and build agents, showing that exposure extends well beyond source code repositories.
Why it matters: It matters because IAM and NHI programmes that focus only on repos will miss credentials embedded in endpoints, runners, and operational workspaces.
👉 Read Truffle Security's analysis of host-level secrets sprawl beyond code scanning
Context
Secrets can land on infrastructure hosts even when teams follow standard development practices. The issue is not limited to repositories or code scanning, because root sessions, installers, troubleshooting, and build jobs all create places where credentials are written to disk.
For identity and access teams, this is a Non-Human Identity coverage problem as much as a detection problem. The same credentials that are governed in a vault or pipeline can reappear in shell profiles, service directories, temp files, logs, and CI/CD agent workspaces.
The article’s central point is that host-level exposure is usually a byproduct of normal engineering work, not a single exceptional failure. That makes coverage, inventory, and scan scope part of the control surface, not an afterthought.
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. The result is partial visibility, delayed remediation, and false confidence that the problem is contained. Teams also miss secrets that were copied after initial exposure, which is often where the live risk persists.
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. Environment variables get persisted into profile files, installers write tokens into software directories, troubleshooting leaves values in logs, and runners cache job artefacts in workspaces that survive long enough to be discovered later.
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. If you are not scanning root-owned paths, build-agent workspaces, installer trees, logs, and temporary directories, you are not seeing the full problem. Effective coverage is defined by whether those filesystem hotspots are included, not by whether one scanner ran successfully.
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.
Technical breakdown
Why secrets accumulate on hosts
Host-level secret exposure happens when credentials are written onto a machine outside a central secrets system. Common paths include shell startup files, installer directories, service configuration, temporary exports, and application logs. The problem is not always hard-coding in source. It is the operational tendency to persist values that were meant to be temporary, especially when engineers need a session to survive across reboots or future logins. On shared or long-lived hosts, those artefacts become durable evidence of access that was never meant to be durable.
Practical implication: treat host filesystems as a first-class secrets source, not a secondary scan target.
Why build agents and CI/CD workspaces are high-risk
Build agents are designed to retrieve credentials, use them, cache them, and move on. That workflow leaves residue in workspace directories, agent home paths, and job containers. Whether the platform is GitHub Actions, GitLab, Jenkins, TeamCity, or Bitbucket, the relevant risk is persistence after job execution, especially on self-hosted runners and long-lived agents. The workspace becomes a collection point for environment variables, cached artefacts, and files created during the build. If cleanup is incomplete, the next job inherits exposure from the previous one.
Practical implication: scope scanning to runner workspaces and validate that job cleanup actually removes secret-bearing artefacts.
How scan scope changes the visibility problem
A full root scan offers the broadest coverage because it traverses the entire filesystem, but it is expensive in time and disk I/O. That makes the choice of scan path a governance decision, not just a tooling one. A practical model starts with the directories most likely to contain secrets, then expands across representative host classes such as servers, virtual machines, containers, and build agents. This balances speed against completeness while making it easier to prove where coverage exists and where it does not.
Practical implication: define a tiered host-scanning programme so coverage expands from high-yield paths to full-filesystem review.
Breaches seen in the wild
- PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.
- TruffleNet stolen AWS keys campaign 2025: TruffleNet used 800+ attacker hosts to test stolen AWS keys and check SES capacity; one compromised account sent a fake $50,000 invoice.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
CI/CD agents create a persistence layer that most secrets programmes under-model: a build job is supposed to be transient, yet its workspace can outlive the access session that created it. That makes ephemeral execution and durable artefacts a poor fit unless cleanup is enforced and validated. The practitioner conclusion is that runner governance belongs in the same review cycle as secrets inventory.
Ordinary engineering work can create secrets exposure without a mistake being made: the article is right to frame the issue as a byproduct of normal administration, troubleshooting, and deployment work. That matters because policies aimed only at preventing obvious error will miss the routine behaviours that keep producing residue. The practitioner conclusion is to govern where secrets are allowed to appear, not merely how they are intended to be stored.
Host scanning should be treated as one control in a broader visibility model: secrets also travel through repositories, cloud storage, and collaboration tools, so no single scanning lane is sufficient. The useful programme design question is coverage across all places credentials can settle. The practitioner conclusion is to measure secrets discovery as an estate-wide capability, not a point product event.
What this signals
Host-level secret sprawl should be managed as an estate coverage issue: if the programme does not include endpoints, runner workspaces, and service paths, it is only measuring one part of the credential footprint. The control question is not whether secrets exist, but where they are allowed to persist.
Representative scanning is a practical way to size the gap: one server, one VM, one cloud instance, one container image, and one build agent will usually show whether the organisation has a storage problem in operational paths. That approach helps teams decide where to widen discovery before they commit to slower full-host scans.
For practitioners
- 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.
- Separate temporary from durable storage Review whether exports, logs, and troubleshooting files are landing in persistent locations where secrets survive longer than the task that created them.
- Use representative host classes to test coverage Scan one server, one VM, one cloud instance, one container image, and one build agent to see which directory patterns actually hold secrets in your environment.
Key takeaways
- Secrets exposure is not confined to source control, because hosts and build agents create additional places where credentials persist.
- The operational risk comes from ordinary admin and engineering work, which means the control problem is coverage and cleanup rather than a single faulty workflow.
- Teams that want usable visibility should start with high-yield host paths and runner workspaces, then expand to broader filesystem review.
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 CSF 2.0 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 centres on secrets persisting in files and workspaces outside intended storage. |
| NHI-07 — Long-Lived Secrets | Temporary exports and leftover artefacts become durable secrets on long-lived hosts. | |
| NHI-01 — Improper Offboarding | Build-agent artefacts and stale host files remain after jobs or sessions end. | |
| Recommendation — Scan host filesystems and build workspaces for leaked credentials, then remove exposed secrets immediately. Reduce persistence windows by replacing durable host storage with governed secret delivery. Remove residual credentials from hosts and runners when the task or job completes. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Host and runner paths need explicit permission boundaries to limit secret exposure. |
| Recommendation — Apply least-privilege access to host directories that can store credentials or job artefacts. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article ties exposure to accounts and sessions used by admins, SREs, and build agents. |
| Recommendation — Review account-driven host access and restrict where privileged sessions can write secret-bearing files. | ||
Key terms
- Host-Level Secret Exposure: Host-level secret exposure occurs when credentials are stored on or reachable from an endpoint host rather than a controlled vault or dedicated secret store. In practice, that includes shell profiles, logs, installers, temp directories, and build workspaces that persist beyond the task that created them.
- Build Agent Workspace: The file area where CI/CD jobs check out code, cache artefacts, and write intermediate files. In practice, it can retain secrets from previous jobs if cleanup is incomplete, making it a recurring source of machine identity leakage.
- Filesystem Secret Coverage: Filesystem secret coverage is the practice of scanning host paths where secrets are likely to accumulate, not just code repositories or vaults. It is a discovery discipline that reveals where credentials actually persist across infrastructure, endpoints, and operational tooling.
- 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.
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
Deepen your knowledge
NHI governance, identity lifecycle management, and secrets management 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 NHI governance programme, it is worth exploring.
Published by the NHIMG editorial team on August 28, 2026.
Updated on October 5, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org