The main failure is that CI improves repeatability but removes the human authentication check that many registries require for sensitive releases. If a token is stolen, reused, or over-scoped, an attacker can publish as the maintainer without a second factor. The result is faster compromise of the release process, not stronger control.
What breaks when publishing moves into CI without a second factor
Moving package release into CI removes the human check from the final publish step, so the control boundary shifts from a person approving a release to a token authorizing it automatically. That is fine only when the token is tightly scoped, short-lived, and well-governed. With a single-factor token, compromise of the credential becomes compromise of the publishing path itself.
The practical failure is not just “someone can log in.” It is that the pipeline now carries production release authority, so token theft, reuse, or over-privilege can turn build automation into a trusted publishing channel for malicious or tampered releases. In other words, the speed and repeatability of CI increase, but the release trust model becomes weaker unless the automation credential is treated as a high-value secret.
That is why this pattern belongs in the broader discipline of non-human identity governance and secret hygiene, not just pipeline convenience. A publish token that can sign or upload artifacts is functionally an identity with delegated authority, and its exposure path matters as much as the code it ships. NHIMG’s Ultimate Guide to NHIs on static vs dynamic secrets is a useful reference point here because long-lived credentials and weak rotation make automation tokens easier to steal and harder to contain.
Where the release control fails in practice
The broken assumption is that CI is merely a safer wrapper around the same release approval. It is not. If the registry accepts the token as sufficient proof, then the token becomes the sole gate for publishing, and the second-factor signal that often protects sensitive release actions disappears. Once that happens, any compromise of the CI environment, logs, dependency chain, or secrets store can be enough to issue a trusted release.
Single-factor automation tokens also create a wider blast radius when they are over-scoped. A token that can publish to multiple packages, environments, or registries can be replayed far beyond the intended build job, and an attacker does not need to defeat the code review process if they can simply impersonate the pipeline. That is why release automation should be treated as a privilege boundary, not just a deployment convenience.
For practitioners, the failure mode is easiest to see when the token is present in a long-lived secret store, visible to many jobs, or usable outside the exact publish step. In that case, CI is improving repeatability while quietly removing the assurance that a human or stronger auth event still stands behind a sensitive release.
Risk and Threat Considerations
Single-factor publish tokens concentrate release authority in a credential that is often reused, copied into pipelines, and left valid longer than the job that needs it. If that token is stolen or over-scoped, an attacker can publish malicious packages, overwrite trusted artifacts, or poison downstream consumers without breaking the build system itself.
Failure mechanism: the registry treats the automation token as sufficient proof, so a compromised secret becomes a direct path to trusted publishing. That creates a supply-chain style abuse path where the attacker needs access to the CI secret, not the maintainer’s interactive authentication flow.
Impact: malicious or tampered releases can be distributed as if they were legitimate, which increases the chance of downstream compromise, emergency revocation, and loss of trust in the package pipeline.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Publish tokens are non-human credentials that must be scoped, rotated and protected. |
| NHI-02 — Lifecycle and Rotation | CI tokens that stay valid too long widen compromise and replay risk. | |
| NHI-03 — Least Privilege and Access Governance | Over-scoped automation tokens let a stolen secret publish beyond its intended boundary. | |
| Recommendation — Limit publish tokens to the minimum package and job scope, and rotate them aggressively. Use short-lived tokens and revoke them immediately after the release job completes. Restrict publish tokens to the exact registry, package and action required. | ||
| CIS Controls v8 | 6.3 — Access Control Management | Release publishing depends on tightly controlling who or what can perform sensitive actions. |
| 6.8 — Audit Log Management | CI publish activity needs traceability to detect misuse of stolen automation tokens. | |
| Recommendation — Enforce least privilege for CI publish credentials and remove unnecessary release rights. Log token issuance, package publish events and privilege changes for review. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | Stolen or exposed automation tokens are a direct credential-access path to publishing abuse. |
| Recommendation — Hunt for exposed CI secrets and rotate any publish token found outside approved storage. | ||
| NIST CSF 2.0 | PR.AC-1 — Identity Management, Authentication, and Access Control | The publish flow depends on authenticating the automation identity with appropriate assurance. |
| PR.AC-4 — Access Permissions and Authorizations | Sensitive release actions need narrowly defined authorization boundaries. | |
| Recommendation — Bind release publishing to tightly governed credentials and access rules. Constrain CI publish permissions to the minimum required package and repository scope. | ||
Practitioner Guidance
What to verify: confirm that publish tokens are narrowly scoped to the exact package, repository, and environment, and that they expire quickly enough to be unusable outside the intended CI run. If the token can publish more than one target, treat that as a privilege design issue rather than a pipeline tuning problem.
Decision rule: if the registry release is sensitive enough that you would normally want a human second factor, do not substitute a long-lived shared token for that assurance. Use short-lived, tightly bound credentials and add an approval or attestation step for the highest-risk releases.
Common mistake: teams often secure the CI job but leave the publish credential itself too powerful. The pipeline may be reproducible, yet the release channel is still one secret away from compromise.
Practitioner takeaway: CI can automate publishing, but it should not silently lower the authentication standard for release authority, because the token becomes the control plane for trust in the package.
