Who is accountable when a malicious package exposes source code through a build script?

Accountability usually spans the software supply-chain owner, the CI platform owner, and the engineering team that approved the dependency or build pattern. In regulated environments, the organisation remains responsible for protecting internal source and secrets even when the exposure came through a third-party package. That makes build governance and vendor review part of security accountability, not optional hygiene.

Why This Matters for Security Teams

A malicious package that exposes source code through a build script is not just a dependency problem. It is a control failure across supply-chain governance, CI trust boundaries, and secrets management. NHI Mgmt Group has repeatedly shown that secrets exposure is common in software delivery paths, including cases where third-party components pull data out of build environments. The Ultimate Guide to NHIs — Why NHI Security Matters Now notes that 96% of organisations store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools.

That matters because build scripts often run with broad access to source repositories, signing material, package caches, and deployment tokens. Once a package executes during install or build, accountability is no longer limited to the author of the package. The organisation that approved the dependency chain still owns the risk, and the platform team still owns the execution boundary. The exposure path is especially serious when build systems are treated as “trusted automation” rather than as privileged workloads that need inspection and containment. For an incident pattern like this, see NHI Mgmt Group’s Shai Hulud npm malware campaign and CrewAI GitHub Token Leak.

In practice, many security teams encounter this only after a package has already executed inside CI and source code or tokens have already left the environment.

How It Works in Practice

Accountability for this class of incident usually splits across three layers: the engineering team that selected the package or build pattern, the CI or platform team that allowed execution, and the organisation’s security and governance function that set the rules for dependency use, secrets handling, and build isolation. That is consistent with NIST guidance on separating control ownership from implementation details in NIST SP 800-53 Rev 5 Security and Privacy Controls. The practical question is not “who wrote the malicious package” but “who had authority to prevent it, detect it, and limit blast radius.”

Operationally, mature teams reduce exposure by treating build-time execution as hostile-by-default:

• Pin dependencies and review changes to lockfiles, manifests, and build hooks.
• Run builds in ephemeral, least-privilege runners with no standing access to production secrets.
• Separate source retrieval from secret retrieval so package install steps cannot read tokens directly.
• Use short-lived credentials for CI jobs and revoke them automatically after the run.
• Log package install behavior, outbound network access, and file-system writes from build scripts.

This is where NHI governance becomes practical. Build systems rely on non-human identities such as service accounts, OIDC-backed job identities, and signing keys, so secret lifecycle controls matter as much as code review. NHI Mgmt Group’s Ultimate Guide to NHIs shows why poor visibility and overprivileged identities make these incidents harder to contain. Where package execution can reach external endpoints, the risk profile also resembles the abuse patterns described in the Anthropic report on AI-orchestrated cyber espionage, because automated tooling can chain actions quickly once it has access.

These controls tend to break down when CI runners share long-lived credentials, cache credentials across jobs, or execute untrusted build steps inside persistent environments.

Common Variations and Edge Cases

Tighter build isolation often increases delivery overhead, requiring organisations to balance release speed against containment. There is no universal standard for this yet, but current guidance suggests distinguishing between ordinary package bugs and malicious build-time behavior, because the accountability model changes when the package intentionally exfiltrates data.

One edge case is third-party build tooling that legitimately needs repository access but should never see signing keys or deployment tokens. Another is monorepo pipelines where multiple teams inherit the same runner configuration, making ownership ambiguous when exposure occurs. A third is vendor-managed CI, where the platform owner may operate the runners but the engineering team still approves dependency risk. In those cases, incident review should map: who approved the dependency, who controlled the runner, who held the secrets, and who had authority to block execution.

For organisations building a control narrative, the key lesson from 52 NHI Breaches Analysis is that identity and secrets failures are often discovered through downstream damage rather than preventive review. The right accountability model therefore treats build governance, NHI lifecycle control, and third-party review as one operating responsibility, not separate audits.

Related resources from NHI Mgmt Group

• Who is accountable when malicious code enters through a package registry?
• Who is accountable when a build process loads malicious code and exposes credentials?
• Who should respond first when a build host resolves a malicious npm package?
• How should teams reduce risk from malicious npm package installs?