Question about build level for the generic provenance generators in SLSA v1.0

[behnazh-w]

According to SLSA v1.0, Build L3: Hardened builds

Provides strong confidence that the package was built from the official source and build process.

Based on this statement, my question is whether the provenances generated by the generic generators should be considered Build L2 moving forward because they sign a given artifact and do not check if it is built from any approved build process. On the other hand, if a provenance is generated by a trusted builder or BYOB builder, it can be considered Build L3.

Also, it would be great if the SLSA verifier can report the build level of a provenance based on the generator.

[laurentsimon]

Thanks @behnazh-w , this is a great question!

For context, the generic generator was released when the SLSA version was v0.2 and had 2 tracks: Build track and verification track. We claimed level 3 for provenance, but made no claim for the build track. As you point out, v1.0 specs got rid of the provenance track and only has the build track.

We have a tracking issue #1868 to make the generator level 3 for the build track, which, until you posted this issue, I interpreted mostly as having stronger isolation, e.g. ephemeral VMs.

Back to your original question. What levels should the generic generator has. In terms of isolation, it ticks all the boxes assuming #1868 is resolved. In terms of was built from the official source and build process, then it's not clear to me to what extent this guarantee should hold.

Let's take some examples:

• GitHub workflows: users can clone any repo, so we can't guarantee it (that's why you're asking if it should be labelled L2)
• GCB: GCB clones the repo on behalf of users (based on webhook info). But the build script could be doing anything, e.g. download a binary without building from source code
• BYOB: similar to GCB, BYOB clones the repo on behalf of users
• Go Builder in this repo: this builder goes one step further: it does not run any user-provided script. It runs the go compiler itself. It also restricts which arguments to the Go compiler (including env variables) the user is allowed to pass, giving high guarantees that the repo code is actually used for compilation.

I don't know what the definition of "source" is in the specs: does it encompass the workflow files? I don't see why not, since it's a (GitHub specific) build config. But I see that there are some nuances in guarantees for the builders above, and it may be useful to be able to capture them.
So maybe there's a need to differentiate between "trigger source repo", "cloned source repo" and "built source repo"? (and maybe have these be part of some SLSA levels / requirements?)

So my honest answer to your question is that I don't know the exact intent of the specs is :)

/cc @kpk47 @MarkLodato @joshuagl @mlieberman85 have been active on the specs and may have some insights

For the second part of your question about levels in slsa-verifier. We've been willing to make progress on this slsa-framework/slsa-verifier#84, but have been hesitant to decide ourselves what the levels should be. At the end of the day, trust is in the eye of the user. The conformance program (I think slsa-framework/slsa#515) aims at providing some visibility into builder implementation and guarantees, via a text-based questionnaire. Based on the questionnaire, I could imagine the SLSA WG provides "their view" on the levels, and we'd implement it in the slsa-verifier. We'd additionally provide a config files for users to overwrite these defaults. I recall @kpk47 making some progress on it, but I don't recall the exact status. EDIT: slsa-framework/slsa-proposals#9 and https://github.com/slsa-framework/slsa-proposals/blob/main/0005/README.md Furthermore, the SLSA specification makes it the verifier's responsibility to determine whether a build system is trustworthy, and that trustworthiness determines Build L3 conformance. Looks like the level is something you, as a user, will define. So slsa-verifier may need to make a call and be very clear what the default levels are while allowing overwrite?

[behnazh-w]

Thanks @laurentsimon for the thorough response. Looks like the spec requires to be more specific about was built from the official source and build process for Build L3. This is an important problem for consumer tools like Macaron too that attempt to help users decide on a build level. I need to think some more about it. Looking forward to clarifications from others.

[laurentsimon]

What do you think of creating an issue on https://github.com/slsa-framework/slsa for broader visibility?

[behnazh-w]

@laurentsimon My conclusion of the discussion at slsa-framework/slsa#926 is that the current generic and BYOB generators can be classified as Build L3 and the requirements/benefits in the Build L3 spec are going to be adjusted, removing "official source" from:

• Provides strong confidence that the package was built from the official source and build process.

and breaking it into:

• Provides strong confidence in the accuracy [correctness? trustworthiness?] of the package's provenance.
• With verification, prevents building from unofficial or unexpected build inputs.

Now, one major benefit if Build L3 is protection against insider threats. This brings me to this question about GitHub Actions OIDC tokens that the current generators rely on: what prevents me as a project maintainer to exfiltrate the $ACTIONS_ID_TOKEN_REQUEST_TOKEN and $ACTIONS_ID_TOKEN_REQUEST_URL environment variables and grabbing the JWT token from a fork in the 10 minute buffer that the Fulcio certificate is valid? Am I missing something? Or is it possible to forge a provenance in this case?

[laurentsimon]

Now, one major benefit if Build L3 is protection against insider threats. This brings me to this question about GitHub Actions OIDC tokens that the current generators rely on: what prevents me as a project maintainer to exfiltrate the $ACTIONS_ID_TOKEN_REQUEST_TOKEN and $ACTIONS_ID_TOKEN_REQUEST_URL environment variables and grabbing the JWT token from a fork in the 10 minute buffer that the Fulcio certificate is valid? Am I missing something? Or is it possible to forge a provenance in this case?

You can grab the JWT but the identity will be your repository's identity, not the SLSA generator's. During verification, it will fail because we expect the generator / builder to sign the attestation, not the project itself.

Does this answer the question?

[behnazh-w]

Yes, it does thanks. The OIDC token would identify both the caller workflow and the called reusable workflow through job_workflow_ref (executing the provenance generator). And a project maintainer cannot exfiltrate the token produced for the reusable workflow job at the main repo.

How about the provenances generated by npm CLI? As far as I understand, there is no requirement to call it from a reusable workflow. Can a project maintainer grab the JWT and forge a provenance from a fork?

[laurentsimon]

How about the provenances generated by npm CLI? As far as I understand, there is no requirement to call it from a reusable workflow. Can a project maintainer grab the JWT and forge a provenance from a fork?

yes that's possible. It also means npm dependencies (especially those with install scripts) can grab the tokens and sign arbitrary packages. The builders / generators (reusable workflows) provide that additional level of security.

[arewm]

This has been mentioned elsewhere, but the SLSA specification does not pertain to any guarantees about what is in the code repositories themselves. Some diligence will be required by producers to ensure that any dependencies (or modifications to the code) are reasonable/reliable especially when it comes to their ability to arbitrarily sign packages.

The threat of arbitrary package signing can be mitigated by a build platform by controlling/restricting the network access available to builds themselves in a potential future SLSA level. This may not be a level with the build track as it isn't necessarily related to ensuring an accurate provenance is present but I tried to summarize this point in an ongoing discussion on slsa-framework/slsa#230.