Deprecate --attachment sbom commands

[lcarva]

Description

There are two ways to sign an SBOM and connect it an image.

The first option relies on cosign attach sbom to push the SBOM to the OCI registry and connect it to the image. Then, the user must use cosign sign --attachment sbom to sign the SBOM image attached to the underlying image. NOTE: this is a new .sig image for the SBOM image itself. The verification is also a two step process. 1) cosign verify --attachment sbom; then B) cosign download ... . Given that these commands take the digest of the underlying image and not the digest of the SBOM image, the verification process is susceptible to TOCTOU attacks.

The second option adds a new layer to the .att image which includes the signed SBOM data. This is done via cosign attest --type .... It can be verified in one step via cosign verify-attestation type ... . It is also a more generic approach since it can also be used to verify SLSA Provenance and other attestations types.

As a user, it is confusing that both options are available. It is also not obvious, at first, which option is better.

Let's deprecate the --attachment parameter of cosign sign and cosign attest according to the deprecation guidelines.

[priyawadhwa]

sgtm! Based on our deprecation policy, we need to:

1. Print a deprecation messaged to stderr whenever the --attachment flag is passed. We should mention that the cosign attest command should be used instead.
2. Remove the flag in 6 months :)

[ChristianCiach]

I am confused about this proposal. Do you want to effectively deprecate the .sbom artifacts in favor of the .att artifacts?

We currently prefer to use SBOMs over attestations because attestations are too hard to work with:

• Feature: Provide an easier way to retrieve SBOM from In-Toto attestation #2307

I agree that the current two-step process of uploading and signing, or downloading and verifying an SBOM is cumbersome and also produces unavoidable warnings. That's why I've created this issue a while ago:

• Feature: attach+sign or download+verify an SBOM in one command (to avoid currently unavoidable warning) #2528

If cosign decides to deprecate and eventually remove SBOMs in favor of attestations, I would be fine with that, because we are currently struggling to decide which attachment type we should use for our SBOMs. We are currently using .sbom for the sole reason that these are easily retrieved by using cosign download sbom. Before making attestations the only option, please solve #2307 before doing so.

[lcarva]

@ChristianCiach, I just realized the main downside of using attachments. The connection between the attachment (SBOM) and the underlying image is done via tag convention, i.e. :sha256-<digest>.sbom. If image A has SBOM A', and image B has SBOM B', someone with registry access can swap the relationship so image A has SBOM B', and vice-versa.

Contrast this with attestations. An attestation contains the data and the subject in a signed envelope. Swapping SBOMs requires re-signing the envelope. The relationship between an attestation and an image is signed.

For this reason, and the possibility of TOCTOU attacks (mentioned in the description), I am convinced that the attachments approach should be deprecated ASAP.

UPDATE: The SBOM itself does mention which image it describes. For CycloneDX, this is found under .metadata.component. This does provide a stronger connection between the SBOM and the underlying image. Of course, this is highly dependent on the SBOM format itself, and requires custom verification.

[ChristianCiach]

It's a bit sad to see that the sbom commands have been deprecated while the consumption of attestations (like extracting the SBOM from an attestion) is still so cumbersome and needs external tooling, as described in my previous comment.

[ChristianCiach]

Seeing that SBOM attachments will be removed soon, I want to point out that it's still not possible to push SBOM attestations as an OCI compliant artifact, because #1397 only added (still experimental) support for pushing signatures and SBOM attachments as OCI artifacts, but not attestations. This makes it currently impossible to push attestations to https://zotregistry.dev

See related issue:

• FR: loose mode allowing Docker mediaTypes  project-zot/zot#724 (comment)

[haydentherapper]

Hey @ChristianCiach, happy to revisit this. Reviewing this issue, I think both approaches are not ideal - SBOM signatures as separate artifacts have the TOCTOU concerns @lcarva brought up, while attestations as signatures are more heavyweight.

Are there efforts to standardize signed SBOMs that we could implement? Something like SBOMit? Or can we design detached signatures in such a way to mitigate TOCTOU concerns?

I'm not very familiar with this space. @lumjjb did you have thoughts on this, detached SBOM sigs vs attestations over SBOMs vs something more standardized?

[ChristianCiach]

I think attestations are the way to go. There is nothing wrong with using attestations for SBOM purposes, IMHO. The only thing missing in Cosign is the support for the OCI 1.1 Referrers-API to store attestations. Related issue:

• Plan for Reference Types Work! #1397

Or, at the very least, Cosign should support using OCI compliant media-types instead of the proprietary Docker media-types.

[lumjjb]

Attestations for an SBOM is good to be able to be able to provide integrity and provenance for an SBOM, as well as an optional effect of attaching it to a subject.

I believe SBOMs should still be their own blobs (i.e. not an embedded predicate), since they are meant to be composable by bundling SBOM files together, and they reference each other by their file hash, and they can become very large (we've seen 500MB+ SBOMs).

+1 to OCI 1.1 referrers api, that's what we're implementing as well for GUAC OCI collector.