CRAVEX-Integration: VEX document import - Design and implement CycloneDX VEX import

[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:

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

[mjherzog]

One more item for VEXes is to consider a VEX that applies to a component without a PURL. Both SPDX and CDX allow you to list an SBOM component with essentially just a name and version. This would be the lowest priority for now, but something to keep on our plan for VEX because it will be some time before we have a PURL-based approach that covers all software.

[pombredanne]

Some notes: The goal is to establish the base data models for the VEX import, to implement the import of VEX document formats (starting with CycloneDX), test the end-to-end round-trip of import/export, and integrate the imported VEX data in the existing flow of CRAVEX. The focus is on the VEX for the packages of a product, as opposed to the simpler case of the VEX of a single package. Importing VEX documents would complete nicely the core VEX feature set in CRAVEX to enable complex VEX exchanges between software authors in their supply chains.