Add VEX file with vulnerabilities information to SBOM

[mdipenta]

Dear project owners, We are a group of researchers investigating the usefulness of augmenting Software Bills of Materials (SBOMs) with information about known vulnerabilities of third-party dependencies.

As claimed in previous interview-based studies, a major limitation—according to software practitioners—of existing SBOMs is the lack of information about known vulnerabilities. For this reason, we would like to investigate how augmented SBOMs are received in open-source projects.

To this aim, we have identified popular open-source repositories on GitHub that provided SBOMs, statically detected vulnerabilities on their dependencies in the OSV database, and, based on its output, we have augmented your repository’s SBOM by leveraging the OpenVEX implementation of the Vulnerability Exploitability eXchange (VEX).

The JSON file in this pull request consists of statements each indicating i) the software products (i.e., dependencies) that may be affected by a vulnerability. These are linked to the SBOM components through the @id field in their Persistent uniform resource locator (pURL); ii) a CVE affecting the product; iii) an impact status defined by VEX. By default, all statements have status under_investigation as it is not yet known whether these product versions are actually affected by the vulnerability. After investigating the vulnerability, further statuses can be affected, not_affected, fixed. It is possible to motivate the new status in a justification field (see https://www.cisa.gov/sites/default/files/publications/VEX_Status_Justification_Jun22.pdf for more information).

We open this pull request containing a VEX file related to the SBOM of your project, and hope it will be considered. We would also like to hear your opinion on the usefulness (or not) of this information by answering a 3-minute anonymous survey: https://ww2.unipark.de/uc/sbom/

Thanks in advance, and regards, Davide Fucci (Blekinge Institute of Technology, Sweden) Simone Romano and Giuseppe Scaniello (University of Salerno, Italy), Massimiliano Di Penta (University of Sannio, Italy)

All Submissions:

• [ ] Have you signed our CLA?
• [ ] Put closes #XXXX in your comment to auto-close the issue that your PR fixes (if there is one).
• [ ] Update docs/release-notes/release-notes-template.md if your changes should be included in the release notes for the next release.

[josvazg]

First of all thanks for your contribution!

The SBOMs we publish here at the Atlas Kubernetes Operator repository are intended to be a immutable registry of each release artefacts. This information will not change after the release, which means we do not need to maintain it after release, while CVE information would become stale eventually. Also, this information is enough to be used as input to CVE tracking tools that may report all known vulnerabilities know at the time the tool is run.

Having said that, we internally have process to augment these SBOMs using the CycloneDX format to include CVE information. That process is still in development and so far we do not plan to extend public support from this public repo. Most likely it will leverage company wide tools and processes instead.

From this, you may understand why we would not want to merge your suggestion, which only covers an older version and would require follow up manually to keep up to date.

[josvazg]

Closing the issue now, please do not hesitate to follow up as needed.