Who is accountable when install-time malware exposes cloud or publishing secrets?

Why This Matters for Security Teams

Install-time malware changes the accountability question because the compromise happens inside a trusted build path, not at the edge of the environment. If a package install, action, or plugin can read secrets during execution, the blast radius includes cloud credentials, publishing tokens, signing keys, and any downstream system that trusts the pipeline. NHI Management Group has documented how supply chain and CI/CD failures turn into credential exposure in cases like the Shai Hulud npm malware campaign and the Reviewdog GitHub Action supply chain attack.

The practical issue is that ownership is often split between platform engineering, IAM, security operations, and release management, while the attack path crosses all of them. OWASP’s Non-Human Identity Top 10 treats this as a workload identity and secrets governance problem, not just a malware problem. The right accountability model is therefore about who approved the trust boundary, who exposed the credential, and who failed to constrain runtime access. In practice, many security teams only discover this after a secret has already been exfiltrated from a build runner, rather than through intentional pipeline design.

How It Works in Practice

Accountability is easiest to assign when the control points are explicit. The team that owns the build system is responsible for runner hardening, package allowlisting, and isolation. The team that owns secrets management is responsible for limiting which workloads can request which credentials, for how long, and under what conditions. The team that owns release access is responsible for making sure publishing tokens, cloud credentials, and signing keys are not broadly available to every install step. That shared model matches NIST guidance on least privilege and system boundary protection in NIST SP 800-53 Rev. 5.

For install-time malware, static secrets are the weak point. Current guidance suggests moving toward short-lived, task-scoped credentials so the runner only receives what it needs at the moment it needs it. That means using workload identity rather than hardcoded tokens, issuing ephemeral access for a specific job, and revoking it automatically when the job ends. Where possible, secrets should never be present as reusable environment-wide values; they should be fetched just in time and constrained by policy at request time. NHI Management Group’s Guide to the Secret Sprawl Challenge and the 2024 State of Secrets Management Survey both show why centralisation and lifecycle control matter when credentials are spread across toolchains.

• Use isolated runners for untrusted installs and treat dependency execution as hostile by default.
• Bind secrets to workload identity, not to the machine image or the developer account.
• Apply policy at request time so the token is issued only for the approved repo, branch, job, and destination.
• Log secret access, package install events, and outbound network calls together so incident response can reconstruct the path.

These controls tend to break down in self-hosted runners with broad network reach because the runner can both install untrusted code and directly reach high-value credentials.

Common Variations and Edge Cases

Tighter secret scoping often increases delivery friction, requiring organisations to balance release speed against credential exposure. That tradeoff becomes visible in monorepos, ephemeral preview environments, and publisher pipelines that need multiple downstream services to work in one job. There is no universal standard for this yet, but best practice is evolving toward context-aware authorisation, just-in-time secret delivery, and narrower trust per workflow step rather than per environment.

Edge cases matter. A package manager hook can exfiltrate tokens even when the build itself never reaches production. A compromised CI plugin can read cached credentials if runners are reused. A publishing pipeline may need temporary access to artifact registries, cloud storage, and code-signing services in the same workflow, which makes one-size-fits-all IAM roles too coarse. The 230M AWS environment compromise and CI/CD pipeline exploitation case study illustrate how quickly pipeline trust can expand beyond what teams intended.

For teams handling publishing secrets, the cleanest accountability rule is simple: whoever can approve install-time execution must also prove that the credential path is ephemeral, least-privileged, and revocable. Where that cannot be demonstrated, the governance gap is not solved by blame assignment after the fact.

Related resources from NHI Mgmt Group

• Who is accountable when a stolen OAuth token exposes cloud secrets?
• Who is accountable when a compromised package exposes cloud or developer secrets?
• Who is accountable when a connector exposes sensitive corporate context?
• How should security teams prioritise NHI remediation in cloud environments?