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 pretty much just a late copy / paste of what sigstore has already done, save swapping out COSE for X509.
Re:NPM Provenance Public Beta
by jacques_chester on Thursday April 20, 2023 @09:08AM
(#35639357)
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.
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