Look for unexpected child processes during package install, unusual access to vaults or credential stores, outbound connections that resemble dead drops or DNS exfiltration, and token use from locations that do not match normal developer behaviour. Those signals suggest the host is doing more than dependency resolution and should be treated as compromised.
What to check first on a developer workstation or CI runner
A host used to steal secrets usually leaves a pattern, not a single indicator. The most useful first pass is to compare process trees, network activity, and secret-store access against the host’s normal build or development behaviour. A legitimate package install may touch dependency tooling; a compromised one often adds collection, staging, and exfiltration steps around it.
Process anomalies matter because secret theft on these systems often starts with code or build hooks, then pivots into enumeration of vaults, environment variables, or local credential caches. That is why suspicious child processes launched during install, build, or test phases are a strong clue rather than a generic “malware” signal.
On the network side, look for outbound connections that are sparse, encoded, or time-correlated with build steps. Repeated lookups, DNS-like beacons, and dead-drop style traffic can indicate that secrets were staged and exported in small chunks rather than moved in one obvious transfer. On ci runner, compare that behaviour with the normal pattern of artifact download and package resolution.
How secret theft shows up in vaults, tokens, and build logs
Access to vaults or credential stores is only suspicious when it does not fit the job at hand. A runner that rarely needs long-lived credentials but suddenly reads secret backends, refreshes tokens outside the pipeline window, or touches unrelated projects should be treated as high risk. The same is true when a developer workstation begins using tokens from locations or tools that do not match the normal operator profile.
Secrets theft also leaves secondary traces in logs and telemetry. Failed redaction, unexpected secret prints, and access to metadata services or credential helpers may show that the attacker is collecting multiple secret types, not just one leaked token. NHIMG’s Guide to the Secret Sprawl Challenge is useful background when you need to connect those symptoms to the broader problem of scattered credentials across code, pipelines, and developer tooling.
CI environments deserve special attention because they often mix short-lived build work with broad access to repositories, registries, cloud APIs, and deployment systems. When a runner starts behaving like a privileged operator, that is a sign of credential abuse, not just a noisy build.
Which compromise paths are most likely in practice
In real incidents, the compromise path is often workstation or runner access first, then secret collection, then reuse elsewhere. That is why a suspicious host can be the source of a much wider breach even when the initial foothold looks minor. NHIMG’s Bybit hack 2025 shows how stolen session material from a developer device can become a path to high-impact changes, while the CircleCI breach 2023 illustrates how CI compromise can expose many downstream secrets at once.
Attackers also like build systems because they are trusted by default and often sit inside normal software delivery flows. A runner that accesses source, dependencies, signing material, or deployment credentials outside its expected job scope may be acting as a collection point before secrets are replayed on another host or in another cloud account. NHIMG’s tj-actions/changed-files compromise 2025 is a good example of how build-time trust can be turned into secret exposure.
Risk and Threat Considerations
A compromised workstation or runner is dangerous because it sits close to the most valuable operational credentials. Once an attacker can read local secrets, inject build steps, or impersonate the normal build identity, they can often expand from one system to many without needing noisy privilege escalation.
Failure mechanism: The host is abused to harvest credentials, session material, or API keys during normal-looking development activity, then to stage and exfiltrate them through low-volume network channels or build output.
Impact: The result can be source access, environment takeover, artifact tampering, cloud control-plane abuse, or lateral movement into deployment and production systems.
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, OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Secret theft from runners and workstations is directly about exposed credentials and tokens. |
| NHI-04 — Insecure Authentication | Unexpected token use from abnormal locations signals misuse of authentication material. | |
| NHI-07 — Long-Lived Secrets | Developer and CI compromise is often amplified by durable credentials on the host. | |
| Recommendation — Hunt for exposed secrets in build logs, processes, and vault access, then revoke and rotate them. Investigate anomalous token and session use, then invalidate compromised authenticators. Prioritise replacing long-lived secrets with short-lived credentials and enforce rapid rotation. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Stolen tokens and replayed credentials are an authentication failure pattern at the API layer. |
| API5 — Broken Function Level Authorization | A stolen build identity can be abused to perform actions beyond its intended scope. | |
| Recommendation — Validate token provenance and revoke any credentials used from untrusted build hosts. Restrict build identities to the smallest action set needed and review privileged endpoints. | ||
| MITRE ATT&CK | T1555 — Credentials from Password Stores | Suspicious access to vaults and credential stores maps to credential collection behaviour. |
| T1041 — Exfiltration Over C2 Channel | Dead-drop style outbound traffic fits covert exfiltration of stolen secrets. | |
| Recommendation — Detect and alert on credential-store access patterns that deviate from normal tooling. Correlate low-volume outbound traffic with secret access and isolate suspected hosts. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Host and pipeline audit trails are needed to confirm suspicious secret access. |
| IA-5 — Authenticator Management | Secret theft on dev and CI systems often requires rapid rotation and invalidation of authenticators. | |
| SI-4 — System Monitoring | Detection depends on monitoring process creation, network activity, and credential use on build hosts. | |
| Recommendation — Review audit logs for abnormal secret-store access, token use, and build-step child processes. Rotate, revoke, and shorten the lifetime of exposed authenticators immediately. Monitor child processes, DNS, and token usage for suspicious deviations on developer systems. | ||
Practitioner Guidance
What to verify: Check whether the process tree, token use, secret-store access, and outbound destinations match the runner or developer’s historical baseline. If a host that should only resolve dependencies is suddenly reading vaults, invoking curl or shell children, or using tokens from an unexpected location, treat that as compromise until proven otherwise.
What to prioritise: Preserve logs, token issuance records, build history, and network telemetry before rotating everything blindly. You need to know which secrets were accessed, whether they were long-lived or ephemeral, and whether the same host touched signing keys, deployment credentials, or only low-value tokens.
Practitioner takeaway: The key judgement is whether the host stayed within its normal build role; once a workstation or runner starts acting like a secret collector, response should focus on containment and blast-radius reduction, not just malware removal.
Related resources from NHI Mgmt Group
- How should teams respond when CI or developer secrets are exposed?
- Why do secrets stay dangerous even when they are no longer actively used?
- What should security teams do first when a package install may have executed a Shai-Hulud style payload on a developer workstation or CI runner?
- What is secrets exposure in NHI security?