Support for dynamic VEX retrieval from "External References" of SBOMs

[RingoDev]

Description

What is this about?

I am wondering if it makes sense for the most feature complete OS SBOM scanner (namely Trivy) to support the dynamic loading of VEX statements specified via an "external reference" in CycloneDX or SPDX SBOMs.

What am I talking about

Both CycloneDx and SPDX SBOM standards have the possibility to included "externalReferences" with a strict enum of possibly types of external references / documents that are related to that SBOM. What is especially interesting for me here is the "exploitability-statement" type of CycloneDx and the "vulnerabilityExploitabilityAssessment" type of SPDX.

As this field is explicitly allowed to contain URLs I believe it would be a valid usecase to make a lookup to such an URL and check if the resource located at that URL is a supported VEX format that can be applied to filter the produced output.

What would be the value?

This could be used to have a very "efficient" way of retrieving VEX information specifically related to the SBOM that is being scanned. Compared to the "vex-repo" approach, in the best case this would only require to retrieve the VEX information that is explicitly relevant to the scanned SBOM. This would even open up possibilities for publishers/vendors to generate VEX files dynamically on the fly and distribute them via an API.

Furthermore, this gives vendors that are already publishing SBOMs (e.g. as part of their container images with Cosign and In-Toto attestations) a way for these SBOMs to point at where the dynamic VEX information for that SBOM can be retrieved.

What could be downsides?

• Even though there is a specific type for "exploitability-statement" this could point to any kind of external reference and does not even require to be a valid URL.
• I am not sure how many vendors are/will be reyling on that - except that I would like to make use of it 😅.
• This would be dynamically trying to retrieve information from a scanned SBOM and applying filtering possibly without the initiator of the scan being aware of it. It might make sense to have explicity logging if such an external reference is resolved and used, or even hide the feature behind a flag such as "--vex-resolve-external-references".
• This is yet another way of where VEX information might be coming from, whereas I see that you are currenly already working on speccing out thte Vex-Hub and Vex-Repository functionality - which possibly increases maintenance

How much work do I think that is?

Actually with Trivy already supporting VEX filtering and the ability to handle different VEX formats this is "only" another way of specifying where the VEX information is coming from that should be used to "filter" the results of an SBOM scan.

Who would need to do the work

I am currently pretty deep in that topic as I am working on a master's thesis in that field and would be willing to contribute if that seems to be a reasonable feature to have.

Target

SBOM

Scanner

Vulnerability

[knqyf263]

I think it should be discussed with the CycloneDX and SPDX teams first. Once it's standardized, we're happy to add support for that. Otherwise, nobody will use the field for this purpose, and implementing it in Trivy will be meaningless.

Also, the VEX Repository Specification potentially allows the indexing of external VEX documents.
aquasecurity/vex-repo-spec#2

This can achieve this benefit you pointed out.

in the best case this would only require to retrieve the VEX information that is explicitly relevant to the scanned SBOM.

[knqyf263]

Also I have not found information about your standardization efforts or the governance structure of the VEX-Repo spec. I would be more eager to try it out if I know what the future of that spec is shaping to.

We're discussing here.
https://docs.google.com/document/d/1Db-Izh2PWjIXH7mS54K1cHWsttq4_bxg9v3_YI2enyU/edit?tab=t.0

We haven't had a chance to discuss it since recent meetings were canceled, but we hope to move forward in a few months.

[knqyf263]

Especially if you have have a lot of different container images on all of the main public container registries. It seems like a pain to maintain all of these different oci PURLs to point at the correct VEX repo. Whereas the SBOMs attested on those containers already could easily propagate where the VEX source for that container can be found.

You are correct, but the placement of the SBOM is not standardized either. For container images, the OCI referrer may be available, but it is a long way to go, as you need to start with the step of ensuring that you get the SBOM first. We have chosen the shortest practical method, even if it is not ideal. So, it can be replaced by other methods in the future.

[RingoDev]

Ah interesting, so I guess at the moment you are not able to discover SBOMs attested on the OCI registry via cosign automatically (yet)?

EDIT: Just found the docs that show that cosign is required to be run before trivy can scan the retrieved SBOM: https://trivy.dev/latest/docs/supply-chain/attestation/sbom/#scanning

This would sound like a nice addition if you were able to discover such SBOMs in a single call.

[knqyf263]

Ah interesting, so I guess at the moment you are not able to discover SBOMs attested on the OCI registry via cosign automatically (yet)?

No, I mean there are many ways to attach SBOMs in OCI registries. Cosign does that using their approach, which is not standardized in OCI. Also, it's anyway applicable only to OCI registries. How about other artifacts or git repositories? AFAIK, there is no standard for SBOM discovery.

[RingoDev]

You are absolutely correct here. Also due to the fact that ecosystems differ so much and distribution channels are very different for something e.g. packaged as a container vs a CLI tool or a binary downloadable e.g. from a GitHub release page.

This makes a strong use case for the work being done on the Transparency Exchange API where you have a strongly specified API that serves/points to artifacts such as SBOM or VEX related to a Transparency Exchange Identifier (TEI).

How to propagate such an identifier with the artifact then, might just have the same discovery problem as you currently have though, that I do not think has had enough attention at this point.