Images should Include Signatures/SBOMS/Attestations

[runyontr]

Is your feature request related to a problem? Please describe. As a system owner, I would like to obtain all artifacts for an image produced by IronBank and other image vendors.

Describe the solution you'd like

As an end user, when an image is included as part of the Zarf.yaml, I would like the associated objects to be included in the Zarf bundle:

$ cosign tree registry1.dso.mil/ironbank/redhat/ubi/ubi8:8.5
📦 Supply Chain Security Related artifacts for an image: registry1.dso.mil/ironbank/redhat/ubi/ubi8:8.5
└── 💾 Attestations for an image tag: registry1.dso.mil/ironbank/redhat/ubi/ubi8:sha256-20cc7b5f918a4b545093e84f8d514d18734577e4eac74acedec2e6285976150a.att
   └── 🍒 sha256:c4825a56acbe4b241e34ad741bece768cf6f6dd9665a7a5e6747189df9c08b23
└── 🔐 Signatures for an image tag: registry1.dso.mil/ironbank/redhat/ubi/ubi8:sha256-20cc7b5f918a4b545093e84f8d514d18734577e4eac74acedec2e6285976150a.sig
   └── 🍒 sha256:7d5ed1fe5df8e5fb32c35ab9c0c8b09a5cd30f20683acc73e67a4d7dfbb4e884
└── 📦 SBOMs for an image tag: registry1.dso.mil/ironbank/redhat/ubi/ubi8:sha256-20cc7b5f918a4b545093e84f8d514d18734577e4eac74acedec2e6285976150a.sbom

Currently they provide vulnerability information in the attestation as can be seen here:

cosign download attestation registry1.dso.mil/ironbank/redhat/ubi/ubi8:8.5 | jq -r .payload | base64 --decode | jq .

Describe alternatives you've considered The Zarf.yaml could define each one of these objects individually, which seems time consuming, but very explicit about which version of the image should be downloaded.

Additional context IronBank is currently providing SBOM, signatures and justification, but as they expand the metadata around the image they could/may provide it would be good to dynamically bring more of the data with in Zarf without explicit reference changes.

https://github.com/sigstore/cosign/blob/main/cmd/cosign/cli/tree.go

[jeff-mccoy]

This is interesting, one thing I'm noticing though, tree doesnt seem to tell you if the artifacts really exist, just what their url would be if they did--so some downloads will result in error if just following the tree command. That's not super ideal to be generating a bunch of 404s on remote registries. Any thoughts on how to optimize that?

[jeff-mccoy]

Bump on this one re: the last question @runyontr

[runyontr]

Doesn't look like there's a more efficient way then just trying to download each artifact and if its not there, just skipping adding it to the Zarf bundle

[bburky]

Not sure how the cosign commands work internally. But you can discover Cosign signatures/attestations/attachments by inspecting your image path (to get it's sha256 digest) and then listing tags. If there is a tag named sha256-... those are all cosign artifacts that reference the image's digest.

It's two Docker v2 API requests total, one to inspect the tag/manifest and one to list tags.

[jeff-mccoy]

Update: would like this to check for these components and include in-lieu of doing syft when available.

[mjnagel]

Looks like the issue with showing all possible components was resolved in cosign - https://github.com/sigstore/cosign/pull/1872

Running cosign tree on images now only returns existing signature/sbom/attestation.

[mjnagel]

Going to unassign myself and drop a few notes from follow on todos to fully close this issue. With the merged PR cosign artifacts should be fully supported and discoverable with find-images.

Two pieces are not complete that would be part of this issue or follow on ones:

• Identify when an sbom artifact is included and skip over syft creation of SBOM
• Mutating digests as needed - in order for tools to identify the signature the tag for it must be tagged <digest>.sig. When zarf does its AddImageAnnotation this could change the image digest if that annotation was not already present, making it so that the signature is no longer at the expected tag

[bburky]

Another TODO and a question:

• https://github.com/defenseunicorns/zarf/pull/2027 added support for zarf prepare find-images adding cosign .sig images to the images: section in zarf.yaml (example below) This does not pin podinfo to a specific digest, is it possible for an image's tags to be changed and no longer point to the resolved signature. Tags are mutable, and in the case of Iron Bank they may frequently change.

  example:
  https://github.com/defenseunicorns/zarf/blob/7801b7c400042240fcdc78ea4c06afd2fc3202c8/examples/helm-charts/zarf.yaml#L15-L18

  If possible, it would be nice if this step also mutated ghcr.io/stefanprodan/podinfo:6.4.0 into ghcr.io/stefanprodan/podinfo:6.4.0@sha256:57a654ace69ec02ba8973093b6a786faa15640575fbf0dbb603db55aca2ccec8. This would prevent the tag from changing after running find-images. (However, I'm not quite sure if zarf supports digests in images:, including the image:tag@digest syntax. Zarf's image push behavior could be modified to support pushing image:tag@digest as image:tag to the zarf registry with a guarantee of the specific digest.)

• Is there any plan to verify the cosign signatures during zarf package create?

[Racer159]

To better scope this issue - changing the title to verify cosign signatures during package create - SHAs (and SHA + tag) syntaxes are supported by Zarf but want to spin the auto editing of image:tag@digest into a separate issue for better tracking. See: https://github.com/defenseunicorns/zarf/issues/2247

[Racer159]

Created another issue for validation as well actually to keep things cleaner - going to close this one: https://github.com/defenseunicorns/zarf/issues/2257