Table of contents
Generating provenance statements
Table of contents
You can generate provenance statements for the packages you publish. This allows you to publicly establish where a package was built and who published a package, which can increase supply-chain security for your packages.
About npm provenance
npm provenance includes two types of attestations:
- Provenance attestation
- Publish attestation
The provenance attestation is established by publicly providing a link to a package's source code and build instructions from the build environment. This allows developers to verify where and how your package was built before they download it.
Publish attestations are generated by the registry when a package is published by an authorized user. When an npm package is published with provenance, it is signed by Sigstore public good servers and logged in a public transparency ledger, where users can view this information.
About Sigstore
Sigstore is a collection of tools and services aimed at making it easy to use short-lived, ephemeral certificates to sign software. Its three main components are a CLI tool, a certificate authority, and a time-stamping transparency log.
The certificate authority federates with any OIDC provider that includes verifiable build information. It acts as an intermediary between build systems and package registries by verifying the integrity of the OIDC token, issues a signing certificate that contains that build information, and then logging the signing certificate to an immutable ledger.
The transparency log service provides a public, verifiable, tamper-evident ledger of signed attestations. This ensures transparency of the public service, as well as providing a way to detect attempts to tamper with a package if a package registry were to be compromised.
Provenance limitations
- To publish a package with provenance, you must build your package with a supported cloud CI/CD provider using a cloud-hosted runner. Today this includes GitHub Actions and GitLab CI/CD.
- When a package in the npm registry has established provenance, it does not guarantee the package has no malicious code. Instead, npm provenance provides a verifiable link to the package's source code and build instructions, which developers can then audit and determine whether to trust it or not. For more information, see "Searching for and choosing packages to download."
Prerequisites
Before you can publish your packages with provenance, you must:
-
Review the Linux Foundation Immutable Record notice, which applies to the public transparency log.
-
Install the latest version of the npm CLI (ensure you are on
9.5.0+
as older versions don't support npm provenance). For more information, see "Try the latest stable version of npm." -
Ensure your
package.json
is configured with a publicrepository
that matches (case-sensitive) where you are publishing with provenance from. -
Set up automation with a supported CI/CD provider to publish your packages to the npm registry. The following providers are supported:
- GitHub Actions. For more information, see "Publishing packages with provenance via GitHub Actions."
- GitLab CI/CD. For more information, see "Publishing packages with provenance via GitLab CI/CD."
Publishing packages with provenance via GitHub Actions
In order to establish provenance, you must use a supported cloud CI/CD provider and a cloud-hosted runner to publish your packages. GitHub Actions is a supported CI/CD platform that allows you to automate software development tasks. For more information, see GitHub Actions in the GitHub documentation.
To update your GitHub Actions workflow to publish your packages with provenance, you must:
-
Give permission to mint an ID-token:
permissions:id-token: write -
Run on a GitHub-hosted runner:
runs-on: ubuntu-latest -
Add the
--provenance
flag to your publish command:npm publish --provenance -
If you are publishing a package for the first time you will also need to explicitly set access to public:
npm publish --provenance --access public
Example GitHub Actions workflow
This example workflow publishes a package to the npm registry with provenance.
name: Publish Package to npmjson:release:types: [published]jobs:build:runs-on: ubuntu-latestpermissions:contents: readid-token: writesteps:- uses: actions/checkout@v4- uses: actions/setup-node@v4with:node-version: '20.x'registry-url: 'https://registry.npmjs.org'- run: npm ci- run: npm publish --provenance --access publicenv:NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
Using third-party package publishing tools
If you publish your packages with tools that do not directly invoke the npm publish
command, you can do one of the following in your GitHub Actions workflow to publish your packages with provenance.
-
Configure environment variables: In your GitHub Actions workflow, you can use an environment variable called
NPM_CONFIG_PROVENANCE
, and set it totrue
. -
Configure your
package.json
file: You can add apublishConfig
block to yourpackage.json
file:"publishConfig": {"provenance": true}, -
Add an
.npmrc
file: You can add an.npmrc
file to your project with the following entry:provenance=true
Note: At this time, yarn
is not a supported tool for publishing your packages with provenance.
Publishing packages with provenance via GitLab CI/CD
In order to establish provenance, you must use a supported cloud CI/CD provider and a cloud-hosted runner to publish your packages. GitLab CI/CD is a supported CI/CD platform that allows you to automate software development tasks. For more information, see Generating provenance in GitLab CI/CD in the GitLab documentation.
Example GitLab CI job
This example job publishes a package to the npm registry with provenance when a git tag is pushed. Don't forget to define the NPM_TOKEN
variable in your GitLab project settings.
publish:image: 'node:20'rules:- if: $CI_COMMIT_TAGid_tokens:SIGSTORE_ID_TOKEN:aud: sigstorescript:- npm config set //registry.npmjs.org/:_authToken "$NPM_TOKEN"- npm publish --provenance --access public
Verifying provenance attestations
You can verify the provenance attestations of downloaded packages with the following audit
command:
npm audit signatures
Example response showing the count of verified registry signatures and verified attestations for all of the packages in a project:
audited 1267 packages in 6s1267 packages have verified registry signatures74 packages have verified attestations
Because provenance attestations are such a new feature, security features may be added to (or changed in) the attestation format over time. To ensure that you're always able to verify attestation signatures check that you're running the latest version of the npm CLI. Please note this often means updating npm beyond the version that ships with Node.js.