Is CISA-Use-Cases /Case-7/ valid example

[tomekkolo]

in https://github.com/CycloneDX/bom-examples/tree/master/VEX/CISA-Use-Cases/Case-7 boms do not contain version of the software, but vex file affects sections contain versions or version ranges (i.e.

bom-examples/VEX/CISA-Use-Cases/Case-7/vex.json

Line 169 in 7d52984

"version": "5.1"

). So if I understand correctly, this vex should not apply to any bom as they do not specify any version, or the logic should be that if version is not specified then any matching bom with affects.ref is actually affected and in this case specifying version is irrelevant ?

What is the point of having affects section specifying also component ref and versions, if component ref is unique ? Ot is it just additional information ?

[jkowalleck]

So if I understand correctly, this vex should not apply to any bom as they do not specify any version, or the logic should be that if version is not specified then any matching bom with affects.ref is actually affected and in this case specifying version is irrelevant ?

What is the point of having affects section specifying also component ref and versions, if component ref is unique?

A component ref might be unique, while the component is not necessarily version-pinned.
Therefore, the vulnerability might tell which version of a certain dependency is affected.

Please read CycloneDX/specification#310 (comment)

Does this answer your question?

[tomekkolo]

Not exactly, what does it mean that component ref might be unique ? According to standard, it is unique and points to exact component in exact sbom. What is the goal in standard to give additional level of filter if bom-ref is so unique? It brings additional level of complexity when parsing, because you cannot rely on bom-ref. And producer of vex must know which exact component was scanned, as he/she filled bom ref in vex? You cannot cover with bom-ref more than one sbom at the end. You can only add many refs in affects field.

Going back to example, vex specifies that one version of product jkl is affected CVE-2021-44228, others are not. But bom 2 does not specify version of product jkl. So what should be applied if some software wants to do it automatically ? Is this specific bom ref affected or not ?

Thx

[jkowalleck]

Not exactly, what does it mean that component ref might be unique ? According to standard, it is unique and points to exact component in exact sbom.

Read "A component ref might be unique [...]" as "even though component ref is unique, [...]"
;-)
And: the VEX references a CycloneDX document, not an SBOM -- see below

Is this specific bom ref affected or not ?

see VEX

bom-examples/VEX/CISA-Use-Cases/Case-7/vex.json

Lines 164 to 172 in 7d52984

	"affects": [
	{
	"ref": "urn:cdx:e4c3eedc-4978-470c-ad02-6ffff63738ff/1#product-JKL",
	"versions": [
	{
	"version": "5.1"
	}
	]
	}

references the following product

bom-examples/VEX/CISA-Use-Cases/Case-7/bom-2.json

Lines 8 to 12 in 7d52984

	"component" : {
	"name" : "JKL",
	"type" : "application",
	"bom-ref" : "product-JKL"
	}

and the VEX states, that a known vulnerability affects this very certain product in a certain version range.

Is there something unclear? Maybe read the use-case description again?
see https://github.com/CycloneDX/bom-examples/blob/master/VEX/CISA-Use-Cases/Case-7/README.md

A VEX document might list all known vulnerabilities, and state whether certain versions of a product are exploitable(=affected) or not.
And still, it is up to you to check whether you have these versions installed and running. Especially, if the referenced component does not contain a version, because it is a product in general.
This way, you could build a complete vulnerability database in a VEX data document. Isn't that an amazing use case? ;-) This is VEX, not SBOM not VDR.

[tomekkolo]

The idea is clear, the case is in making standard easy to use for software that operates on it :)

So in general, what you say is that standard does not enforce the quality of provided sbom files and vex :)

Like the sboms from example are actually very low quality sboms and the correct thing to do is either request from vendor to ship better sbom, or do it yourselves. In example you cannot automatically apply vex to the product relaying only on database build based on sbom and vex, without additional (human?) analysis, as the same vex has also

bom-examples/VEX/CISA-Use-Cases/Case-7/vex.json

Line 130 in 7d52984

"affects": [

And I think a lot of people have issues how to use it actually, even with tools like dependency track DependencyTrack/dependency-track#2741

[tomekkolo]

I mean, try to import this example to dependency track (or point to other tool/test that works?), nothing is applied and even base component is not identified well :)

also, affects versions and how to use them are not mentioned even in cyclonedx guide (latest), https://cyclonedx.org/guides/sbom/OWASP_CycloneDX-SBOM-Guide-en.pdf . IMO it states clearly that only ref itself matters as it "provides a direct link to the precise component within a BOM" . So is it missing in guide that "if additional version is specified, additional check is needed as it might be just VEX that at the end might not apply due to version mismatch " :)
This contradicts a bit with the idea of standard that it is easy to automate by good linking and focus on automation of bom management and exchange, as it does not promote and enforce good quality of sboms leaving corner cases ?

[stevespringett]

I mean, try to import this example to dependency track (or point to other tool/test that works?), nothing is applied and even base component is not identified well :)

@tomekkolo what is your point? Dependency-Track (and most other tools) do not support every VEX use case. They will improve over time.

The guide you mention is specific to SBOM. Only a small subset of functionality of the spec is mentioned in the guide. There is another guide in development specifically for VDR+VEX, and a handful of other guides (SaaSBOM, ML-BOM, MBOM, CBOM, etc) also being developed.

Moving this thread to a discussion.

[tomekkolo]

Hey,
I just believe that this case is quite important and usefull, but the example boms and vex are not easy to implement because they are in my opinion not complete enough to apply to each other automatically, and having in standard additional version specifier conflicts a bit with ref and general idea of using them and uniqueness. Maybe better approach would be to use I.e. purl as mandatory and bom ref as optional, if someone wants to narrow matching to specific product installation for example. Then this sample is clear, any version of product that match is affected or not, but with bom ref someone can say in addition that this installation is safe as I.e. it is configured in some specific way. In current example I do not see a way for a product like dt or any other to apply this example vex to sboms in a correct and predictable way. From one side refs point to product, but versions cannot be matched, so as I wrote before, either sboms are wrong or vex are wrongly specified as they cannot be applied. Imagine that you have thousands of products for which you receive this kind of sbom and vex, no company will have human resources to analyze them manually. And standard itself should support/enforce clearly correct way to create those documents.
This is just confusing as examples should clearly guide people who want to use standard.

But anyway, if you have some links to new vdr/vex guide it would be great, maybe I'm missing something.

[tomekkolo]

Or just drop in vex affects bom-ref to be mandatory parameter, and allow users to specify one of: bom ref/purl/etc ? That would be super clear to use imo.

[jloehel]

For me the version/version range in affects is really helpful because I can create suggestions based on it how to fix it in the report: Upgrade to version xyz. But it's also necessary to check if there is one pedigree (patch) available which maybe fixes this.