imagetools inspect: handle provenance and sboms

[crazy-max]

Supports provenance and sbom for imagetools inspect command.

$ docker buildx imagetools inspect crazymax/buildkit:attest --format "{{json .}}"

https://gist.github.com/crazy-max/5bbc2e60c58263a0162bbf3b920d3d09

[crazy-max]

@jedevc Yes we should use in follow-up the go-imageinspect library.

[jedevc]

Is there a way we can support multiple SBOMs? e.g. in the case of a dockerfile where multiple stages have been scanned, we should have a way to get multiple.

Maybe .SBOM for the "first" SBOM, and .SBOMS[idx] for others?

Side note: the issue with ordering here is that the "most relevant" SBOM is currently not guaranteed to be first (though I think I have a solution for fixing that buildkit-side).

[jedevc]

Aside from the above, LGTM 🎉

[tonistiigi]

Could we just show the raw SLSA in here. Just json.RawMessage.

[tonistiigi]

The SBOM part seems ok but I don't think we should invent another temporary provenance type atm.

[tonistiigi]

If we possibly want to add our own typed structs for SBOM/Provenance in the future then maybe it is better if we leave the names of the raw structs as SPDX and SLSA atm.

[tonistiigi]

Did some testing with https://github.com/docker/buildx/compare/master...tonistiigi:buildx:inspect-provenance?expand=1 branch. Mostly seems to work with raw values but commands are really slow(when blobs are being pulled I believe). Maybe this can be optimized or should show debug logs. Especially because some of the SBOM values can be really big they should only be pulled when user really asks for the data.

[tonistiigi]

If we possibly want to add our own typed structs for SBOM/Provenance in the future then maybe it is better if we leave the names of the raw structs as SPDX and SLSA atm.

wdyt @crazy-max @jedevc

[crazy-max]

If we possibly want to add our own typed structs for SBOM/Provenance in the future then maybe it is better if we leave the names of the raw structs as SPDX and SLSA atm.

Not sure about the SLSA terminology here. It can be VSA or Provenance atm so I think Provenance still makes sense. Maybe SLSAProvenance? And for SBOM we could have SBOMSPDX?

[jedevc]

The merged name combination seems odd to me - maybe we could go with {{ .SBOM.SPDX }} and {{ .Provenance.SLSA }}? Those can be the raw data structures, leaving us open in the future to additional formats such as {{ .SBOM.CycloneDX }}, as well as utility fields for our own typed structs in the future, e.g. {{ .SBOM.Packages[0].Name }}.

[tonistiigi]

maybe we could go with {{ .SBOM.SPDX }} and {{ .Provenance.SLSA }}?

I'm not sure if it is possible to have {{ .SBOM.SPDX }} be the spdx and {{ .SBOM }} itself a clear package list later without all the spdx garbage. If this is possible then lgtm. Otherwise SBOMSPDX seems fine to me as well. Although that would also mess up {{ json . }}. I think what we really need is just a custom format handling for these special keys (eg like atm there some commands have --format table). Content is only loaded when the format is exactly the key. In {{ json . }} there would be no SBOM fields.

[tonistiigi]

I merged this in but if we still want to make changes to naming we still can before the GA.