Skip to content

Commit/Subject: add VEX file with vulnerabilities information to SBOM #10

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

gscanniello
Copy link

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)

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)
@gscanniello
Copy link
Author

Dear project owners,
do you have any news about my pull request?

Best Regards
Giuseppe

@umoelli umoelli added the documentation Improvements or additions to documentation label Nov 8, 2024
@umoelli umoelli self-requested a review November 8, 2024 06:49
@tjorbo
Copy link
Member

tjorbo commented Nov 29, 2024

Dear @gscanniello

Thank you for your interest in our project and for introducing us to the concept of VEX and the openVEX tool.

In our opinion, a single VEX file that declares the vulnerability status at a single point in time does not give value to the project since it should be checked and updated on a regular basis.

However, we are currently unable to set up and automate the processes to properly implement the VEX concept into our lifecycle management.

Nevertheless, we believe the concept is valuable and have created an issue to automate the generation. If you have the capacity to assist us, we would appreciate it.

Dataport/terminfinder-frontend#363

Yours sincerely, Tjorben

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants