Enable the reporting of known security vulnerabilities as Open VEX document

[fviernau]

In order to support exchanging information about known security vulnerabilities for a project
an ORT reporter shall be implemented which creates a VEX document according to the Open VEX specification [1].
Open VEX is fully separate from SBOMs which comes in handy, because:

1. It separates static from dynamic data.
2. It decouples corresponding use cases.
3. It is (supposed to be) minimal.
4. Not necessary (in the first place) to worry about linking to entries in an SBOM.

---

pitfalls:

• As a VEX report contains status information for the vulnerabilities, it is necessary to have a way to inject these into the
  report. This has overlap / similarities with ORT's existing resolution mechanisms, which need to be considered.
• One of the tricky things seems to be that the VEX reports contain kind of a history of the status changes with timestamps (e.g. under investigation -> fixed) of the vulnerabilities corresponding to the respective product. This implies, that knowledge about a previously generated VEX report is necessary, in order to generate a successor document with updates.
• A possible simplification to avoid historical data:
  • In ORT only support the use case "3.2.2 Single Product, Single Version, Multiple Vulnerabilities, Single Status" as
    outlined in [3].
  • This allows to use the same timestamp for all status entries, e.g. the report creation timestamp. This removes
    the need to know about the timestamp put into previously generated reports.
  • The merge functionality provided vexctl maybe (TBC) could be used to enable further "Single Product *" use cases, such as the "Single Product, Single Version, Multiple Vulnerabilities, Multiple Statuses" one.
• Open VEX has the tool vexctl which helps which creation, modification, merging of VEX documents. The use of
  such tools might impose more requirements on the VEX report, than the actual use case (e.g. propagating information
  about vulnerabilities). For example, on the correctness of the timestamps of status changes.
• Some initial workflow design questions:
  • Vulnerabilities correspond to packages / dependencies.
  • In license clearance, almost all work done for packages can be shared across projects. How does it look like for
    vulnerabilities? Consider expected amount and ratio of project context agnostic and project context aware curations / resolutions?
  • Do global curations / resolutions make sense? Initially, or better in future iterations?
  • How to store the (historical) information needed (timestamps, etc.) which is not available from the advisor / OrtResult.
  • Is it necessary to consider updating an existing report within ORT at all?

---

starting points:

[1] https://github.com/openvex/spec/blob/main/OPENVEX-SPEC.md
[2] https://www.cisa.gov/sites/default/files/2023-04/minimum-requirements-for-vex-508c.pdf
[3] https://www.cisa.gov/sites/default/files/2023-01/VEX_Use_Cases_Aprill2022.pdf
[4] https://github.com/openvex/vexctl

[sschuberth]

Would it be an alternative to just embed VEX into CycloneDX?

[sschuberth]

For the record, OpenVEX now has an official schema merged, and I successfully used this script to create Kotlin classes from it.

[mkurzman]

Ideally the VEX-file (e.g. managed in DependencyTrack) can also be used to provide the necessary input for handling detected vulnerabilities in the .ort.yml-file (to support the exchange in both directions)

Concerning the question about embedding the VEX into CycloneDX: While the SBOM may stay same, the context where the Software with the SBOM is used may change and thus lead to a different exploitability audit of the vulnerabilities. Thus IMHO the split helps managing different situations, e.g. SBOM1+VEX(context1); SBOM1+VEX(context2), comparable to the pattern with a repository content and different .ort.yml-files.