Why do install-time payloads in CI/CD environments create outsized risk for cloud and identity security?

Install-time code runs before most teams expect any application logic, so it can steal credentials during dependency installation and then use trusted automation access to spread. In CI/CD, that can expose npm tokens, OIDC tokens, cloud metadata credentials, and API keys at once. The result is a supply chain event that becomes an identity event across multiple clouds.

Why This Matters for Security Teams

Install-time payloads are dangerous because they run inside the trust boundary of the build system, not after it. By the time a package manager or build hook executes, CI/CD already has access to cloud tokens, artifact registries, and service credentials that would never be exposed to a normal end user. That turns a seemingly routine dependency install into an identity compromise, not just a code execution event.

The risk is amplified by secrets sprawl. NHI Mgmt Group notes that 96% of organisations store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, and 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, in the Ultimate Guide to NHIs. In practice, many security teams encounter this only after a compromised runner has already authenticated to multiple cloud services.

That is why this issue sits at the intersection of supply chain security and NHI governance, not just dependency hygiene. The same install step can expose npm tokens, OIDC tokens, metadata credentials, and API keys in one execution path, as seen in incidents documented in the Shai Hulud npm malware campaign. In practice, many security teams encounter the blast radius only after trusted automation has already been repurposed for lateral movement.

How It Works in Practice

Install-time payloads typically hide in dependency lifecycle scripts, malicious package updates, or transitive dependencies that execute before application tests begin. In CI/CD, those steps often run with broad permissions because the pipeline is expected to fetch code, authenticate to package registries, and publish artifacts. Once the payload executes, it can read environment variables, query instance metadata, pull cached credentials from the runner, or exfiltrate tokens from build logs.

Mitigation works best when teams treat the runner as a high-risk identity rather than a disposable compute node. Current guidance suggests combining least privilege with ephemeral credentials, strong isolation, and runtime policy checks. For cloud access, prefer short-lived tokens issued per job, not long-lived static secrets. For workload authentication, use workload identity primitives such as OIDC-based federation or SPIFFE-aligned identities instead of embedding cloud keys in the pipeline. For detection and response, log every install step and revoke credentials automatically when a build fails or behaves unexpectedly.

• Disable or tightly restrict package lifecycle scripts where possible.
• Run dependency installs in isolated, ephemeral runners with no standing access.
• Scope OIDC and cloud roles to a single job, repository, branch, or environment.
• Keep secrets out of environment variables unless the job absolutely requires them.
• Verify package integrity and provenance before installation.

The NIST Cybersecurity Framework 2.0 reinforces the need for asset, identity, and access visibility across trusted systems, while NIST control guidance on privileged access and monitoring aligns with ephemeral build access and revocation discipline. The broader NHI pattern is visible in NHI Mgmt Group’s Guide to the Secret Sprawl Challenge, where hidden credentials in development tooling become the entry point for broader compromise. These controls tend to break down when runners are shared across teams because one compromised job can inherit cached credentials from another.

Common Variations and Edge Cases

Tighter install-time controls often increase build friction, requiring organisations to balance developer speed against blast-radius reduction. That tradeoff becomes sharper in polyglot repositories, self-hosted runners, and monorepos where multiple package managers, caches, and cloud accounts intersect.

Best practice is evolving for environments that use AI-assisted coding or agentic automation inside pipelines. Current guidance suggests treating those systems as autonomous workloads with dynamic access needs, not as static service accounts. That means runtime authorisation, short-lived credentials, and real-time policy evaluation matter more than pre-approved role maps. The NIST Cybersecurity Framework 2.0 helps structure governance, but it does not eliminate the need to inspect what the install step can reach at execution time.

Edge cases appear when organisations rely on private package mirrors, internal registries, or nested CI jobs. Those environments can reduce internet exposure but still allow malicious payloads to harvest tokens from the local context. They can also fail when secrets are injected too early into the pipeline, because the payload only needs one execution window. For real-world examples of pipeline abuse and secret harvesting, see the CI/CD pipeline exploitation case study and the Reviewdog GitHub Action supply chain attack. These controls tend to break down when shared runners cache credentials across jobs because install-time code can inherit access it was never meant to have.

Related resources from NHI Mgmt Group

• Why do compromised IDE extensions create such broad identity and secrets risk in cloud-native environments?
• What do security teams get wrong about workload identity in cloud and CI/CD environments?
• Why do malicious extensions and browser-based malware create outsized risk for developers working with cloud and CI/CD systems?
• How should security teams reduce lateral movement risk in CI/CD and cloud environments?