Why do CI and developer secrets become the main target after package execution?

Why This Matters for Security Teams

CI and developer secrets become the main target after package execution because the package is rarely the real prize. The prize is the execution environment and the identity material already present there: cloud access keys, service account tokens, SSH material, deployment credentials, and API secrets. Once malicious code runs inside build or bootstrap context, it can pivot faster than many application controls are designed to react.

This is why secret exposure in pipelines is not just a code review problem. It is an identity problem, and NHIMG has consistently shown that pipeline compromise turns small execution footholds into broad credential access. See the Guide to the Secret Sprawl Challenge and the CI/CD pipeline exploitation case study for how quickly build trust collapses once secrets are reachable. OWASP’s Non-Human Identity Top 10 frames this as an NHI governance failure, not a narrow application bug.

In practice, many security teams encounter secret theft only after a compromised runner, package, or action has already used its legitimate access to enumerate everything nearby.

How It Works in Practice

Package execution in CI, build, or bootstrap phases usually runs with more privilege than the package itself should ever need. That mismatch is what attackers exploit. A malicious dependency, setup script, install hook, or post-install step can inspect environment variables, read mounted files, query metadata services, call secret managers, or reuse cached credentials. The value is not the code execution alone. The value is the reachable identity surface.

Current guidance suggests treating these environments as ephemeral workload identities rather than developer convenience layers. That means short-lived credentials, per-job isolation, and runtime authorization instead of static secrets that persist across many runs. In this model, secrets should be issued just in time, scoped to the specific task, and revoked automatically when the job ends. Static developer tokens and long TTL credentials are especially dangerous because they remain useful long after the original package run has finished.

Practitioners should also separate what the runner can do from what the package can see. That often includes:

• Using workload identity instead of shared secrets where possible, such as OIDC-based federation or SPIFFE-aligned identity patterns.
• Blocking broad environment inheritance so child processes do not inherit unnecessary credentials.
• Applying policy at request time rather than assuming a fixed role is safe for every job.
• Limiting access to the metadata service, secret manager, and cloud control plane from untrusted build steps.

NHIMG’s analysis of the 52 NHI Breaches Analysis shows that once an automation identity is exposed, attackers commonly move from package execution to broader lateral access. NIST control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls supports least privilege and credential management, but the implementation challenge is making those controls real inside fast-moving pipelines.

These controls tend to break down in monolithic runners, long-lived self-hosted build agents, and legacy release jobs because shared state makes secret isolation and revocation too slow to keep pace with execution.

Common Variations and Edge Cases

Tighter secret controls often increase pipeline friction, requiring organisations to balance build speed against credential blast radius. That tradeoff becomes more visible in environments that rely on third-party package managers, reusable actions, or internal developer tooling with broad access to cloud and source-control systems.

There is no universal standard for this yet, but current guidance suggests some clear distinctions. Public CI systems with short-lived runners can usually adopt stronger ephemeral identity controls faster than self-hosted runners embedded in private networks. Conversely, production bootstrap pipelines, release automation, and infrastructure-as-code jobs often need more careful exception handling because they may require access to signing keys, registries, or deployment roles.

Another edge case is secret discovery versus secret revocation. Discovery alone is not enough when attacker dwell time is short and leaked credentials remain valid for weeks. NHIMG’s The State of Secrets in AppSec highlights the gap between confidence and reality, while the The State of Secrets Sprawl 2026 research shows how exposed credentials continue to be exploitable when rotation is delayed. For teams modernising controls, the practical answer is to reduce what execution contexts can ever reach, not just to detect when secrets are already gone.

Related resources from NHI Mgmt Group

• How should teams respond when CI or developer secrets are exposed?
• How should security teams handle package install-time execution in CI environments?
• Why do still-valid secrets matter after public disclosure?
• What breaks when package trust and developer tooling are treated as separate risks?