Who is accountable when an attacker uses GitHub Actions and OIDC tokens to publish compromised packages?

Why This Matters for Security Teams

When GitHub Actions can mint OIDC tokens for package publishing, the real control boundary is no longer just the repository. Accountability extends to the teams that approve workflow changes, govern branch protection, and define which identities are trusted to exchange a token for release access. That matters because a compromised workflow can turn routine automation into an impersonation path for publishing malicious artifacts. The issue is not only code integrity, but also who had authority to let automation act on behalf of the project. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls is clear that access, approval, and change control need to be explicit when a system can reach protected resources.

Security teams often misread this as a supply chain provenance problem alone. In practice, provenance records can prove where a package came from, but they do not prevent a trusted workflow from being misused if permissions are too broad or approvals are weak. Repository owners, platform engineering, and release managers each hold a different part of the control chain, and accountability should follow those delegated responsibilities. In practice, many security teams encounter package compromise only after a trusted automation path has already been abused rather than through intentional release governance.

How It Works in Practice

GitHub Actions can authenticate to external services through OIDC, which avoids long-lived secrets but shifts trust to workflow conditions, token claims, and the identity policy of the target package registry. The practical question is not whether OIDC is secure in principle, but whether the repository and workflow rules make it hard for an attacker to alter a release job and obtain publish rights. MITRE’s MITRE ATT&CK Enterprise Matrix is useful for mapping the surrounding attack path, especially credential abuse, persistence, and execution through trusted tooling.

Accountability usually breaks down into three layers:

• Repository owners decide who can change workflows, tags, and release branches.
• Platform or DevOps teams define token audience, subject conditions, and permission scope for the OIDC trust relationship.
• Security and release governance teams verify that publishing requires the right approvals, not just successful automation.

Good practice is to require branch protection, review rules for workflow files, pinned action versions, short token lifetimes, and minimal package-scoped permissions. If the registry supports issuer and subject restrictions, those constraints should be tied to exact repositories, branches, and release environments. This becomes even more important where agents or automated release assistants can trigger builds, because identity governance must cover non-human actors as well as people. Where AI-assisted automation is involved, the trust chain should also be reviewed against current guidance from MITRE ATLAS adversarial AI threat matrix and the risks described in the Anthropic — first AI-orchestrated cyber espionage campaign report. These controls tend to break down when workflow edits, release approvals, and OIDC trust policy are managed by different teams without a single owner for the full publishing path.

Common Variations and Edge Cases

Tighter release controls often increase deployment friction, so organisations have to balance speed against the chance that a malicious workflow can publish compromised packages. There is no universal standard for this yet, but current guidance suggests that accountability should be assigned to the function that can actually prevent token issuance or release approval, not merely the team that detects the incident later.

Edge cases matter. In monorepos, one workflow may publish multiple packages, so a single weak approval path can affect several product teams. In federated organisations, a central platform group may own the OIDC policy while application teams own the workflow file, which means accountability is shared but should still be traceable by control domain. Temporary exceptions, such as emergency releases or fork-based contribution models, can also weaken assumptions if they are not time-bound and logged. For incident response, advisories from CISA cyber threat advisories remain useful for correlating package compromise with broader intrusion patterns. The practical takeaway is that provenance, signing, and OIDC are complementary, but none of them replace accountable workflow governance.

Related resources from NHI Mgmt Group

• Who is accountable when an attacker uses a legitimate Microsoft URL to steal tokens?
• Who is accountable when a compromised publish token is used to tamper with packages?
• What actions should I take if my OAuth tokens are compromised?
• How should security teams reduce risk from compromised GitHub Actions workflows?