Secrets on shared or long-lived runners break the assumption that installation is a harmless administrative step. A malicious dependency can harvest environment variables, config files, and local tokens, then use them to alter repositories or publish new packages. The failure is both technical and governance-related because one compromise can spread across several trust domains.
Why This Matters for Security Teams
Secrets on CI runners and developer laptops turn a convenience layer into a shared attack surface. A runner that persists between jobs, or a workstation that accumulates tokens over months, can silently inherit access to source control, package registries, cloud APIs, and internal services. That breaks separation between build, test, and release functions, and it also weakens governance because one compromised identity can impersonate many workloads.
This is not a hypothetical nuisance. NHI Management Group has documented how secrets exposure extends well beyond repositories in the Guide to the Secret Sprawl Challenge, and the same pattern appears in the CI/CD pipeline exploitation case study. The OWASP Non-Human Identity Top 10 also treats unmanaged machine identities and overexposed credentials as a core control failure, not a tooling inconvenience.
One useful benchmark: GitGuardian and CyberArk reported that the average time to remediate a leaked secret is 27 days, which means exposure often lasts long enough for an attacker to pivot across systems. In practice, many security teams discover this only after a package publish, repo rewrite, or cloud misuse has already occurred, rather than through intentional control testing.
How It Works in Practice
The failure starts with trust assumptions. CI runners and developer machines are often treated as temporary compute, yet they routinely hold long-lived credentials for Git, cloud providers, signing services, and internal APIs. Once those secrets are present, malware, a malicious dependency, or even a copied shell history can extract them from environment variables, config files, caches, and dotfiles. From there, the attacker does not need the original device any more. They can use the stolen secrets to push code, alter release artefacts, or create additional tokens and service accounts.
Good practice is to reduce both secret lifetime and secret portability. That means using OWASP Non-Human Identity Top 10 guidance to eliminate standing credentials, and pairing it with short-lived, JIT-issued access tied to workload identity rather than human convenience. For pipelines, current guidance suggests ephemeral credentials per job, strong brokered authentication, and automatic revocation when the job ends. For laptops, the safer model is to avoid persistent cloud keys altogether and to rely on device-bound or federated identity flows where possible.
- Issue secrets only for the task, not for the workstation session.
- Prefer workload identity over copied API keys or shared service accounts.
- Rotate or revoke tokens immediately after job completion or handoff.
- Log secret access as a privileged event, not as routine developer activity.
- Scan runner images, dotfiles, and build caches for residual credentials.
GitGuardian’s research shows that internal repositories are far more likely to contain secrets than public ones, which reinforces a key point: private infrastructure is not the same as protected infrastructure. This aligns with lessons from the Reviewdog GitHub Action supply chain attack and the Shai Hulud npm malware campaign, where build-time trust was enough to expose downstream credentials. These controls tend to break down when runners are shared across projects and developer endpoints keep cached credentials after privileged sessions end because the same secret is then reachable from multiple trust domains.
Common Variations and Edge Cases
Tighter secret controls often increase operational friction, so organisations have to balance developer speed against the cost of repeated authentication and shorter session windows. There is no universal standard for exactly how short a secret TTL should be, but current guidance consistently favours the minimum lifetime needed for the task.
Edge cases matter. Self-hosted runners that execute untrusted pull requests need stronger isolation than managed hosted runners. Air-gapped or heavily regulated environments may keep more material on endpoints, but that makes device hardening and local secret discovery even more important. AI-assisted development also changes the risk profile because code generation tools can reproduce tokens into logs, prompts, or copied examples. In that context, the safest response is not just secret scanning but strict boundary control around what the runner or laptop can reach.
The compromise most teams miss is that revocation alone is not enough. If the same developer token unlocks source control, cloud admin, and package publishing, a single leak still creates a multi-step attack path. The best reference point is the Ultimate Guide to NHIs — Static vs Dynamic Secrets, which shows why dynamic credentials outperform static ones in environments with constant change. For broader incident patterns, the 52 NHI Breaches Analysis makes the same point: once secrets are portable, compromise becomes repeatable.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses secret sprawl and weak lifecycle control on runners and endpoints. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is central when one leaked token can span multiple trust domains. |
| NIST AI RMF | Risk governance must account for autonomous tooling that can expose or misuse secrets at runtime. |
Replace standing secrets with short-lived credentials and enforce rotation, revocation, and inventory checks.
