Feature request: Support custom properties for vulnerability analysis and include them in VEX export

[tkfu]

Current Behavior

The fields available for storing information about vulnerability analyses which make it into the final VEX are Analysis, Detail, and Justification. There is additionally a Comment field, but this does not have any effect on the final VEX file that gets exported.

Proposed Behavior

Add the possibility to define custom properties for vulnerabilities, and include them in the VEX export. This could be similar to the properties support for components that was released in 4.11. However, I'd personally like it a lot if the properties could be linked to the specific analysis of the vulnerability for a specific product, not to the vulnerability as a whole.

I provide an embedded Linux OS that gets used and customized downstream, by manufacturers or system integrators. I provide VEX documents to those downstream users, and include my analysis and annotations to make it easier for them to do the final analysis. For that reason, I provide a version of the SBOM that has a lot of vulnerabilities with the in_triage analysis state, with enriched information that helps the manufacturer or system integrator to finish the analysis, in the specific context of their own product with its final, shipped configuration.

I use custom properties to make automation of analysis easier: for example, suppose a vulnerability is in a kernel module that might or might not be included in the final product, I might have a property like affects_module so that a user can have tooling where they supply their kernel config and automatically parse which vulnerabilities apply. For that reason, it would be great if the properties could be scoped to the analysis. But I understand if that's not possible, or not desirable for other use cases.

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this enhancement was already requested

[stohrendorf]

I'm curious here how your custom properties could be processed by downstream systems. Unless your properties are following some well-defined schema, I doubt these properties would be beneficial at all. I think most systems would just ignore your custom properties, or not give any option to take some action based on these. If these properties rely on being interpreted by humans, you could also write a proper comment explaining the situation. The analysis options offered by the CycloneDX schema should, IMHO, be enough to express the analysis. In the scenario you mentioned, it's something like requires_configuration, which is covered by CycloneDX. It's impossible to technically express every case of misconfiguration, and I think it's much more easier to just say in the comment "hey, don't set X in the config" than trying to put it into properties. But maybe I missed something in your case.