generated from sigstore/sigstore-project-template
-
Notifications
You must be signed in to change notification settings - Fork 15
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
2 changed files
with
18 additions
and
2 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,16 @@ | ||
+++ | ||
title = "npm's Sigstore-powered provenance goes GA" | ||
author = "The Sigstore Technical Steering Committee" | ||
date = "2023-10-03" | ||
draft = false | ||
type = "post" | ||
tags = ["sigstore","npm","security","node"] | ||
+++ | ||
|
||
Last week saw the [GA release of npm CLI’s native Sigstore functionality](https://github.blog/changelog/2023-09-26-npm-provenance-general-availability/), a project [over a year in the making](https://www.wired.com/story/github-code-signing-sigstore/). This is a tremendous milestone for the adoption of Sigstore in open source projects and represents huge progress in effecting a cultural shift toward expecting provenance to exist for software components. It also helps move npm toward the best practices articulated by the OpenSSF's Securing Open Source Repos Working Group in their document ["Build Provenance for All Package Registries"](https://github.com/ossf/wg-securing-software-repos/blob/main/docs/build-provenance-for-all-package-registries.md). We're very pleased to see npm showing what registries can (and should) be doing to offer new capabilities that respond to emerging threats in software supply chain security. | ||
|
||
During the [public beta period](https://blog.sigstore.dev/npm-public-beta/) (which lasted from April 2023 until September 26), over 3,800 projects have adopted build provenance (including 134 high-impact projects), resulting in over 500 million total downloads of provenance-enabled package versions to-date. | ||
|
||
npm is the world’s largest package registry, handling tens of billions of downloads per month and around 40k publishing events each day. The decision to place [SLSA-compliant](https://slsa.dev/spec/v1.0/provenance) provenance-generation functionality into the CLI directly (as opposed to locating it in a CI job or external tool) represents bold leadership in the community of package management tooling. In essence, npm is saying that package maintainers ought to have access to first-class capabilities for producing authentic information about the source code and build instructions that produced their package. The effort to produce that functionality in npm resulted in the creation of two powerful new JavaScript libraries: the [sigstore-js](https://github.com/sigstore/sigstore-js) package which produces and verifies Sigstore signatures over artifacts and attestations, and [tuf-js](https://github.com/theupdateframework/tuf-js), which enables the npm CLI to use Sigstore’s TUF trust root to ensure secure communications with the public good instance. Both of these libraries have been donated to their respective organizations, ensuring that the work done by the npm team can have positive network effects in the future. | ||
|
||
We see npm’s work to integrate Sigstore as an exemplar for other package managers, which we codified into our roadmap as a [strategic priority](https://github.com/sigstore/community/blob/main/ROADMAP.md#focus-on-oss-package-managers-as-the-primary-path-for-sigstore-adoption-in-the-oss-ecosystems). The more ecosystems adopt signing and provenance, the more confidence the OSS community (and downstream dependers across OSS and proprietary source) will be able to have in the building blocks of open source. That’s an exciting future to be in, and one that we’re working toward every day. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters