Treat cosign SBOM and Attestation artifacts as "accessories"

[ChristianCiach]

Since Harbor 2.5.0 there is support for Cosign signatures (:tada:). When viewed inside harbor, the signature-images are shown as an "Accessory":

That is a very nice presentation of the signature artifact! Another nice effect of handling signatures as "accessories" is the fact that Trivy doesn't try to scan the signature-image this way. This is a good thing, because Trivy cannot handle these images and errors out.

This is exactly what happens when using cosign to attach SBOMs (cosign attach sbom ...) or attestations (cosign attest ...). Similar to signatures (tag-suffix .sig), cosign pushes SBOMs (tag-suffix .sbom) and attestations (tag-suffix .att) as additional artifacts.

Unfortunately, Harbor currently doesn't know how to handle these sbom- and att-artifacts. They are not listed as accessories, so Trivy tries to scan them, resulting in ugly error messages. Here is an example for an .sbom artifact:

When I click on "View logs", the log shows this:

image scan error: scan error: image scan failed: failed analysis: analyze error: failed to analyze layer: sha256:6535572bb4db769acd49b16cce0335166bad95c0e41680992a7bd9f1302ae717 : walk error: failed to extract the archive: archive/tar: invalid tar header
: general response handler: unexpected status code: 500, expected: 200

Because of this, I think .att and .sbom artifacts should be treated as accessories, exactly the same way as .sig artifacts.

Cosign uses the exact same naming conventions for .sbom and .att artifacts as for .sig artifacts, only the suffix is different. There is probably a lot of existing code in Harbor that can be reused for this.

Beware: SBOM and attestation-artifacts can have their own signatures-artifacts! If .sbom and .att artifacts are handled as accessories, this means that they can have their own accessories. I don't know if or how nested accessories should be handled.

Versions:

• harbor version: v2.5.4 (but Harbor 2.6.0 should behave the same)

[ChristianCiach]

The OCI spec now supports "reference types". Cosign already has plans to support this new spec: sigstore/cosign#1397

It probably makes sense to base the "accessories" feature of Harbor on that spec eventually.

[wy65701436]

Yes, currently Harbor does not recognize sbom, but we have plans to support it.

We have been looking at reference support in OCI, but it is still not finalized.

[ChristianCiach]

Feel free to close this in favor of #17928

[sambonbonne]

I don't know if I should open a new issue for this but SBOM in the CycloneDX format and uploaded by cosign in Harbor are not used for vulnerability scanning. It is listed as an accessory but nothing more. Re-running the vulnerability scan does not use the accessory SBOM.

Of course, I analyzed my SBOM locally with Trivy and it found some vulnerabilities (which are not listed by Harbor) so I'm sure it's Harbor that does not use the accessory.

I used the expirimental flags from cosign to upload the SBOM and attach it correctly:

$ COSIGN_EXPERIMENTAL=1 COSIGN_OCI_EXPERIMENTAL=1 cosign attach sbom \
  --sbom path/to/generated/bom.json \
  --type cyclonedx \
  --registry-referrers-mode oci-1-1 \
  my-registry.example.com/workspace/image:tag

[ChristianCiach]

@sambonbonne I feel like what you are describing is a completely different issue. In fact, I don't expect Harbor to use the uploaded SBOM for anything at all.

I actually think this issue could be closed. When using the OCI 1.1 features of cosign, Harbor behaves exactly as I wanted it to pre-OCI-1.1. Unfortunately Cosign still doesn't support to push attestations as proper OCI artifacts, but this is probably just a matter of time and we are probably migrating to Notary v2 (ORAS) anyway, for exactly this reason. As soon as cosign supports OCI 1.1 for all its produced artifacts, there will be no need for Harbor to treat in-toto attestations as anything special.