Skip to content
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

docs(security): add VEX file with vulnerabilities information to SBOM #4511

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

Conversation

dfucci
Copy link

@dfucci dfucci commented Oct 16, 2024

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)

@terriko
Copy link
Contributor

terriko commented Oct 16, 2024

We already have a vex file here: https://github.com/intel/cve-bin-tool/blob/main/TRIAGE.json

Is there some particular reason you'd want to make a second one with less info in it, or was this pull request generated by a script that missed where the actual one was kept?

@terriko
Copy link
Contributor

terriko commented Oct 16, 2024

Also, if you have any recommendations on how to make it more obvious to people or scripts that we do in fact have a vex file already, I'd love some feedback on that.

Copy link
Contributor

@terriko terriko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm pretty sure the correct path here would be to integrate anything we've missed into the existing triage json file, so I'm marking this as needing changes and won't bother letting it run through CI at this time.

@dfucci
Copy link
Author

dfucci commented Oct 17, 2024

We already have a vex file here: https://github.com/intel/cve-bin-tool/blob/main/TRIAGE.json

Is there some particular reason you'd want to make a second one with less info in it, or was this pull request generated by a script that missed where the actual one was kept?

Thanks for your comment @terriko
This pull request was generated after our script found this repository containing SBOM.
Unfortunately, we missed the VEX file.

@dfucci
Copy link
Author

dfucci commented Oct 17, 2024

Also, if you have any recommendations on how to make it more obvious to people or scripts that we do in fact have a vex file already, I'd love some feedback on that.

AFAIK, there is no accepted way of doing this. We decided to have an ad-hoc VEX for each SBOM following a naming convention (file.spdx -> file.vex.json).
This would help us to decouple dependencies tracked in an SBOM from their vulnerabilities info, which may be used for a specific use case (risk assessment).

@dfucci
Copy link
Author

dfucci commented Oct 17, 2024

I'm pretty sure the correct path here would be to integrate anything we've missed into the existing triage json file, so I'm marking this as needing changes and won't bother letting it run through CI at this time.

Please notice that our VEX includes CVEs which are not present in yours.
I am not sure if they have been addressed already (I did not check the history of your VEX), but our VEX was generated on Oct 16, right before opening this PR.

Copy link
Contributor

@terriko terriko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had a bit of time to do an actual look through the difference in the findings. Looks two of them are already resolved since your script ran, but two of them point to places we could maybe recommend higher minimums, so thank you for that! If you'd like to make a PR for changes to requirements.txt feel free, otherwise I'll leave this open so I don't forget, but we can probably close this PR specifically after that.

And yeah, I'm still waiting for some standards to emerge around vex locations. we went with TRIAGE.json to match README.md and SECURITY.md and the like, but it might be more reasonable to stick it into the directory with the individual sboms (just more of a pain because we generate sboms per-python so then I get stuck maintaining a lot mroe of them). I'll have to think about it and maybe bug the others for ideas during our end of october monthly meeting.

sbom/cve-bin-tool-py3.9.spdx.vex.json Show resolved Hide resolved
sbom/cve-bin-tool-py3.9.spdx.vex.json Show resolved Hide resolved
sbom/cve-bin-tool-py3.9.spdx.vex.json Show resolved Hide resolved
sbom/cve-bin-tool-py3.9.spdx.vex.json Show resolved Hide resolved
sbom/cve-bin-tool-py3.9.spdx.vex.json Show resolved Hide resolved
@dfucci
Copy link
Author

dfucci commented Oct 21, 2024

Looks two of them are already resolved since your script ran, but two of them point to places we could maybe recommend higher minimums, so thank you for that!

Glad we could help.

I will leave this PR open for you as a reminder.

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

Successfully merging this pull request may close these issues.

2 participants