search

volution / kawipiko

kawipiko -- blazingly fast static HTTP server -- focused on low latency and high concurrency, by leveraging Go, `fasthttp` and the CDB embedded database
396 stars 10 forks source link

VEX file with vulnerabilities information to SBOM #16

Open gscanniello opened 3 days ago

gscanniello commented 3 days ago

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 commented 3 days ago

Thank you for checking our PR and showing interest in our research about SBOM and vulnerabilities management. We apologize for the confusion regarding the wrong dependencies. We have amended the commit and added the correct VEX file.

The VEX file should indeed be updated every time the related SBOM is modified (e.g., a new dependency is added, a dependency is updated). Ideally, this should be done as part of the same process that generates the SBOM (e.g., a GitHub action), which should also be included in the release of the project. (Notice that, for this study, we are targeting repositories providing an SBOM in their repository since this information can be queried through GitHub API.) You can find the script we use for generating the VEX given an SBOM at this gist https://gist.github.com/dfucci/055db60081cf188791ea593a149e1073 (thanks for your suggestion, I am sure that providing a webapp for this will be appreciated). Feel free to include is as part of your deployment. Finally, we appreciate your work to provide an SBOM as part of your project and hope this will soon become common practice among OSS maintainers.