Scan SBOM attestation in Rekor

[knqyf263]

Description

SBOM attestation can be stored in Rekor and searched by digest such as image digest. If an image has an SBOM attestation in Rekor, we'll use it instead of scanning the image itself.

[knqyf263]

Assigned to @otms61

[otms61]

Alright. I'll try.

[itaysk]

Regarding the UX, the PR uses this format: trivy image --sbom-attestation <image>. What do you think about trivy image --rekor <image>?
Also I would suggest adding this via the sbom target, like trivy sbom --rekor <image>

[knqyf263]

Also I would suggest adding this via the sbom target, like trivy sbom --rekor

SBOM attestation is one of the metadata like image manifest and config, so it is more intuitive to me that it is under image. Also, Rekor can have attestations for container images, binaries and any artifacts. When trivy sbom --rekor foo is executed, Trivy doesn't know foo is a container image, a local binary or something else. If it is a container image, Trivy needs to calculate the digest that is used to search for attestation in Rekor, from the image manifest. If the input is binary, Trivy needs to calculate the digest from the binary content.

• trivy image --sbom-attesattion <image_name>
  • Calculate the digest from the image manifest
• trivy fs --sbom-attestation <path/to/binary>
  • Calculate the digest from the binary content

Another reason we put it under image is I feel like SBOM attestation should be used like a cache. If we don't find SBOM attestation, we should fall back to the normal scanning. In addition, SBOM attestation can be stored in the OCI registry and Rekor. Therefore, image scanning uses the following precedence order.

1. Try to retrieve SBOM attestation from OCI registry (if --sbom-attestation is specified)
2. If #1 is not found, try to retrieve SBOM attestation from Rekor (if --sbom-attestation is specified)
3. If #2 is not found, try to scan the image as usual

Regarding the UX, the PR uses this format: trivy image --sbom-attestation . What do you think about trivy image --rekor ?

--rekor is a bit ambiguous. We might be going to leverage vulnerability attestation as well. We might verify container images with Rekor though the work is left to cosign for now. Rekor is recently used for many purposes. I thought more granular flags were better (e.g. enable only vuln attestation, not SBOM attestation), but if you think users just want to enable/disable all Rekor-related settings once, I'm ok with --rekor.

In that case, we need another flag for SBOM attestation in the OCI registry.

1. Try to retrieve SBOM attestation from OCI registry (if --??? is specified)
2. If #1 is not found, try to retrieve SBOM attestation from Rekor (if --rekor is specified)
3. If #2 is not found, try to scan the image as usual

[itaysk]

makes sense, thanks for the detailed response.
the reason why I suggested --rekor is that maybe we will want to scan sbom attestation from somewhere else (like guac), but that might be too future looking to discuss now.

Also, what do you think about making this behavior on by default? if the service is unavailable/sbom doesn't exist it will still work.

[knqyf263]

the reason why I suggested --rekor is that maybe we will want to scan sbom attestation from somewhere else (like guac), but that might be too future looking to discuss now.

Ah yes, nice catch. What if specifying the attestation places via flag like --sbom-attestation oci,rekor,somewhere? It can disable OCI registries only for example and change the priority however they want like --sbom-attestation rekor,somewhere,oci.
And I just remember Rekor as well as OCI registries is also able to be self-hosted. It is a bit complicated, but we may need something like --sbom-attestation oci,rekor--vuln-attestation rekor --rekor-url https://myrekor.dev --somewhere-url https://somewhere.dev.

• Try to retrieve SBOM attestation in the following precedence order
  1. From OCI registry
  2. From Rekor
• Try to retrieve vulnerability attestation in the following precedence order
  1. Only from Rekor
• Rekor URL is https://myrekor.dev
  • It is used for SBOM/Vulnerability attestation
• Scanning steps are
  1. Try to retrieve vulnerability attestation from Rekor (https://myrekor.dev)
  2. If the vuln attestation is found and fresh (e.g. within 1 hour), Trivy just returns the result without scanning
  3. If the vuln attestation is stale or not found, try to retrieve SBOM attestation from OCI registry
  4. If #3 is not found, try to retrieve SBOM attestation from Rekor (https://myrekor.dev)
  5. If #4 is not found, try to scan the image as usual

It is too much 😄 , but this is what was in my mind.

Also, what do you think about making this behavior on by default? if the service is unavailable/sbom doesn't exist it will still work.

Yes, that is my plan. But attestations in Rekor is not mature and I guess they will add some more breaking changes. We will add a flag experimentally at the moment, then once it gets stable, we will change it the default behavior.

[itaysk]

ok so if I'm thinking about this through,

1. I suppose service url will not hold for much further, probably some more connection information will be needed at some point by some service (credentials, protocol, options etc).
2. --sbom-attestation rekor --rekor-url https://somthing I think needs to better disambiguate between the "official" services and custom.

so perhaps there's a service connection defined. I connect to my OCI registry, I call it "myreg" and in this connection I define all required information that's specific to this registry service. Ideally I would do this in the trivy config file, but for the sake of consistency all config file options could be configured as flags. additionally the common ("official") services are preconfigured in trivy like docker hub and rekor.
Then I can refer to any of the preexisting or default connections --sbom-attestation myreg,myrekor,dockerhub,rekor.

Also, perhaps renaming the flag name to --with-sbom or --sbom-from will be more intuitive but I'm not sure about this one, just sharing a raw thought.

[knqyf263]

but for the sake of consistency all config file options could be configured as flags.

What do those flags look like?

FYI: Cosign can customize the Rekor URL via --rekor-url.

--rekor-url string         [EXPERIMENTAL] address of rekor STL server (default "https://rekor.sigstore.dev")

[itaysk]

we've discussed this offline and agreed to support just one instance of every type (with predefined ordering between providers). no need to over-engineer this yet