What breaks when a CI pipeline can publish packages with the same trust as a maintainer account?

The organisation loses the separation between source code approval and release authority. A compromised workflow can publish malicious artifacts while appearing legitimate, which means provenance checks alone are not enough. Teams need distinct identities, approval gates, and least-privilege publish rights for release automation.

Why This Matters for Security Teams

When a CI pipeline can publish packages with the same trust as a maintainer account, release automation stops being a helper and becomes a high-value identity. The problem is not just malware in the build system. It is that the pipeline can now exercise release authority, which collapses the separation between code review, artifact creation, and trusted distribution. That is exactly the failure pattern highlighted in CI/CD pipeline exploitation case study and in broader secret abuse research such as LLMjacking: How Attackers Hijack AI Using Compromised NHIs.

NIST guidance is clear that authentication, authorization, and system integrity should not be treated as one control boundary. See NIST SP 800-53 Rev 5 Security and Privacy Controls for the control families that underpin separation of duties, access enforcement, and auditability. In release engineering, that means a pipeline should prove what it is allowed to do, not inherit maintainer equivalence by convenience. In practice, many security teams discover the trust collapse only after a compromised workflow has already published a legitimate-looking malicious package.

How It Works in Practice

The safest pattern is to split the identity used to build from the identity used to publish. A CI workflow can compile, test, sign, and stage artifacts, but the final publish step should require a narrower, explicitly governed release identity. That identity should have only the minimum package-scoped permissions needed to publish a specific artifact family, and those permissions should be time-bound and revocable.

For mature teams, this usually means three layers of control:

• Workload identity for the pipeline itself, so the system proves what it is using cryptographic identity rather than a reusable secret.

• Just-in-time publish authorization, so the release action is approved at runtime rather than inherited from a long-lived maintainer token.

• Policy checks on the release event, so approval, branch provenance, change scope, and artifact metadata are evaluated together before publication.

This is where Reviewdog GitHub Action supply chain attack is useful as a cautionary example: once automation has access to secrets or publish credentials, a single compromised action can move from helper to distributor. Best practice is evolving toward policy-as-code enforcement at release time, using controls that resemble zero trust for software delivery rather than trust by repository membership alone. NIST SP 800-53 also supports this model through least privilege, separation of duties, and continuous monitoring.

These controls tend to break down in fast-moving package ecosystems where maintainer workflows, automated release bots, and human approvals all share the same token path because revocation and audit boundaries become blurred.

Common Variations and Edge Cases

Tighter publish controls often increase release friction, so organisations have to balance delivery speed against blast-radius reduction. That tradeoff becomes most visible in multi-package repositories, open-source maintainership, and high-frequency release pipelines where teams want unattended publishing.

There is no universal standard for this yet, but current guidance suggests the most defensible design is to treat publication as a separate trust domain from code contribution. A bot may be allowed to stage a release, but it should not be able to impersonate a maintainer across all repository operations. Likewise, provenance checks help confirm where an artifact came from, but they do not by themselves prove that the right authority approved the release.

Operational edge cases include emergency hotfixes, forks with distributed maintainership, and vendor ecosystems where package registries still rely on static API keys. In those environments, teams should prefer short-lived credentials, scoped registry permissions, and explicit human approval for privilege escalation. The goal is not to eliminate automation, but to make sure automation cannot silently inherit the same trust as a person with release accountability.

NHIMG’s research on Guide to the Secret Sprawl Challenge shows how quickly trust breaks down when credentials spread across systems faster than governance can contain them. Package publishing is the same problem, just with a more visible blast radius.

Related resources from NHI Mgmt Group

• What breaks when developer accounts can publish packages and expose credentials at the same time?
• Who is accountable when CI identities are abused to publish malicious packages
• What breaks when a CI/CD workflow can access secrets from untrusted pull requests?
• What breaks when malicious npm packages are allowed to run on developer endpoints?