add VEX file with vulnerabilities information to SBOM #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ners, 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, Best Regards |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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_investigationas it is not yet known whether these product versions are actually affected by the vulnerability. After investigating the vulnerability, further statuses can beaffected,not_affected,fixed. It is possible to motivate the new status in ajustificationfield (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)