What is the point of `merge-vex`?

[mmarseu]

The documentation isn't clear on this, so I'd like to ask what the merge-vex command is for.

The documentation simply states:

This command requires two input files, a SBOM and a VEX file that shell be merged. The VEX file needs to be compatible with the SBOM.

But what is a "VEX file"? That isn't an established term. Even if you google it, you'll find a VEX document only described in an abstract manner, as a set of requirements but not as a complete data format. At the very least, there are currently two implementations which fulfil these requirements and therefore could constitute a VEX file: CycloneDX and CSAF.

Now, if we wanted to merge a CSAF VEX document into the SBOM that would probably justify its own command. At the moment, the command only works for CycloneDX, though, so why do we need a separate command if we already have merge for merging two CycloneDX files?

The only thing the current implementation apparently does differently from the regular merge is check whether all vulnerabilities reference components contained in the SBOM (see also #155). If they don't the command fails silently and simply outputs the original SBOM.

Could you explain the need for a separate command for this in the documentation?

[italvi]

@mmarseu Thanks for starting this discussion as this is something we also discussed internally since #35 and #36. And we decided to deprecate merge-vex in favor of a vex command. The vex command should have several sub-commands.

The ones we currently think of:

• merge. This would merge two VEX-files, i.e. not requiring an SBOM anymore. Part of this merge would be to check, whether the same CVE from one VEX-file was maybe updated and therefore the current analyis.state should be overwritten (one of the use-cases I can think of there).
• list. This would list me all CVEs in the VEX. Here I could even think of further flags, e.g. "--affected" to only see CVEs where (after analysis) I am really affected.
• prune/trim. This would remove not required entries, e.g. if you want to remove the false-positives CVEs from the VEX-file.

I think this command would bring a real benefit and justify a separate command for VEX-files.

Meaning for your integration test: Ignore it.

@CBeck-96 maybe for the time being, till the rework happens, we should add a deprecation notice to the command. This way we also see whether somebody reacts to it, as up to now only one user is known to us.

[CBeck-96]

Besides the ones mentioned above, we also have plans for a plausibility check regarding VEX.

@italvi i also agree with the deprecation notice, since the implementation might not happen for some time

[mmarseu]

@mmarseu Thanks for starting this discussion as this is something we also discussed internally since #35 and #36. And we decided to deprecate merge-vex in favor of a vex command. The vex command should have several sub-commands.

The ones we currently think of:

• merge. This would merge two VEX-files, i.e. not requiring an SBOM anymore. Part of this merge would be to check, whether the same CVE from one VEX-file was maybe updated and therefore the current analyis.state should be overwritten (one of the use-cases I can think of there).

That raises the same question again: Vex is CycloneDX (at least in the sense that we use it. Other implementations exist but we don't support them). Why do we need two separate merge commands for CycloneDX files, depending on the contents?

• list. This would list me all CVEs in the VEX. Here I could even think of further flags, e.g. "--affected" to only see CVEs where (after analysis) I am really affected.
• prune/trim. This would remove not required entries, e.g. if you want to remove the false-positives CVEs from the VEX-file.

Okay, I can see possible use-cases for these.

Meaning for your integration test: Ignore it.

Cool 😆

[italvi]

That raises the same question again: Vex is CycloneDX (at least in the sense that we use it. Other implementations exist but we don't support them). Why do we need two separate merge commands for CycloneDX files, depending on the contents?

Ok, agree. It would only make sense, if we start to support other formats like OpenVEX and CSAF VEX profile. And before doing so, we should then have something like convert.

Okay, I can see possible use-cases for these.

Glad, that this seems to be of use for you, too 😉. One more use-case could be extract for only getting the VEX, if somebody provides an embedded VEX.