Who is accountable when a trusted build pipeline is used to deploy malware?

Why This Matters for Security Teams

A trusted build pipeline is not just a delivery mechanism. It is a privileged execution environment with access to source code, signing material, deployment targets, and often long-lived secrets. When malware is introduced through that path, the issue is not only malicious code, but also failed control ownership across engineering, security, and governance. The operational question becomes who approved the trust boundary and who monitored it. NHI Mgmt Group notes that 97% of NHIs carry excessive privileges, which helps explain why pipeline compromise so often turns into broad environment access rather than a single isolated defect; see the Ultimate Guide to NHIs. Security teams also need to understand how this maps to control intent in the NIST SP 800-53 Rev. 5 Security and Privacy Controls and the CIS Controls v8. In practice, many organisations discover ownership gaps only after a release pipeline has already been abused to push malicious artifacts.

How It Works in Practice

Accountability in this scenario should follow the controls that made execution possible, not just the team that built the software. Platform engineering usually owns runner hardening, workflow configuration, token scope, and environment isolation. Application owners are typically accountable for the code path, dependency integrity, release intent, and approval logic. Security governance is accountable for defining the minimum control baseline, reviewing exceptions, and ensuring incident response can trace actions back to identities and systems. A practical accountability model usually includes:

• Ownership of build runners, agents, and ephemeral infrastructure
• Control of secrets, tokens, certificates, and signing keys
• Approval of workflow changes and deployment permissions
• Logging for audit trails, provenance, and rollback decisions
• Incident escalation paths for suspected tampering

This is where the NHI perspective matters. Build systems often rely on service accounts, API keys, and machine credentials that behave like high-trust identities. NHI Mgmt Group’s CI/CD pipeline exploitation case study and Shai Hulud npm malware campaign show how quickly those identities become the real target. Current guidance suggests treating pipeline identities as privileged non-human identities, with scoped access, short-lived credentials, and strong provenance checks. That maps well to NIST control families for access enforcement, auditability, and configuration management, especially where release tooling can modify production or sign artifacts. These controls tend to break down when legacy shared runners, static secrets, and weak separation between build and deploy are all present in the same environment.

Common Variations and Edge Cases

Tighter pipeline control often increases delivery friction, requiring organisations to balance release speed against assurance and traceability. That tradeoff becomes sharper in shared DevOps platforms, outsourced build services, and multi-tenant CI environments, where the security team may not own every component but still bears governance responsibility. There is no universal standard for this yet, but best practice is evolving toward explicit trust zones, immutable build logs, and policy-as-code for release approvals. A common edge case is the “trusted” pipeline that is technically secure but operationally over-permissioned. For example, a workflow may be allowed to read secrets it does not need, or a runner may retain permissions long after a job ends. Another edge case is delegated deployment, where application teams can trigger releases but platform teams control the underlying identity and infrastructure. In that model, accountability is shared, but it must still be assigned in writing. The incident response lesson is simple: if the build pipeline can mint trust, then someone must own that trust end to end. The Guide to the Secret Sprawl Challenge is relevant here because secret placement often determines whether a compromise stays contained or becomes a full environment breach. In high-change environments with unmanaged service accounts or poor secret hygiene, accountability frameworks often fail because no single team can prove which identity actually executed the malicious step.

Related resources from NHI Mgmt Group

• How should security teams govern API keys used for generative AI access?
• Who is accountable when a hijacked subdomain is used for phishing or malware?
• Who is accountable when a stolen credential is used to deploy workloads in cloud environments?
• Who is accountable when a trusted cloud identity is used for business email compromise?