OIDC Publishing Pipeline

An OIDC publishing pipeline is a software release workflow that uses OpenID Connect tokens to authenticate automated package publication without long-lived secrets. In supply chain attacks, a stolen or hijacked OIDC flow can let an attacker publish a malicious package while appearing to use legitimate infrastructure.

Expanded Definition

An OIDC publishing pipeline is not just “CI/CD with login.” It is a release path where build automation receives short-lived OpenID Connect assertions from an identity provider and exchanges them for publish-time authorization, typically to sign, upload, or promote packages without storing long-lived secrets. In NHI security, the term matters because the identity being trusted is the pipeline workload itself, not a human operator.

Definitions vary across vendors on where the trust boundary begins. Some teams treat the OIDC token as the credential; others treat it as an attestation that must be exchanged for a tightly scoped publishing grant. The operational distinction is important: OIDC reduces secret persistence, but it does not eliminate the need for issuer validation, audience restriction, job isolation, and workflow provenance checks. OpenID Connect is the relevant standard reference here, while implementation guidance often follows broader control ideas from the NIST Cybersecurity Framework 2.0.

The most common misapplication is treating any successful OIDC login as proof that the package publish is safe, which occurs when teams skip branch protection, token audience binding, or workflow pinning.

Examples and Use Cases

Implementing OIDC publishing rigorously often introduces tighter pipeline controls and more brittle release engineering, requiring organisations to weigh secret elimination against build complexity and token-validation overhead.

• A maintainer-free release job exchanges an OIDC token for a one-time package publish grant after a signed tag is verified.
• A container registry accepts publishing only from a specific workflow identity, preventing ad hoc CI jobs from pushing artifacts.
• A GitHub Actions release pipeline uses short-lived federation instead of stored API keys, reducing exposure if the runner is compromised. See the Reviewdog GitHub Action supply chain attack for why secretless design matters.
• A dependency publisher separates build and release stages so the OIDC token is issued only after test and provenance checks complete.
• A security team compares issuer and audience claims against expected values before allowing publication, aligning the workflow with OpenID Connect and the CI/CD pipeline exploitation case study.

Why It Matters in NHI Security

OIDC publishing pipelines reduce the need for static credentials, but they also create a high-value path where a compromised workflow can impersonate legitimate automation. That makes token scope, identity federation, and workload provenance core NHI controls, not optional hardening. The security benefit is strongest when the pipeline identity is short-lived, narrowly scoped, and bound to a trusted workload context.

NHIMG research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which explains why many teams move to OIDC-based publishing in the first place. The same research also shows 92% of organisations expose NHIs to third parties, a reminder that publishing pipelines often sit at the intersection of external integrations and release authority. The best-known failure mode is not credential theft alone, but attacker use of a legitimate pipeline path to publish malicious artifacts under trusted infrastructure. Related incident analysis in the Shai Hulud npm malware campaign and the OneLogin API Key Vulnerability both show how quickly identity trust can be converted into supply chain abuse. Organisations typically encounter the consequence only after a malicious package is already published, at which point OIDC publishing pipeline controls become operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What breaks when a long-lived npm token is left active after adopting OIDC publishing?
• Policy publishing pipeline
• OIDC Trusted Publishing
• What is OpenID Connect (OIDC) and how does it extend OAuth 2.0 for NHIs?