-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SBOM attestations generation #2983
Conversation
1455aa5
to
4299dff
Compare
To test locally, you can use $ docker buildx create --driver docker-container --name sbom-builder --driver-opt image=justinchadwell050/buildkit:sbom-attestations
$ docker buildx build --driver sbom-builder --build-arg BUILDKIT_SYNTAX=justinchadwell050/dockerfile:sbom-attestations ... |
f875447
to
852605e
Compare
852605e
to
bae87d2
Compare
The one major remaining thing still missing from this is the ability to bundle attestations internally, which will allow the sbom scanning protocol to output sboms in different formats, which will be picked up by the exporter. |
bae87d2
to
8c2b6cc
Compare
1478cda
to
0933e00
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at my local branch, this PR used to have some dockerfile tests. Did something get deleted?
0933e00
to
73eec4a
Compare
73eec4a
to
116dcb7
Compare
Have pushed functionality to do attestation bundling to let a generator produce multiple outputs per input. This requires a new version of jedevc/buildkit-syft-scanner. |
8ec70ae
to
ca059d0
Compare
Have enhanced the scanning protocol to clarify how multiple refs are scanned at a time. A scan has one "primary" ref to scan (the runtime rootfs), but may contain multiple "extra" refs which could be used in the future to attach SBOMs of build contexts or of previous build stages. Otherwise, I'm reasonably happy with the state of this, though we'd need a follow-up to introduce documentation for creating custom scanners. |
4bdb500
to
bb144fc
Compare
Have rebased, should be ready to review/merge. I did draft a new commit to maybe pull on top of this: d4ced27 (with the corresponding change jedevc/buildkit-syft-scanner@e6fa1e1). This would change the structure of the bundle fairly significantly - but the idea would be that instead of having an |
return nil, err | ||
} | ||
|
||
att, st, err := scanner(ctx, p.ID, st, nil) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wdyt of controlling the extras here with defining ARG SBOM_SCAN_STAGE=true
and global ARG SBOM_SCAN_CONTEXT=true
(in addition to allowing it to be set in attestation attrs).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So a stage that wants to be a scan point has a command for that ARG
? That sounds ok, but I think it would be good to expose some level of control to the user somehow.
Maybe:
mode=min
= scan only the final stage, regardless ofARG
smode=max
= scan the final stage, and also all the scan points (that are declared on theARG
s), maybe with a warning if no additional scan points have been point?
I'm not sure, what we would do if a user overrode those ARG
s using build --arg
? I think the user's choice is taken into account and we override the values in the Dockerfile
.
Let's do this in a follow-up ↪️
bb144fc
to
4d674fb
Compare
Signed-off-by: Justin Chadwell <me@jedevc.com>
Additionally, propogate attestations through to the buildkit server when using client.Build. Signed-off-by: Justin Chadwell <me@jedevc.com>
An attestation bundle is a directory containing attestations. It uses the same Ref and Path properites as an InToto Attestation, but looks up the files inside the Ref+Path to process as raw InToto statements. This allows flexibility for generating more complex combinations of attestations, where all the details may not be known ahead of time, and unlazying the reference is not desired. Signed-off-by: Justin Chadwell <me@jedevc.com>
Signed-off-by: Justin Chadwell <me@jedevc.com>
These can be added by calls to Solve to modify the result before exporting it. These can add additional metadata, insert new references, or create new attestations, essentially any way that the caller wants to modify the result. Signed-off-by: Justin Chadwell <me@jedevc.com>
This adds a new processor to pass to Solve that converts a result's unit Ref output to a simple Refs map type, which is required to be able to add attestations at this point. All metadata is appropriately converted, so that the new result should have the same semantics as the old one. Signed-off-by: Justin Chadwell <me@jedevc.com>
This adds functionality to perform an SBOM scan if the frontend did not produce a valid SBOM. Signed-off-by: Justin Chadwell <me@jedevc.com>
This includes both a dockerfile test to test the builtin dockerfile scanner, as well as a more complex client test to test the interaction between frontends and the fallback scanner. Signed-off-by: Justin Chadwell <me@jedevc.com>
d783e8c
to
3d45d9e
Compare
Follow up to #2935, and part 2 of #2773 (comment).
This PR adds support for scanning the resulting image to easily generate SBOMs. For example, using my example scanner at jedevc/buildkit-syft-scanner:
$ buildctl ... build --frontend=dockerfile.v0 --output type=image,name=<image>,push=true --opt attest=sbom=jedevc/buildkit-syft-scanner:latest
This generates SPDX attestations according to the In Toto SPDX attestation.
The
jedevc/buildkit-syft-scanner
image follows a simple scanning protocol:BUILDKIT_SCAN_SOURCE
, and output an SPDX document toBUILDKIT_SCAN_DESTINATION
.The details of this protocol will likely change, however, we need to ensure that anyone interested in producing an SBOM scanner can easily create an image to slot into the build process. Ideally, we'd also be able to provide a default, however, we should do this as a later follow-up, once the overall design is stabilized.
The scanner is integrated into the dockerfile frontend natively, and, if a frontend does not produce an SBOM when specified, the solver will fallback to this same scanner.
Still to-do:
--attest
flag for buildx, however, how this option is passed to buildkit (part of the frontend attributes, or part of the exporter attributes) is up for debate.Note to reviewers: this PR shares many commits with #2935, see the comparison here to see only commits that are different.