Who is accountable when a build process loads malicious code and exposes credentials?

Accountability usually spans engineering, platform, and security teams because the failure sits at the intersection of dependency governance, secret placement, and host hardening. NIST-style access and audit controls apply to the systems that allowed the process to run with excessive trust.

Why This Matters for Security Teams

When a build process loads malicious code and exposes credentials, accountability is not limited to the person who merged the change. The failure usually sits across dependency governance, pipeline trust, secret placement, and host hardening, which means engineering, platform, and security all own part of the control gap. NIST guidance on access control and logging is relevant here because the question is really about who allowed an overly trusted execution path to exist in the first place.

This is also a supply chain problem, not just a code review problem. If build runners can fetch unpinned dependencies, execute untrusted hooks, or read long-lived secrets from environment variables, then compromise becomes a matter of time. NHIMG research on the 52 NHI Breaches Analysis shows how quickly weakly governed machine identities and exposed secrets turn into broader compromise, while the Guide to the Secret Sprawl Challenge highlights the operational risk of placing credentials where build systems can inherit them too broadly. In practice, many security teams encounter the incident only after the credentials have already been reused elsewhere.

How It Works in Practice

Accountability should be assigned by control ownership, not by whichever team notices the breach first. Engineering is typically accountable for dependency hygiene, pipeline configuration, and code provenance. Platform is accountable for runner isolation, image hardening, and workload identity. Security is accountable for the policy model, detection coverage, and enforcement standards that make abuse visible and containable.

Practically, the build path should be treated as an untrusted execution environment. That means pinning dependencies, signing artifacts, restricting outbound access, and replacing static secrets with short-lived credentials wherever possible. The OWASP Non-Human Identity Top 10 is useful for framing machine-to-machine exposure, while NIST SP 800-53 Rev. 5 Security and Privacy Controls maps well to access restriction, auditability, and configuration management. For build systems specifically, the strongest pattern is to issue just-in-time credentials only for the job that needs them, then revoke them at completion.

That model works best when the runner has its own workload identity and the secret store is never mounted broadly into the job context. It is also where the evidence trail matters: if malicious code executed, the audit log should show what identity was used, what repository or artifact introduced it, and which approval or policy check failed. This is exactly why the Reviewdog GitHub Action supply chain attack is instructive, since it illustrates how a trusted automation step can become the channel for secret exposure. These controls tend to break down when legacy CI runners share credentials across jobs because one compromised step can inherit trust from the whole pipeline.

Common Variations and Edge Cases

Tighter build controls often increase friction for release velocity, so organisations have to balance stronger containment against developer experience and delivery speed. There is no universal standard for assigning accountability in every pipeline architecture, but current guidance suggests using a shared-responsibility model tied to control boundaries rather than a single owner for the incident.

Edge cases appear in monorepos, ephemeral preview environments, self-hosted runners, and third-party build integrations. In those environments, responsibility can shift because the platform team may own the runner, the application team may own the dependency lockfile, and the security team may own the policy that decides whether unverified code may execute. The right question is not only who caused the failure, but who failed to prevent secret reachability after trust was already elevated.

For deeper context on how exposed secrets become operationally exploitable, pair the Shai Hulud npm malware campaign with the Anthropic AI-orchestrated cyber espionage campaign report; both reinforce that automated abuse compounds quickly once trust is misplaced.

Related resources from NHI Mgmt Group

• Who is accountable when a GitHub Actions workflow exposes secrets or pushes malicious code?
• Who is accountable when a malicious dependency exposes cloud and Kubernetes credentials?
• Who is accountable when a malicious skill exfiltrates code or credentials?
• Who is accountable when an AI agent or build pipeline introduces malicious code?