Who is accountable when a forged open-source release is published to a package registry and container registry?

Why This Matters for Security Teams

Forged releases are not just a software integrity problem. They create a direct accountability gap between the people who publish artefacts and the teams that trust them in production. When a package registry or container registry accepts a malicious or impersonated release, the issue usually traces back to weak release governance, overbroad automation tokens, or missing provenance validation. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls is clear that controlled change, least privilege, and integrity checks are core defensive expectations, not optional extras.

The practical mistake is treating registry publication as a purely operational event. In reality, it is a trust decision that can affect downstream deployments, SBOM accuracy, vulnerability triage, and incident response scope. If release identity is not bound to a verified workflow, a compromised maintainer account or stolen CI token can make a forged artefact look legitimate long enough to be pulled into build and runtime environments. In practice, many security teams encounter this only after a malicious package has already been mirrored, cached, or deployed, rather than through intentional provenance review.

How It Works in Practice

Accountability should be assigned to the roles that control each trust boundary. Maintainers and release owners are accountable for workflow design, tag protection, signing, and token scope. Platform or DevSecOps teams are accountable for registry policy, provenance enforcement, and preventing unsigned or unverified artefacts from being promoted. Security and risk owners are accountable for setting the minimum acceptance standard for consumption.

Operationally, a mature release path usually includes:

• Protected branches, protected tags, and release approvals that cannot be bypassed by automation alone.
• Short-lived credentials or scoped workload identity rather than long-lived secrets in CI/CD.
• Artifact signing and verification before package publication and again before deployment.
• Provenance metadata, such as attestations, tied to the exact commit, build environment, and workflow run.
• Registry policy that rejects untrusted sources, orphaned tags, and unsigned images or packages.

For software supply chain governance, the best public reference point is the NIST Secure Software Development Framework, which reinforces that release integrity is part of secure development, not an afterthought. The same logic extends to container registries: if the image is not traceable to a known build and a trusted signer, downstream teams are accepting unbounded risk when they deploy it. This is especially important where software attestation or internal approval gates are used to prove build provenance.

These controls tend to break down when a project uses shared CI runners, inherited secrets, or manual hotfix publishing because the chain of custody becomes ambiguous and no single team can prove who authorised the artefact.

Common Variations and Edge Cases

Tighter release control often increases delivery overhead, requiring organisations to balance speed against the cost of stronger verification. That tradeoff is real, especially for open-source projects with many contributors, emergency releases, or multi-registry publication pipelines.

There is no universal standard for assigning legal accountability across all ecosystems, but current guidance suggests separating operational responsibility from assurance responsibility. For example, a maintainer may own the release workflow, while a platform team owns registry policy, and a consuming enterprise owns the decision to trust the artefact. If a forged release is published because a tag was overwritten or a token was reused, the immediate root cause may sit with the release owner, but the blast radius often reflects missing checks in downstream intake. MITRE guidance on adversary techniques relevant to supply chain compromise can help teams model how such abuse occurs, and the OWASP supply chain and application security guidance is useful for structuring internal reviews even when the issue is not AI-related.

Special cases include upstream maintainer compromise, delegated package ownership, and emergency security releases. In those situations, best practice is evolving toward explicit provenance attestation and rapid revocation playbooks. The key question is not only who published the artefact, but who had the authority to let an untrusted artefact reach consumers. Where that authority is diffuse, accountability becomes fragmented and post-incident review turns into guesswork rather than evidence.

Related resources from NHI Mgmt Group

• Who is accountable when a trusted open-source package is used to deliver malware?
• Who is accountable when a developer workstation is infected through a compromised open source package?
• Who is accountable when a maintainer account is hijacked and a poisoned package is published to a public registry?
• Who is accountable when malicious code enters through a package registry?