-
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
BUILDKIT_SBOM_SCAN build args #3249
Conversation
@sudo-bmitch wdyt? Do we have good example cases? I guess most multi-stage builds with compilation stage except Go which embeds dependency data in final binary? |
That's the main use case I've seen. Having multiple SBOMs, and possibly merging them, looks like it will be a common use case. There will be the SBOMs for any upstream dependencies. Then an SBOM for the build environment (which could include previous stages of a multi-stage build), the output image (application + OS packages), and the runtime environment for SaaS solutions. |
The added test should show an example of how it's used. In a practical scenario I imagine a dockerfile author adding the ARG SBOM_SCAN_CONTEXT=true
FROM golang:latest AS builder
ARG SBOM_SCAN_STAGE=true
WORKDIR /src
COPY . .
RUN go build .
FROM scratch
COPY --from=builder /src/binary .
CMD ["/binary"] The end user can then manually adjust the exact parameters setting build args for |
Should we not prefix with |
65a8dbc
to
da3d30e
Compare
Have rebased, changed the prefix to include |
if err != nil { | ||
return nil, err | ||
} | ||
o := ds.Outline(dt) | ||
return &o, nil | ||
} | ||
|
||
type SBOMTargets struct { | ||
Core llb.State | ||
Extras map[string]llb.State |
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.
Is the name in this map retrievable from the final attestation (descriptor)?
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 by default this is the last part of the path component - I think we should probably document this, so that scanners can use this as the name in the SBOM.
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.
This doesn't seem to work for me, at least with the default scanner. I have defined args in Dockerfile but only get one sbom.
Signed-off-by: Justin Chadwell <me@jedevc.com>
Signed-off-by: Justin Chadwell <me@jedevc.com>
Ugh, GitHub actions hadn't run the CI, have fixed the issue, it should work now. It also looks like https://github.com/tonistiigi/buildkit/blob/5d5a6b93e09c466aece20f9835b07138a95660fe/cmd/buildctl/build.go#L281-L289 changed some critical behavior in buildctl, so that the |
This patch adds BUILDKIT_SBOM_SCAN_CONTEXT and BUILDKIT_SBOM_SCAN_STAGE which configure scanning the build context and stages respectively. To use these, the underlying Dockerfile must declare these args, and optionally assign a default value. BUILDKIT_SBOM_SCAN_CONTEXT must either be set in the global meta args before a FROM or in the target stage, while BUILDKIT_SBOM_SCAN_STAGE must be set in each target stage. The user can additionally override the values set in the Dockerfile to change the behavior. Signed-off-by: Justin Chadwell <me@jedevc.com>
Signed-off-by: Justin Chadwell <me@jedevc.com>
Doesn't this mean that attestations not generated in frontend do not run. The attestation parameters are sent with the inner solve that only returns inner result, not with the |
The previous behaviour passed all parameters to both the outer solve and the inner solve, so both the frontend and the solver have the chance to generate attestations. The provenance PR updated this to pass only the attestation parameters to the solver, so none of them ever reached the frontend. |
🛠️ Fixes #3185
⬆️ Follows up #2983
This patch adds
BUILDKIT_SBOM_SCAN_CONTEXT
andBUILDKIT_SBOM_SCAN_STAGE
which can configure scanning of the build context and intermediate dockerfile stages respectively.To use these, the underlying Dockerfile must declare these args, and optionally assign a default value.
BUILDKIT_SBOM_SCAN_CONTEXT
must either be set in the global meta args before a FROM or in the target stage, whileBUILDKIT_SBOM_SCAN_STAGE
must be set in each target stage.The user can additionally override the values set in the Dockerfile to change the behavior.