11 ms·

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 attestatio

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] [1] https://datatracker.ietf.org/group/scitt/about/ https://datatracker.ietf.org/group/scitt/about/ [2] https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-security-supply-chains-software-1 https://www.nist.gov/itl/executive-order-14028-improving-nat... [3] https://github.com/secure-systems-lab/dsse https://github.com/secure-systems-lab/dsse [4] https://www.rfc-editor.org/rfc/rfc8152 https://www.rfc-editor.org/rfc/rfc8152 [5] https://github.com/in-toto/attestation https://github.com/in-toto/attestation

jacques_chester 3y ago
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.
bmeck 3y ago
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.
- lucideer 3y ago
  > 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.
deleted 3y ago
[deleted]
jobby23 3y ago
SCITT is pretty much just a late copy / paste of what sigstore has already done, save swapping out COSE for X509.

jacques_chester 3y ago

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.

bmeck 3y ago

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.

lucideer 3y ago
> 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.

deleted 3y ago

[deleted]

jobby23 3y ago

SCITT is pretty much just a late copy / paste of what sigstore has already done, save swapping out COSE for X509.