FYI there is a push to standardize this stuff under the name of SCITT in IETF [1]. In this case (blog post) this is different as NPM is using in-toto attestation [5] (a description of a thing) and logs it in Google's provided append only log (transparency service). They are trying to make this thing being adopted through a freemium model at the moment.
One issue here is that NIST are trying to push SBOMs [2] but NPM is not providing them as part of the provenance I think.
Another thing is a push to use new types of signature envelopes like DSSE [3] instead of something like COSE [4]
SBOM doesn't make sense at this level usually since the things being published lists constraints when installed locally and not locked/pinned versions. Some executables distributed on npm do provide lockfiles but those aren't SBOMs. You cannot really have an SBOM of something with unknown transitive dependencies. There are also disagreements on which SBOM would make sense here as multiple are in play.
> Some executables distributed on npm do provide lockfiles but those aren't SBOMs
Not entirely sure what this sentence means (some executables?), NPM generates lockfiles and, while lockfiles are not SPDX/CycloneDX equivalent, the overlap in intent and content is strong. SBOM makes just as much sense at this level as the existing lockfile generation mechanism.
SCITT is still nascent. Sigstore is operating and in use by multiple ecosystems. On the principle of "rough consensus and running code", SCITT is not the leader.
> and logs it in Google's provided append only log
This is false. The entire sigstore effort is under the OpenSSF and the production systems are operated by volunteers from multiple companies.
In order to publish a package with provenance, you must build your package with a supported cloud CI/CD provider. Today this includes GitHub Actions, and we are collaborating with additional providers to expand support.
I really hope that's not an empty statement. I enjoy some aspects of Github, but would hate to see it become the only trusted source for an entire language's ecosystem.
Shouldn't this be on the npmjs.com blog instead of GitHub? I know that both are owned by Microsoft, but why not use microsoft.com for everything then? Or let things at least appear separated from the outside.
Edit: Oh, realize now that npmjs.com doesn't even have it's own blog/news anymore, it's been absorbed by github.blog already and link on npmjs.com redirects there. Oh well, I'll leave my comment so you all can laugh about how wrong I was.
It's incredible how much of the software development space is owned by Microsoft now. I wonder if they will also buy JetBrains in the foreseeable future?
Great work! This provenance check is going to be very valuable for enforcing supply-chain security. We are working on adding support to check for provenance in Packj.
All haranguing over details aside, this is great news! I didn't know GitHub/npm was even working on this, and I'm glad to see a reasonable solution to a recognizable problem. Keep it up.
A more sane way for npm publish would be if the registry would just git checkout your repo during publish and strongly tie the package version to a commit hash.
Thus things without provenance become unusable and Microsoft builds on ownership of npm to exert absolute control over the javascript ecosystem. I reckon I can see how this ends.
The Root CA is generated by the sigstore community (five folks, two from academia). Right now github exchanges an OIDC token for a sigstore root chained cert.
GitLab are currently adding themselves, to have the same capability (several other providers are there as well).
Extinguish what exactly? Are people publishing packages to anywhere other than npm, and maybe GitHub? Microsoft already owns both of those, so there is nothing to extinguish.
It's not clear what you're worried about, and I'm skeptical you can articulate it, because it makes no sense.
And I say this as someone who is an extremely paranoid anti-corporate crusader, just like I imagine you are. But in this instance, your worry is misplaced.
- build on the record of supply chain compromises in npm to justify a provenance system
- establish yourself as one of the trusted authorities on establishing provenance
- spread fear and doubt about untrusted software
- become the trusted source and supplier of software
- open source becomes synonymous with untrusted software, basically malware
- in microsoft we trust
I think microsoft's land grab over open source software was pretty clearly established when they bought github and the general attitude of "they're nice now, it'll be fine" is going to be judged harshly in the future. Or I'm a paranoid crank with a misplaced mistrust of microsoft, who didn't declare "linux is a cancer" or anything like that.
I understand that line of thinking, but what land are they grabbing? They already possess all of it through npm and GitHub.
Do you think they intend to exclude caches like yarnpkg.com as insecure? I don't see how they would do that, since (1) your cache is a local config variable, not part of package.json, so there's no static analysis that could mark packages downloaded through Yarn as insecure, and (2) all of the key signature metadata is publicly available, so any cache or alternative package manager can implement the same provenance features as npm.
Or are you worried about EEE of the upstream source repositories and CI runners, eg "only packages built through GHA platform can contribute provenance data to npm registry?" I guess I could see that as a more reasonable fear, but as someone else explained to you, it's also unfounded (at least for now - which is maybe your argument), and GitLab is currently working on their own implementation. But even if they tried that, then you could still publish and consume packages from another registry if you wanted to. And I'd like to think that if Microsoft made a hostile move like that, we could count on package managers like yarn to pull provenance data from other sources.
Any code licensed under any of the popular OSS licenses are free to be hosted anywhere. If people want to mirror every package on NPM to a new registry, there's nothing Microsoft can do to stop them.
I hate to disappoint you, but it's actually really boring. The people who work on this stuff care about the security of NPM packages. That's the whole story.
One issue here is that NIST are trying to push SBOMs [2] but NPM is not providing them as part of the provenance I think.
Another thing is a push to use new types of signature envelopes like DSSE [3] instead of something like COSE [4]
[1] https://datatracker.ietf.org/group/scitt/about/
[2] https://www.nist.gov/itl/executive-order-14028-improving-nat...
[3] https://github.com/secure-systems-lab/dsse
[4] https://www.rfc-editor.org/rfc/rfc8152
[5] https://github.com/in-toto/attestation