Who is accountable for supply chain risk when maintainers and security teams share responsibility?

Why Shared Responsibility Creates a Security Ownership Gap

When maintainers and security teams both touch the software supply chain, the main risk is not that nobody cares. It is that accountability becomes blurry at the exact point where dependency trust, provenance, and release approval need a single owner. Security teams can define controls, but maintainers usually execute them inside the build and release workflow. That division is common in modern software, and it is why supply chain incidents often move faster than governance.

Current guidance from the OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 is consistent on one point: the party that ships the software must own the risk decisions, even if implementation is shared. That owner has to decide which dependencies are allowed, what evidence is required for release, and who can override a failed control. NHI Management Group’s 52 NHI breaches Report shows how quickly identity and trust failures spread once release processes are unclear. In practice, many security teams only discover this gap after a malicious package, compromised token, or poisoned pipeline has already been promoted into production.

How Accountability Should Work in the Build and Release Path

Accountability works best when it is assigned to the software owner, but distributed across specific operational tasks. Maintainers should own the mechanics of dependency review, build integrity, and release approval. Security teams should own policy, detection, exception review, and escalation. That split only functions when every control has a named decision-maker and a clear evidence trail.

A practical model is to define three layers of responsibility:

• Maintainability layer: maintainers approve dependency changes, pin versions, review provenance, and block untrusted packages before merge.

• Security layer: security teams define policy for allowed registries, signature checks, secret scanning, and artifact validation using controls from NIST SP 800-53 Rev 5 Security and Privacy Controls.

• Release layer: the product or platform owner accepts residual risk, especially when a control fails but a release is still being considered.

This matters because supply chain attacks often target the gap between code review and deployment. NHI Management Group’s Reviewdog GitHub Action supply chain attack is a good example of how workflow trust can be abused even when the repository appears controlled. The right operating model uses signed provenance, short-lived credentials, explicit approval gates, and a documented exception path. It should also specify which team can revoke trust in a package, runner, or token without waiting for a committee. These controls tend to break down in fast-moving CI/CD environments where multiple teams can merge, publish, and deploy from the same pipeline because no single owner can make a release stop decision.

Where Shared Responsibility Usually Breaks Down

Tighter supply chain governance often increases workflow overhead, requiring organisations to balance release speed against control depth. The tradeoff is real: if every dependency or artifact requires manual review, delivery slows; if approval is too loose, the organisation inherits unowned risk.

Best practice is evolving toward evidence-based accountability rather than vague shared ownership. That means defining who signs off on provenance, who owns dependency exceptions, and who is accountable when a maintainer cannot act quickly enough. It also means security teams should not be treated as the final owner of a bad release unless they actually controlled the release decision. The software owner remains accountable, even if operational duties are shared. That distinction matters in open source, platform engineering, and internal developer platforms where many contributors touch the pipeline but only one organisation benefits from shipping the software.

Edge cases include volunteer maintainers, federated projects, and outsourced build operations. In those environments, current guidance suggests using written service agreements, explicit trust boundaries, and automated controls that do not depend on one person being available. The clearest lesson is that accountability cannot be shared in the abstract; it must be assigned at the point where code becomes a releasable artifact, which is why incidents like the Shai Hulud npm malware campaign are so damaging when ownership is unclear.

Related resources from NHI Mgmt Group

• How do security teams know whether token restrictions are actually reducing supply chain risk?
• How should security teams reduce supply chain risk from compromised package maintainers?
• How should security teams reduce the risk of secret theft from npm supply chain attacks?
• How should security teams reduce supply chain risk in GitHub-based development pipelines?