Who is accountable when a malicious dependency enters a build pipeline?

Why This Matters for Security Teams

When a malicious dependency enters a build pipeline, the issue is not only code integrity. It becomes a question of who controlled ingestion, who could approve execution, and who had the ability to publish or revoke access. That makes this a governance problem as much as a technical one. Security teams often assume the pipeline itself is trustworthy until a package, script, or transitive library is abused to reach secrets, signing material, or deployment systems.

Good practice is to treat dependency intake as a controlled trust boundary. That means defining ownership for package policy, build permissions, and non-human credentials, then mapping those responsibilities to control requirements such as NIST SP 800-53 Rev 5 Security and Privacy Controls. If accountability is vague, investigation slows down and remediation becomes political rather than procedural. In practice, many security teams encounter the failure only after a signed artifact has already been built and distributed, rather than through intentional review of the dependency supply chain.

How It Works in Practice

Accountability should follow the points where trust is granted, not just where damage is discovered. In a mature CI/CD environment, this usually means three separate control domains: dependency policy, build execution, and release authorization. Engineering may own the pipeline code, platform teams may own the runner and secret store, and security may own guardrails, but the organization still needs a single decision path for exceptions and revocation.

Operationally, the most effective pattern is to make the build pipeline enforce policy before it can fetch or execute untrusted content. That includes dependency allowlists, provenance checks, signature validation, pinned versions, and restriction of scripts during install phases. Non-human credentials should be scoped to the minimum action required, rotated on a defined schedule, and traced to a named service owner rather than a team mailbox. If a malicious dependency is introduced, incident response should be able to answer which control failed: intake review, artifact verification, privileged token exposure, or a weaker publishing workflow.

• Define the control owner for dependency policy, build runners, and release signing separately.
• Require approval for new packages, especially where transitive dependencies can change trust assumptions.
• Protect build-time secrets so package install hooks and post-install scripts cannot reach them unnecessarily.
• Log provenance, version changes, and publish events so investigators can trace the introduction path.
• Test revocation procedures for compromised credentials and poisoned artifacts before an incident occurs.

For supply chain assurance, current guidance from CISA on software bills of materials and supply chain security supports better inventory and traceability, while OWASP Top 10 CI/CD Security Risks highlights the common places where pipeline trust is broken. These controls tend to break down when self-hosted runners share credentials across projects because one compromised job can inherit access intended for an entirely different build.

Common Variations and Edge Cases

Tighter dependency controls often increase delivery overhead, requiring organisations to balance release speed against verification depth. That tradeoff is real, especially in teams that ship frequently or depend on open-source ecosystems with rapid change.

There is no universal standard for exactly how much validation every build should perform. Current guidance suggests stronger checks for internet-facing systems, production signing paths, and pipelines that can access secrets or deployment credentials. Lower-risk internal builds may use lighter controls, but only if they cannot reach sensitive environments. In agentic or highly automated pipelines, the accountability question widens further because autonomous tooling may select dependencies, invoke build actions, or request approvals through an identity that is itself a non-human identity. That intersection is where NHI governance becomes material.

Edge cases also include monorepos, fork-based contribution models, and third-party build services. In those environments, the organisation may own the policy but not the execution substrate, so contractual controls and logging become important. SLSA is useful here as an implementation reference for provenance and build integrity, even though maturity varies by environment. The practical rule is simple: if a system can introduce dependencies, execute code, or publish artifacts, it needs an accountable owner and a documented revocation path.

Related resources from NHI Mgmt Group

• Who is accountable when an AI agent or build pipeline introduces malicious code?
• Who is accountable when malicious code enters through a package registry?
• Who is accountable when a malicious dependency exposes cloud and Kubernetes credentials?
• Who is accountable when a compromised pipeline publishes malicious packages?