Is it correct to say that the npm-generated provenance counts as SLSA v1 Build L2?

[trishankatdatadog]

Hopefully a quick, clarifying question:

Is it fair to say that, currently, the npm-generated provenance counts as SLSA v1 Build L2 since the predicate is entirely generated in userspace?

Cc @kommendorkapten

[kommendorkapten]

That seems reasonable.
What can be worth to consider is that the data that goes into the SLSA build provenance can be verified against the JWT from GitHub actions, which is signed by the control plane -- not in userspace. The most important claims in the JWT are lifted over by Fulcio as certificate extensions into the signing certificate returned.

But still, the SLSA provenance is generated and signed by keys available to the build job itself. At the registry we verify that the provenance matches the content in the X.509 certificate, which makes sure that the content of the provenance is vetted, and if there is a mismatch the publish is not accepted. After successful verification we create a publish attestation, which is a way to signal that the package and provenance was successfully authorized and verified by the registry.

[trishankatdatadog]

Got it, thanks for the clarification, Fredrik! This is very helpful. The thing I was most curious about is how the userspace generation of provenance itself should count in terms of levelling in the SLSA v1 Build Track, because others might adopt the same practical approach, and so this discussion might be helpful to them, too.

[joshuagl]

I think the npm generated provenance counts as SLSA Build L2 when generated on a hosted build platform which ensures the generated provenance is authentic.
Running npm publish --provenance from my laptop wouldn't count as SLSA Build L2, but AIUI from npm-publish(1) that's not even possible:

provenance

   •   Default: false

   •   Type: Boolean

   When publishing from a supported cloud CI/CD system, the package will
   be publicly linked to where it was built and published from.

   This config can not be used with: provenance-file

[trishankatdatadog]

Very helpful clarifications, thanks, especially when explaining why the provenance is designed for CI and not laptops.

[arewm]

I think that is supported by the specification as well.

At L2,

Accuracy: The provenance MUST be generated by the control plane (i.e. within the trust boundary identified in the provenance) and not by a tenant of the build platform (i.e. outside the trust boundary), except as noted below.

At L1, there are no requirements for accuracy as it just states

The build process MUST generate provenance that unambiguously identifies the output package by cryptographic digest and describes how that package was produced. The format MUST be acceptable to the package ecosystem and/or consumer.

[trishankatdatadog]

Hold on: now I'm confused.

I thought the npm CLI currently generates the unsigned payload in user/tenant space, but the signing is done by the control plane, right?

If so, what level is this provenance then? The OIDC identity of the GHA pipeline cannot be forged w/o breaking into the control plane, but the rest of the provenance is generated purely in user/tenant space.

[behnazh-w]

The control plane in this case provides the JWT token and makes is available to the untrusted build step that invokes npm sigstore as part of npm publish --provenance to generate and sign the provenance. So, the control plane itself does does not generate the provenance. Therefore, for a short period of time the token can be forged either by one maintainer of the package or if the build step is compromised by the untrusted build process. See the discussion here.

To consider npm provenances as Build L2, we should relax the requirement that the provenance is generated by the control plane and clarify that the npm provenance can be forged during the build, but cannot be forged after the build. See the discussion here and the conclusion here.

[kommendorkapten]

So, the control plane itself does does not generate the provenance.

While this is true, I would just like to point out that we do not put data into the provenance that can not be verified against the JWT (signed by the control plane). This is then verified by the registry (data in provenance MUST match what's in the JWT), if the data is equal the publish is allowed to happen, and in response the registry generates a "publish attestation", which can be seen as a VSA (content of provenance is verified).

[MarkLodato]

I think we should clarify this as part of #863.