Who is accountable when a release workflow publishes malicious code through trusted publishing?

Why This Matters for Security Teams

trusted publishing changes the failure mode of release security: the code may be signed by a workflow identity that looks legitimate, even when the workflow itself has been altered or the build inputs were poisoned. That makes accountability broader than the person who merged the pull request. Repository owners, release engineers, and platform teams all share responsibility for the branch protections, workflow permissions, and provenance checks that decide whether malicious code can move from source to release.

This is not a theoretical edge case. NHI Mgmt Group research shows that only 5.7% of organisations have full visibility into their service accounts, and identity blind spots in CI/CD are a recurring cause of exposure. When release automation is trusted by default, attackers do not need to defeat every control, only the identity path that publishes artefacts. See GitHub Action tj-actions Supply Chain Attack and the control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls for the governance baseline. In practice, many security teams encounter release abuse only after a trusted workflow has already published a compromised artefact, rather than through intentional control testing.

How It Works in Practice

Accountability should follow control authority, not just code authorship. If a malicious release was published through trusted publishing, the immediate questions are: who owned the workflow, who could approve changes to it, who could alter branch protections, and who monitored the execution environment. Those are different roles, and each one has a distinct security duty.

Operationally, the cleanest model is to separate source approval from release authority. Repository owners govern merge rules and workflow definitions. Release engineers manage the release pipeline, signing steps, and provenance generation. Platform or identity teams control the underlying OIDC trust policy, short-lived credentials, and environment protections that allow the workflow to obtain publish rights. Current guidance suggests treating the workflow identity as a privileged non-human identity, with auditability equivalent to other production secrets and service accounts. The control set in Ultimate Guide to NHIs is useful here because the same lifecycle problems appear in CI/CD: overbroad access, weak visibility, and delayed revocation.

• Restrict who can edit release workflows and who can approve those edits.
• Require short-lived, per-run credentials for publishing instead of static tokens.
• Log workflow identity, commit SHA, environment, and approver for every release.
• Verify provenance and signature status before the artefact is promoted downstream.
• Review branch protection and environment protection as part of release governance.

For control mapping, NIST expects organisations to enforce least privilege, audit events, and separation of duties across sensitive workflows. The practical translation is that no single developer should be able to change a publish job, approve it, and release it without independent review. These controls tend to break down when self-hosted runners, shared automation accounts, or loosely governed reusable workflows collapse ownership into a single operational team.

Common Variations and Edge Cases

Tighter release governance often increases delivery friction, requiring organisations to balance release speed against the risk of a trusted path being abused. That tradeoff is especially visible when teams use reusable workflows, third-party actions, or delegated release signing.

There is no universal standard for this yet, but current guidance suggests the following distinctions. If malicious code enters through a compromised maintainer account, the repository owner and code reviewers are accountable for approval safeguards. If the workflow definition itself is modified, the release engineering function becomes central because it owns the pipeline logic. If a trusted publishing token, OIDC trust policy, or environment secret is mis-scoped, the platform or identity team shares accountability because it owns the credential boundary. For broader supply-chain scenarios, compare the attack patterns described in Reviewdog GitHub Action supply chain attack with the control emphasis in NIST SP 800-53 Rev 5 Security and Privacy Controls.

Edge cases also matter. In multi-repo orgs, accountability can split between central platform teams and product teams unless ownership is explicitly documented. In regulated environments, the release publisher may be a vendor-operated automation account, which does not remove accountability from the enterprise that authorised it. The practical rule is simple: whoever can change the trust relationship, the workflow, or the publish credential must be able to explain how malicious code would be stopped before release.

Related resources from NHI Mgmt Group

• Who is accountable when a trusted maintainer identity is hijacked and malicious code is published?
• Who is accountable when malicious code enters through a package registry?
• Who is accountable when a GitHub Actions workflow exposes secrets or pushes malicious code?
• Who is accountable when a compromised workflow publishes secrets or malicious changes?