Achieving Service Generated Provenance in Github Actions

[ChaosInTheCRD]

Hi SLSA Team!

I am currently becoming more involved with the development of the slsa-provenance-action Github Action that the Philips Lab team have been working on.

Specifically I am looking at integrating the ability to sign the generated provenance, before uploading it with https://github.com/sigstore/cosign/pkg/oci.

My question is regarding how one could meet the Service generated requirement inside the Provenance Process section. In an ideal world (e.g. with Tekton Chains or Google Cloud Build), the generation, signing and uploading of provenance would be taken out of your hands.

In the case of the slsa-provenance-action, the flow for signing and uploading the attestation (using cosign oci ) would look somewhat like:

• slsa-provenance generate container --repository 'xxxx' --tags 'latest, 1.0.0' --digest 'ajsdhadx' --auto-upload --key cosign.key
• Generates attestation in memory
• Signs attestation in memory
• Pushes attestation to image repository in memory

Given a flow like this, would the Service generated requirement be met? Or does it fail on the basis that it is not integrated tightly enough with the build service?

[dlorenc]

I don't think it's really possible to meet the "Service generated" requirement on GitHub actions today. The main goal is that the provenance would be protected against the compromise of a build step inside the release job itself, which requires that it be captured and generated from something in a separate "trust domain".

[ChaosInTheCRD]

Thank you for this clarity @dlorenc. I was wondering where the lines lie.

I am trying to consider how the Github Actions Contexts could be fetched by a process running out-with the release job, so it could build the provenance, sign it and push it with cosign separately... but I am not sure how closely knitted it would all need to be. Would it be sufficient if it received it via an API request coming from within the job itself? Or even if said external process could fetch the information directly from the Github API 🤷 - but in that case I am not sure how it would determine the build job id.

All just ideas and attempts to see how Github Actions could be more SLSA'ble 😊

[TomHennen]

@msuozzo was looking into something like that, Matt WDYT?

[msuozzo]

We had discussed systems like this from the beginning: Bolt-on provenance generators for builders with no native support. One example of this can be found in the recent demo repository we published where we hooked up the server to the GitHub Actions API (similar to that described by @ChaosInTheCRD).

The important thing is that the build system then conceptually grows to encompass this new system with all of the security implications that come with it. All identity, isolation, and key handling considerations must apply to both and the resulting SLSA level must reflect this evaluation.

[ribbybibby]

The important thing is that the build system then conceptually grows to encompass this new system

If an organisation moves from producing provenance as part of a build step to using an external system that monitors the CI, does the consumer of the artifact's trust in the provenance change at all if the organisation also manages that external system?

It seems to me that you'd still be trusting the developers to report their provenance faithfully.

[MarkLodato]

@ribbybibby I think you understand correctly. The intent is for there to be a small number of trusted "build systems", where the external monitor is included in the "build system".

Consider an organization that consumes software from N different providers, whether they are external or internal to the organization. By default, the org would need to trust all N different teams to faithfully and securely build their artifacts. By limiting the number of trusted builders to a small number, K, where K<<N, we can limit our trust base. So in the case of an external monitor, there would only be say a single external monitor for the K different build systems, rather than each of the N teams setting up their own monitor.

Does that help?

This needs to be better clarified in the spec.

[ribbybibby]

Does that help?

@MarkLodato It does, yep!

So you're saying that rather than every team that produces artifacts from Github Actions workflows running an external monitor in their own infrastructure, it would be preferable if there was one system (maybe some kind of public Github app?) that provided the service?

Obviously, it would be better if Github Actions offered service-generated provenance natively. I don't suppose anyone knows if that's something they're interested in or actively working on?

[MarkLodato]

So you're saying that rather than every team that produces artifacts from Github Actions workflows running an external monitor in their own infrastructure, it would be preferable if there was one system (maybe some kind of public Github app?) that provided the service?

Yup.

It might be the case that large companies prefer to run their own monitors instead of relying on a third-party one, but in that case it would probably one monitor for the whole company.

Obviously, it would be better if Github Actions offered service-generated provenance natively. I don't suppose anyone knows if that's something they're interested in or actively working on?

Agreed. We haven't reached out to them yet.