CRAVEX-Integration: import VEX statements

[pombredanne]

I would like to import existing VEX documents. This would mean being able to read either at least one of a CSAF or CycloneDX VEX (and later cover all three types with CSAF, CDX and OpenVEX) in the context of a product and apply the exploitability to the Packages of that Product. This could be done through ScanCode.io if need be and appropriate too.

This could instead of doing a DejaCode integration with ERP and business systems which has proven to be harzardous and essentially impossible in the current state of FOSS business tools

As noted in:

• CRAVEX-integration: Integrate DejaCode with business systems #353

In hindsight, these integrations look like either difficult, hard or impossible to achieve in a generic way. We should instead repurpose these towards another useful integration.

Originally posted by @pombredanne in #353

[mjherzog]

Integrating VEX data makes a lot more sense than ERP/business systems because the latter do not usually have a logical integration point or data structures for integration with FOSS compliance or supply chain security tools. The only integration for ERP that comes to mind would be BOMs (or SBOMs) for products in the discrete manufacturing modules and that is difficult because the manufacturing modules are typically more specialized than the financial or distribution modules.

[tdruez]

A few VEX data examples:

• https://cyclonedx.org/use-cases/optimize-remediation-efforts/
• https://cyclonedx.org/use-cases/vulnerability-disclosure/
• https://cyclonedx.org/use-cases/vulnerability-exploitability
• https://github.com/canonical/ubuntu-security-notices

Related issues:

• Introduce VEX Import (VEX Ingest) capability to DejaCode #16
• Enhancement request: Allow managing vulnerabilities in the product itself #249

Subtasks:

• Currently, a vulnerability can only apply to a product through package/component relationships. We first need to extend the Vulnerability models so vulnerabilities can be directly related to products.
• Implement the Vulnerability models in ScanCode.io (still using JSON field to store the vulnerability data)
• Load the VEX data from SBOMs into DejaCode/ScanCode.io models.

[pombredanne]

See also:

• Enhancement request: Export OpenVEX VEX docs #440

[pombredanne]

There are completely different set of VEXes:

• 1- something which for a specific package, like with this https://github.com/canonical/ubuntu-security-notices/blob/main/vex/usn/USN-2169-1.json
• 2- something which applies to a product for the product own-code
• 3- something which applies to a bundled or dependent package in the context of a product

When importing the more important and interesting feature is 3. meaning being to import VEX for the packages of a product.

The points for 1. and 2. could come out later and are less directly useful.

We can focus for now on a use case where the vulnerabilities are already known. Later on the supporting not-yet-known vulnerabilities could be useful, but may need also some integration with VulnerableCode.