What is the point of `merge-vex`? about cyclonedx-editor-validator HOT 4 OPEN

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

from cyclonedx-editor-validator.

@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.

from cyclonedx-editor-validator.

@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 😆

from cyclonedx-editor-validator.

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.

from cyclonedx-editor-validator.