Why vex affects has versions

[tomekkolo]

See CycloneDX/bom-examples#41.

Why vex specifies affects.version or range if affects.ref is unique bom-ref? Is it intended as a comment or what is the purpose ? Vulnerability is anyway always matched by bom-ref, so as in linked example it is confusing what to do.

[stevespringett]

A component version is optional. Therefore, you can specify a vulnerability that affects the component (using affects.ref) and specify a range of affected versions using affects.version.

[tomekkolo]

So in that case if version range is not matching version of component from bom-ref, then the vulnerability does not affect. So what is the point? To signal that some component was scanned and is not affected ? Because if it is affected (or not), then bom-ref says exactly which component it is, and version is not needed. And because of bom-ref, it always applies to only one component in specific sbom. I mean this brings additional confusion when parsing/applying vex, as I understand standard is based on uniqueness of bom-refs. Especially, that there is another field in vulnerability, analysis.state, which is for component according to description, and generally it gives the same information.
If needed, even as duplicated field, would it be just enough to have the affects.status without version ?

I just want to understand real use case and if to take into account affects.version field as it seems not needed if all uniqeness is guaranteed by bom-refs. Especially if some software is going to consume those sboms/vex.
Thx

[jkowalleck]

So what is the point?

the point is VEX. this is not SBOM nor VDR.
Maybe read the use-case description again?
see https://github.com/CycloneDX/bom-examples/blob/master/VEX/CISA-Use-Cases/Case-7/README.md
see also CycloneDX/bom-examples#41 (comment)