Beyond Classic Tokens: Securing Your Software Supply Chain with NPM Staged Publishing

For years, the standard operating procedure for automating NPM package publishing was deceptively simple: generate a granular access token (or worse, a legacy read-write token), bury it deep within your CI/CD secrets, and hope it never leaks. While functional, this 'set it and forget it' approach has become a significant liability in the modern threat landscape.

With software supply chain attacks rising by an estimated 742% over the last few years, the pipeline between your code repository and the package registry is now a primary battleground. Attackers aren't just looking for vulnerabilities in your code; they are looking for the keys to the factory floor.

At Nohatek, we believe that security should enable velocity, not hinder it. In this guide, we explore the shift away from static credentials toward OpenID Connect (OIDC) and NPM Staged Publishing with provenance. We will discuss how CTOs and developers can modernize their pipelines to ensure that the code you build is exactly the code your users install.

The Hidden Risks of Classic Automation Tokens

Classic NPM automation tokens have long been the backbone of CI/CD pipelines, but they possess inherent architectural flaws that make them unsuitable for high-security environments. The primary issue is that they are static secrets. Once generated, they exist indefinitely until manually revoked or rotated.

This static nature creates several critical risks:

• Credential Sprawl: Tokens are often copied across multiple environments, developer machines, and third-party tools, increasing the attack surface.
• Rotation Friction: Because rotating tokens requires manual intervention across pipelines, teams often delay rotation, leaving stale credentials active for months or years.
• Lack of Provenance: A classic token authorizes who is publishing, but it verifies nothing about where or how the package was built. If a token is stolen, an attacker can publish malicious code from their local machine that looks indistinguishable from a legitimate build.

Security is not just about keeping intruders out; it is about verifying the authenticity of what you let out into the world.

To mitigate these risks, the industry is moving toward short-lived, identity-based authentication methods that tie the publishing process directly to the build environment.

Embracing OIDC and NPM Provenance

The solution to the static token problem lies in OpenID Connect (OIDC). Instead of storing a secret token in your CI/CD provider (like GitHub Actions or GitLab CI), your pipeline exchanges a short-lived identity token with the NPM registry. This token is valid only for the duration of the specific job.

When you combine OIDC with NPM Provenance, you achieve a higher standard of supply chain security. Provenance generates a verifiable attestation—signed by a non-falsifiable source (like Sigstore)—linking the package directly to the source code repository and the specific build instructions.

Here is why this matters for your tech strategy:

• Traceability: Consumers of your package can verify exactly which commit and workflow run produced the artifact.
• Tamper Resistance: Because the identity is tied to the CI environment, it becomes incredibly difficult for an attacker to inject malicious code without compromising the source repository itself.
• Reduced Management Overhead: No more managing long-lived secrets. The trust is established between the identity provider (CI) and the service provider (NPM).

Practical Implementation: Configuring the Pipeline

Adapting your pipeline for this modern workflow requires a shift in configuration. Below is a practical example of how to configure a GitHub Actions workflow to utilize OIDC for publishing with provenance. This assumes you have already configured the necessary trust settings in your NPM package settings.

First, ensure your workflow has the correct permissions:

permissions:
  contents: read
  id-token: write  # Required for OIDC authentication

Next, update your publishing step. Notice that we are no longer using a stored NPM_TOKEN secret for authentication in the traditional sense. Instead, we use the provenance flag:

- name: Publish to NPM
  run: npm publish --provenance --access public
  env:
    NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }} # Still used, but scoped differently with OIDC setup

Note: While a token is still passed for backward compatibility in some setups, the --provenance flag triggers the generation of the signed attestation using the OIDC identity.

For a truly secure staged rollout, consider implementing a dry-run verification step before the actual publish:

- name: Dry Run Publish
  run: npm publish --dry-run

By validating the manifest and packing process before the actual upload, you ensure that the artifact structure meets your standards before it is immutably signed and released to the registry.

The Executive View: Why Supply Chain Security is a Business Asset

For CTOs and decision-makers, moving beyond classic tokens is not just a technical upgrade—it is a strategic asset. In an era where trust is the currency of the cloud ecosystem, being able to prove the integrity of your software gives you a competitive edge.

Adopting OIDC and staged publishing aligns with major compliance frameworks (such as SLSA - Supply-chain Levels for Software Artifacts) and prepares your organization for stricter regulatory requirements regarding software transparency.

Furthermore, this approach improves Developer Experience (DX). By removing the friction of manual secret management and key rotation, your DevOps teams can focus on optimizing build performance and feature delivery rather than playing janitor to expired credentials. It reduces the "bus factor" risk associated with specific engineers holding the keys to the deployment kingdom.

The era of static, long-lived secrets is drawing to a close. As we build more complex, interconnected systems, verifying the identity of our automation is just as critical as verifying the identity of our users. By adopting OIDC and NPM provenance, you aren't just patching a vulnerability; you are future-proofing your development lifecycle.

At Nohatek, we specialize in helping organizations navigate the complexities of modern cloud infrastructure, AI integration, and secure DevOps. If you are looking to audit your software supply chain or modernize your CI/CD pipelines, our team is ready to help you build with confidence.