[FEATURE]: Clarity on referring to external VEX source from SBOM

[RingoDev]

Describe the feature

I would like to be able to strictly typed refer to external VEX information outside of a CDX BOM.

We are already distributing SBOMs with our container images as In-Toto attestations and are very happy that scanners like Trivy are able to pick up the BOM and use it for the most accurate scan results we ever had.

What is missing now is that we would like to be able to communicate vulnerability information (e.g. VEX statements) not hard coded in the BOM itself but rather serve an associated file somewhere else over HTTPS so we are able to make additions when the SBOM was already released to consumers.

What I was thinking about is to use the "externalReferences" in the "exploitability-statement" type to link to such an external VEX file and trying to get SBOM scanners to adopt resolving such references for immediated assessment of known false positives.

That field seems to be exactly made for that use-cases as being typed as containing either an URL or a BOM-Link.

As far as I understand it, the BOM-Link is an abstract link between documents, but would not tell some kind of scanner e.g. where to retrieve it.

The URL type on the other hand could contain any kind of resource on the other end - e.g. a URL to a PDF statement, an HTML page or maybe a CDX BOM with VEX information. This makes it a bit hard to make a case for e2e automation.

Possible solutions

What I would be wishing for is 2 things:

• a statement from your side / the community if that is actually a valid usecase that makes sense to be supported by tools interacting with an SBOM for security scanning -> discussion on trivy repo for reference: Support for dynamic VEX retrieval from "External References" of SBOMs aquasecurity/trivy#8047
• some kind of concept where we can provide additionaly typing to the URL to make it easier for scanners to distinguish if they can read the "format" of the resource that is located at that URL or not (seems very similar to a Media Type now that I am writing it out).

Alternatives

I am aware of the work being done on the Transparancy Exchange API. To me the TEA seems like a parallel usecase but not contradictory. E.g. maybe the linked VEX file might even be hosted by a TEA in the future.

Additional context

Add any other context about the problem here.

[jkowalleck]

We are already distributing SBOMs with our container images as In-Toto attestations and are very happy that scanners like Trivy are able to pick up the BOM and use it for the most accurate scan results we ever had.

So you have a static SBOM and a dynamic VEX?
If so, then here is my solution:

• keep that SBOM static
• create a VEX periodically, and have the affected components BOM-linked via $.vulnerabilities[].affects[].ref.
  Here is an appropriate example: https://github.com/CycloneDX/bom-examples/blob/master/VEX/CISA-Use-Cases/Case-7

If you wanted to communicate the URL to the latest VEX in an SBOM, you could use an external-reference of type = exploitability-statement.

specification/schema/bom-1.6.schema.json

Line 1808 in 2681380

"exploitability-statement": "A Vulnerability Exploitability eXchange (VEX) which asserts the known vulnerabilities that do not affect a product, product family, or organization, and optionally the ones that do. The VEX should include the analysis and findings describing the impact (or lack of impact) that the reported vulnerability has on the product, product family, or organization.",

For your case, the external-reference target URL could look like https://example.com/foo/bar/vex.cdx.json.
Of course, you may update the content of that VEX periodically, while keeping the URL static.
Ingesting tools could check whether the external-reference's target is a CycloneDX document, by schema-validating it, and may use the media types as hints . This way they could distinguish CycloneDX VEX/VDR from PDF or other data.

[RingoDev]

Yes that would have been my proposal as well, thanks for the additional references!

The question that is a bit harder to answer is: do you see this being a use case other organizations will follow on as well so it makes sense for SBOM vulnerability scanners to take on the maintenance to support it?

Why is that so important to us?

Realistically nobody will manually parse through SBOMs and check externalReferences for VEX information. In order to be useful, it needs to be so deeply ingrained in automatic processes and supported by the scanning tools directly.

So this is more coming from the direction -> is this the use case the spec expects to be built upon this externalReference->exploitability-statement field so we can go and rally some of the known SBOM scanning tools to support it as another way to discover VEX information?

[ppkarwasz]

The question that is a bit harder to answer is: do you see this being a use case other organizations will follow on as well so it makes sense for SBOM vulnerability scanners to take on the maintenance to support it?

At Apache Logging, we have been adding a link to our VDR to each published SBOM since last year. Looking at our download stats, it doesn't seem that many scanners follow that link. Maybe for VEX-es the situation will be different.

IMHO those links will never be widely adopted, but they might be useful to populate an initial Transparency Exchange API server.

[RingoDev]

Hey Piotr, is that what was also shortly discussed at KoalaCon?

The main difference here in my view is that scanners already rely on some very thorough sources for Vulnerability disclosure information (VDR) such as osv.dev or the NVD directly. So they might not have incentives to look for additional sources as long as they have the data already from somewhere else.

It may even incur additional overhead due to the fact that it would need to be de-duplicated against those central sources in many cases. Also a year does not seem that long ago yet, considering the current state of SBOM adoption😉

With VEX this still seems like a still very active point of discussion for scanners of where to discover such information where I expect vendors probably want to have direct control over (due to possible liability concerns).

Also I strongly believe that vendors want to have automatic ways of communicating the fact that they are "not affected" by something and if they are able to link to such a source from an SBOM and scanners pick it up, that may even benefit SBOM adoption.

[ppkarwasz]

Hey Piotr, is that what was also shortly discussed at KoalaCon?

Yes, I must have mentioned the fact.

With VEX this still seems like a still very active point of discussion for scanners of where to discover such information where I expect vendors probably want to have direct control over (due to possible liability concerns).

Yes, VEX-es are different, since there is not centralized database for them yet. For VDR-s there is also the possibility that the original version has more information that what ends up in NVD.

Also I strongly believe that vendors want to have automatic ways of communicating the fact that they are "not affected" by something and if they are able to link to such a source from an SBOM and scanners pick it up, that may even benefit SBOM adoption.

I certainly believe that putting links to VEX-es in SBOMs can be interesting. The big question is if this can be implemented on the entire supply chain. Right now it is easier for me, as a library developer, to issue VEX-es that state "CVE-12345 is probably exploitable, but libfoo 1.2.3 works well with the patched version 2.3.4 of the vulnerable libbar". It takes a CI run and 5 minutes to do that, no need to plunge into the code. 😉 Nevertheless I would be interested in establishing a test chain of dependent project, where each project publishes an SBOM and a real VEX.