buildkit
buildkit copied to clipboard
moby
SLSA 1.0 Spec support
Just a heads up SLSA 1.0 is currently out as a release candidate and will be going live in probably end of March 2023.
Would buildkit be interested in supporting the new spec? I can't help with the code right now but can help walk folks through the spec.
@tompizmor no activity recently on this. If anyone's interested, we'd be happy to take a PR to do this.
Also, x-linking this to https://github.com/moby/buildkit/pull/4269 (this is related to upgrading to in-toto v1).
@jedevc I can possibly take this on. A few things I'm wondering on this one..
- Keep version .02 support?
- In terms of slsa for containers - https://cloud.google.com/build/docs/securing-builds/generate-validate-build-provenance#example_output is a decent example for v1 slsa. However, this doesn't have as much detail... but it's more inline with what I see in the slsa spec.
- Expanding on the last point.. Some data doesn't map as well into slsa predicate - purge this data?
- The provenance data for a local exporter is not the same as remote. Is that intentional? Seems all local files are included with their digests.
- I think local exports should be supported. In particular I'd like to export the provenance data, sign it, and upload it to a different data store.
- Should support for signing be added? If so, hooking into sigstore libraries may be viable.
Few of those points can probably be later additions.
@Forrin thanks for your interest!
- Keep version .02 support?
No strong opinions on this one - personally, I don't see a reason to just update to v1.0, I'm happy with that.
- In terms of slsa for containers - cloud.google.com/build/docs/securing-builds/generate-validate-build-provenance#example_output is a decent example for v1 slsa. However, this doesn't have as much detail... but it's more inline with what I see in the slsa spec.
- Expanding on the last point.. Some data doesn't map as well into slsa predicate - purge this data?
Yeahhhh, this is tricky - I think if we're upgrading we can reshuffle fields around, etc. But we shouldn't decrease the level of detail. If we do that, we're losing info, and then this would just be a net downgrade.
Do you have an example of some of the data that doesn't fit in neatly? Even if it doesn't fit into a field directly, SLSA still supports custom fields, and we can use those.
- The provenance data for a local exporter is not the same as remote. Is that intentional? Seems all local files are included with their digests.
- I think local exports should be supported. In particular I'd like to export the provenance data, sign it, and upload it to a different data store.
Each exporter produces different output formats. The remote exporter is producing a container image (where we have image manfests etc), while the local exporter is essentially just the filesystem at the root of the filesystem.
These outputs are different - so yes, they have to have different subjects in the attestation. There is the oci exporter, which exports a container to a local image store - the attestation subjects are more similar to the remote one in this case.
- Should support for signing be added? If so, hooking into sigstore libraries may be viable.
This feels like one of the later additions, I guess it's dependent on 1.0 support in the first place? Or maybe it's orthogonal.
That said, totally a fan of this, I like the sound of that approach - I would happily support and follow along with any work in this direction.
If you have any questions around SLSA v1 I'm happy to help. I'm a maintainer of SLSA.
Definitely go over https://github.com/slsa-framework/slsa/issues/716 with our initial issues with 1.0 (the issue is still open). The bottom line is that we don't want to lose any existing functionality or data that can be useful for evaluating the quality of the build.
Hey folks! I am part of the Rancher Security team. We're looking into using BuildKit across our ecosystem for baking in provenance into our container images. So I am more than happy to help or tag team on this if needed.
The bottom line is that we don't want to lose any existing functionality or data that can be useful for evaluating the quality of the build.
Currently provenance has two modes: min and max. Would the maintainers accept the creation of a new mode to represent a strict slsa-v1? That way both min/max could be kept in line with existing, while users would still have a way to opt-in to the slsa-v1 spec if they so wished - due to hard requirements they may need to abide by.
Alternatively, would it be acceptable to make the provenance generation extensible (like the SBOM scanning protocol) so users can bring their own?
