Who is accountable when a compromised pipeline publishes malicious packages?

Why This Matters for Security Teams

When a compromised pipeline publishes malicious packages, accountability does not stop at the developer who approved a build. It extends to the organisation that issued the publishing credential, defined the pipeline trust boundary, and allowed release authority to persist longer than necessary. That makes this a governance failure across identity, CI/CD, and software supply chain controls, not a single-actor error. The risk is amplified when secrets are embedded in build systems; NHIMG notes that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which turns pipeline access into a high-value path for attacker persistence.

Security teams often miss that package publication is an identity event as much as a software event. Once a compromised credential can sign, publish, or promote artifacts, the blast radius becomes downstream consumers, not just the pipeline itself. Guidance from the Ultimate Guide to NHIs — Why NHI Security Matters Now frames this as a lifecycle and governance problem, while supply chain incidents like the CI/CD pipeline exploitation case study show how quickly a single publishing path can become a distribution channel for malicious code. In practice, many security teams encounter this only after the package has already been pulled into production environments rather than through intentional release hardening.

How It Works in Practice

Accountability is usually assigned along the chain of control, not the chain of blame. The team that owns the pipeline platform is responsible for the trust boundary, the team that grants publishing rights is responsible for least privilege, and the product or release owner is responsible for approving the business use of that authority. When those duties are split, the key question becomes whether the organisation had controls that would have prevented a stolen token, overbroad role, or unattended secret from being used to publish a malicious package.

In practice, strong programs separate build, test, and publish permissions, require just-in-time release elevation, and use short-lived credentials rather than durable tokens. Package publication should be gated by workload identity, not human convenience. That means cryptographic proof of the pipeline workload, runtime policy checks, and revocation on completion. Current guidance suggests mapping these controls into Zero Trust Architecture principles and maintaining explicit ownership for non-human identities. The Guide to the Secret Sprawl Challenge is especially relevant here because package signing and publishing failures often begin with secrets that were never meant to live in the pipeline in the first place.

• Bind publishing rights to a dedicated service identity, not a shared human account.
• Issue time-bound credentials per release, then revoke them automatically after the job completes.
• Require approval and policy checks at publish time, not only at merge time.
• Log who owned the credential, who approved the release boundary, and who operated the platform.

Where this breaks down is in legacy CI/CD environments that reuse long-lived tokens across multiple repositories because the pipeline cannot yet enforce per-workload identity or per-release authorization.

Common Variations and Edge Cases

Tighter release controls often increase operational overhead, requiring organisations to balance speed of delivery against the cost of approval, attestation, and rotation. That tradeoff becomes visible in monorepos, multi-tenant build systems, and vendor-managed pipelines where the organisation may control the artifact but not every layer of the execution environment. In those cases, accountability is shared, but the owner of the publishing credential still carries primary responsibility for constraining its use.

There is no universal standard for this yet, especially where package registries, provenance signing, and automated promotion systems overlap. Best practice is evolving toward policy-as-code, workload identity, and evidence-based release authorization, but the exact split between platform, security, and product ownership differs by operating model. The LiteLLM PyPI package breach and the Shai Hulud npm malware campaign both underline the same pattern: once publishing trust is compromised, downstream users inherit the impact even if they never touched the original pipeline. This is why incident response should preserve evidence of credential issuance, approval paths, and revocation timing, not just package hashes.

For broader threat modelling, the Anthropic report on AI-orchestrated cyber espionage is a reminder that autonomous tooling can accelerate abuse once access is obtained, making containment speed part of accountability. In practice, the hardest cases are those where the pipeline is compromised through an inherited secret or delegated build role because the blast radius spans multiple teams and no single owner sees the full release path.

Related resources from NHI Mgmt Group

• Who is accountable when a compromised workflow publishes secrets or malicious changes?
• How can organisations reduce the blast radius of compromised agent identities?
• How should security teams think about a compromised integration like Drift?
• Who should be accountable when compromised npm packages spread through CI and developer systems?