Why we’re excited about the Sigstore general availability

Sigstore reaches a stable milestone

Sigstore has reached general availability, a significant step for the software supply chain security project. The announcement, made at SigstoreCon, marks the point where the project's components have all reached 1.0+ releases, the APIs have stabilized, and the public servers now operate under a formal service level objective with 24/7 on-call coverage. That operational maturity matters for any organization considering adopting the tooling for signing and verifying software artifacts.

The project's approach differs from traditional signing mechanisms in a way that lowers the barrier to entry. Rather than requiring teams to generate, store, and rotate private keys, Sigstore leverages OIDC tokens from cloud CI/CD providers like GitHub Actions. This enables keyless signing: the build process obtains a short-lived signing certificate without the need to manage a long-term secret. The model has already seen adoption in significant projects, including Kubernetes and CPython releases.

For teams using GitHub Actions, the practical path involves cosign. The tool handles container image signing with cosign sign, but cosign sign-blob extends the same capability to arbitrary build outputs. This means the keyless workflow can protect virtually any artifact produced in a CI pipeline.

GitHub has been directly involved in the project's development, contributing code and participating in the on-call rotation that keeps the public Sigstore infrastructure running.

Connecting npm packages back to their source

The general availability milestone also sets the stage for a more ambitious capability: verifiably linking npm packages to the source code and build instructions that produced them. Currently, when you examine an npm package, the available provenance information is limited. The package may include a link to a source repository, but that link is unverified and doesn't point to the specific commit that generated a given release.

The signing certificate issued during Sigstore's keyless signing process contains more than just a signature over the build output. It also encodes attributes pulled from the OIDC token, including the repository path, the specific commit that was built, and a link to the file containing the build steps. That certificate data is what enables the chain of verification.

Work remains before this capability is fully realized for npm users. The Sigstore libraries are continuing to gain support for this use case, and the project is collaborating with multiple cloud CI/CD providers to ensure OIDC tokens carry the required repository information regardless of which platform you build on. For the registry side, npm would cache the verification data from public Sigstore servers—an important consideration given the service handles billions of daily downloads—and surface it through the website, API, and CLI tools. End users would be able to confirm the data using Sigstore public keys or query the Sigstore servers directly.

This kind of verifiable provenance would be a meaningful improvement for vulnerability management and incident response, where quickly identifying which versions of a package are affected and tracing them back to their source can save considerable time during a security investigation.