You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SBOMs can specify a product in a number of different ways. For example, a SBOM can include a product as a Name, a CPE or a PURL (and possibly all three!). Whilst the quality of SBOMs is variable (and in some cases inconsistent) extending the mechanisms beyond a name should increase the reliability of the SBOM scanning and reduce false reports as CPE and/or PURL can include vendor information as well.
Currently our SBOM processing uses the "name" field to try to look up a product. This is good enough in a lot of scenarios, but definitely not all of them because a single piece of software may have many names (e.g. beautifulsoup could be bs4 or python-beautifulsoup)
NVD uses a "vendor, product" pair that corresponds to CPE https://nvd.nist.gov/products/cpe. In theory, if we have this CPE data in an SBOM it should tell us exactly what to look up and allow us to skip the more heuristic name matching that we're doing now. So it would be really nice if we could read those and probably prioritize the CPE over the name lookup we do now. It might also be useful to do both, or issue a warning to the user if they differ.
It's entirely possible that users would want to generate an SBOM using whatever tool they have, then manually annotate CPE information on top of it as a way of de-duplicating or fixing product names that don't
Checklist:
Add CPE support to our SBOM parsers. The parsers are here: https://github.com/intel/cve-bin-tool/tree/main/cve_bin_tool/sbom_manager and if you search for "name" you'll see where they current get the name. Have it grab CPE and parse the string appropriately in lieu of or in addition to the name. You may need to read the format docs for CycloneDX, SPDX, etc. to figure out what the field is called in each format.
Change out the current get_vendor logic to use the vendor parsed from CPE (if available). The get_vendor code starts here if you need to change it, though it may be that all the changes need to go in the particular parser where it's called:
Add a note to the documentation saying that we support CPE and noting any limitations or other things that users might need to know.
Note that In theory the CPE would be a unique identifier but in practice, we have many checkers in our catalog that have multiple CPEs associated due to vendor or product name changes, or due to someone new taking over vulnerability management. (Or in a few cases, it looks like due to data entry errors.) So you may need to be prepared to support multiple CPE strings.
This issue is reserved for a participant in the Open Source Hackaton 2023. Please leave it for hackathon participants through the end of April. If it hasn't been claimed by May 5 it will be open to any contributor who wants to work on it.
The text was updated successfully, but these errors were encountered:
Currently our SBOM processing uses the "name" field to try to look up a product. This is good enough in a lot of scenarios, but definitely not all of them because a single piece of software may have many names (e.g. beautifulsoup could be bs4 or python-beautifulsoup)
NVD uses a "vendor, product" pair that corresponds to CPE https://nvd.nist.gov/products/cpe. In theory, if we have this CPE data in an SBOM it should tell us exactly what to look up and allow us to skip the more heuristic name matching that we're doing now. So it would be really nice if we could read those and probably prioritize the CPE over the name lookup we do now. It might also be useful to do both, or issue a warning to the user if they differ.
It's entirely possible that users would want to generate an SBOM using whatever tool they have, then manually annotate CPE information on top of it as a way of de-duplicating or fixing product names that don't
Checklist:
cve-bin-tool/cve_bin_tool/sbom_manager/__init__.py
Line 91 in 0ed6c2d
Note that In theory the CPE would be a unique identifier but in practice, we have many checkers in our catalog that have multiple CPEs associated due to vendor or product name changes, or due to someone new taking over vulnerability management. (Or in a few cases, it looks like due to data entry errors.) So you may need to be prepared to support multiple CPE strings.
Related reading on the challenges of matching up "names" to packages: https://owasp.org/blog/2022/09/13/sbom-forum-recommends-improvements-to-nvd.html
This issue is reserved for a participant in the Open Source Hackaton 2023. Please leave it for hackathon participants through the end of April. If it hasn't been claimed by May 5 it will be open to any contributor who wants to work on it.
The text was updated successfully, but these errors were encountered: