[discussion] SLSA workflows as templates

[behnazh-w]

Is your feature request related to a problem? Please describe.
Let's assume that workflows in an organization are not allowed to reach out to any third-party workflows, e.g., SLSA Reusable Workflow (SRW) builders based on their policies. How can such organizations be supported to get benefit from the workflows in this repository?

Describe the solution you'd like
We could host the SRW inside the organization by using the slsa-github-generator repo as a template repo. One concern would however be maintenance overhead as the downstream repo maintainers would need to keep their repo in in sync with the upstream repo.

[ianlewis]

If we did something like this, I assume the copied reusable workflow repository would need to be self contained, right? All the references it makes would need to be internal and wouldn't be able to call out to slsa-framework repositories in any way?

[behnazh-w]

I assume the copied reusable workflow repository would need to be self contained, right?

Yes, that's correct.

All the references it makes would need to be internal and wouldn't be able to call out to slsa-framework repositories in any way?

Correct.

[mlieberman85]

How would an outside observer know that they are in fact using the SRW and not claiming to use it? This is related to the builder service conversation as well.

For example Github actions hosted by Github the company can be certified to be secure and assuming your organization trusts Github we can then look at the actions and workflows.

In the context of open source the reusable workflows we can look at SLSA/OpenSSF and people can decide whether or not they trust

If someone pulls in those reusable workflows into their own org it might work within their org but if they distribute artifacts and attestations outside their org, the consumer would either need to audit against the org's fork of the reusable workflow or just trust that org.

[laurentsimon]

If someone pulls in those reusable workflows into their own org it might work within their org but if they distribute artifacts and attestations outside their org, the consumer would either need to audit against the org's fork of the reusable workflow or just trust that org.

+1. In this case the builder ID would be the org's reusable workflow path, and consumers would have to trust this org. If the code is just mirrored, this could maybe work since the code would be identical? I have not thought enough about it yet to know whether some configuration would be needed, etc

[mlieberman85]

Even with mirroring, at that point is it really any different than just using the upstream workflow?

FWIW, I've lived through the pain of needing approvals to use some upstream tool but pulling the code directly in for some reason circumvents that process for not always great reasons. I don't want to get on a soapbox but I do understand that by pulling the code internally it allows the organization to scan, lint, review, and control the code a bit better. However, in cases like an open source external reusable workflow it shouldn't matter because the code can be linted and reviewed from the upstream repo.

[behnazh-w]

Thanks @mlieberman85. Thinking about it some more, you're right that verification of artifacts outside the org would not be straightforward. Even if we could consider maintaining a trust list in slsa-verifier, the trusted SRWs would have to be recertified with every change, which is impractical. I don't think it's a good idea to take the generators out of TCB.

So, using this repo as a template would only be useful for artifacts consumed inside the org. I guess it would be good however if the workflows can be self contained to make this option possible anyway.

[laurentsimon]

I came across a repo that forked this repo https://github.com/albasystems/slsa-provenance-generator and uses it to generate provenance for https://github.com/albasystems/hello-slsa.