Who is accountable when a supply chain compromise spreads through open source dependencies?

Accountability is shared. Maintainers must protect high impact accounts, registries need rapid incident response and strong authentication controls, and organisations must govern what they consume, pin, and deploy. Security teams should not treat upstream packages as fully trusted. They need explicit ownership for dependency hygiene, pipeline controls, and emergency response when a trusted package is poisoned.

Why This Matters for Security Teams

A supply chain compromise is not just a software problem. It is a governance problem, an identity problem, and a resilience problem at the same time. When a dependency is poisoned, the blast radius can extend into build systems, production environments, customer data, and automated delivery pipelines. Security teams often assume the risk sits with the upstream maintainer, but the organisation that chooses, pins, approves, and deploys the dependency also owns part of the outcome. That is why control design, provenance checks, and rapid containment matter as much as vulnerability scanning.

The practical issue is that many dependency flows include non-human identities, CI jobs, signing keys, package registry tokens, and deploy permissions that are rarely reviewed with the same discipline as user access. That aligns closely with the concerns raised in the OWASP Non-Human Identity Top 10, because compromised automation credentials can turn an upstream issue into an internal breach path. In practice, many security teams encounter the real accountability failure only after a poisoned package has already been pulled into production, rather than through intentional dependency governance.

How It Works in Practice

Accountability for an open source dependency compromise is distributed across the ecosystem, but the operational burden still lands on the consuming organisation. Maintainers are expected to protect release pipelines, keys, and publishing accounts. Registries and package hosts are expected to detect abuse, revoke malicious artefacts, and communicate quickly. Consumers are expected to control what enters the software bill of materials, validate provenance, and limit what build and runtime identities can do.

In practice, stronger outcomes usually depend on four controls working together:

• Pin versions and verify hashes or signed releases so builds do not silently drift.
• Separate build-time and runtime permissions so a compromised dependency cannot directly reach secrets or deploy rights.
• Use provenance checks, artefact signing, and internal allowlists to distinguish approved packages from opportunistic substitutions.
• Define incident playbooks for rapid dependency quarantine, rebuilds, and secret rotation when a package is suspected of poisoning.

This is also where AI-assisted automation changes the risk model. The latest incident reporting around autonomous abuse patterns shows that attackers can scale reconnaissance, credential abuse, and social engineering faster when automation is available, which is why the line between software supply chain security and identity governance is narrowing. The Anthropic report on the first AI-orchestrated cyber espionage campaign report is a useful reminder that machine-speed abuse can amplify a weak control point very quickly.

For control mapping, the most relevant baseline is strong asset, access, and recovery governance. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls provides the discipline needed for access restriction, configuration management, audit logging, and incident response. These controls tend to break down when organisations rely on unmanaged developer laptops, shared build credentials, or one-off exceptions for urgent releases because provenance and approval evidence become fragmented.

Common Variations and Edge Cases

Tighter dependency control often increases release friction and engineering overhead, requiring organisations to balance velocity against trust and traceability. That tradeoff is most visible in environments that depend on rapid patching, monorepos, or heavily automated CI/CD pipelines, where a strict allowlist can slow remediation while a loose model can let malicious packages through.

There is no universal standard for who is “most” accountable in every case. If the compromise originated in maintainer account takeover, upstream governance is central. If the organisation consumed the package without pinning versions, validating signatures, or monitoring non-human identities, internal accountability becomes dominant. If a registry failed to respond to a known malicious package, platform accountability also matters. Current guidance suggests treating accountability as shared, but assigning named owners for each control layer so gaps do not disappear into the middle.

Edge cases appear when organisations mirror public registries internally, vendor in open source into products, or allow agents and CI systems to fetch packages dynamically. In those environments, the real question is not only who caused the compromise, but who had authority to prevent, detect, or contain it. That is the accountability model security teams should document before the next incident, not after it.

Related resources from NHI Mgmt Group

• Who is accountable when a supply chain compromise spreads through trusted credentials?
• Who is accountable when a supply chain worm spreads through developer and CI environments?
• Who is accountable when supply chain compromise persists through automation workflows?
• How do teams contain a supply chain compromise before it spreads?