You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, when buildkit exports attestations, it exports them inline with the rest of the content:
For the image, oci and docker exporters, the attestations are exported using the attached attestation storage.
For the local and tar exporters, the attestations are exported to separate files within the output directory.
While this is most designed for use cases where the attestations are intended for publishing, using the results in CI/CD pipelines is more complicated. For these cases, a user will likely want to extract the attestations separately from the exported result.
For example:
A user wants to host the provenance and SBOM for the image in the GitHub releases page, but the consumable artifact is pushed separately to a container registry.
A user wants to automate generation of a report of the build, that includes details from the provenance (e.g. timings, github repositories, links to ci runs, etc), as well as details from the sbom (package versions of critical packages).
A user wants to create a pipeline that builds + pushes an image, and only conditionally deploys it, but only if no vulnerabilities are detected during the analysis of the outputted SBOM. This should be possible independent of whether the final output artifact contains the SBOM attestation.
A user wants to manually export the attestation results to a third-party software component, maybe for more advanced analysis and integration.
Ideally, BuildKit should support generating these attestations separately from the main output, to enable these use cases. A couple of implementation possibilities:
Use Enable multiple exporters #2760, and create (or modify) a dedicated attestations exporter that only exports all the attestations. Using Introduce new attestation exporter options #3403, the user can then precisely configure which attestations end up where, and can create a pipeline to easily get the attestations separately.
One issue with the above is that attestations vary between exporters (e.g. the subject of a local attestation is the list of all files in the export, while in an image attestation it's the digest of the platform manifest). We should be able to get the exact same attestation that is exported.
Return the generated attestations in the exporter response (mostly likely not directly, but we could use the new build history api to write the attestations to the content store and then allow the client to read them using a returned descriptor).
Currently, when buildkit exports attestations, it exports them inline with the rest of the content:
image,ocianddockerexporters, the attestations are exported using the attached attestation storage.localandtarexporters, the attestations are exported to separate files within the output directory.While this is most designed for use cases where the attestations are intended for publishing, using the results in CI/CD pipelines is more complicated. For these cases, a user will likely want to extract the attestations separately from the exported result.
For example:
Ideally, BuildKit should support generating these attestations separately from the main output, to enable these use cases. A couple of implementation possibilities:
attestationsexporter that only exports all the attestations. Using Introduce newattestationexporter options #3403, the user can then precisely configure which attestations end up where, and can create a pipeline to easily get the attestations separately.One issue with the above is that attestations vary between exporters (e.g. the subject of a local attestation is the list of all files in the export, while in an image attestation it's the digest of the platform manifest). We should be able to get the exact same attestation that is exported.