namtarb
commented
11 months ago Hi @eroussy, you bring up a good point. Daggerboard didn't have the same findings for lz4 1.9.4 and coreutils 9.0 because CPEs for those particular versions aren't listed as impacted for that CVE.
- CVE-2016-2781 / coreutils 9.0: the NVD database contains a list of properly formatted CPEs, but only goes from 5.0 - 8.31
https://nvd.nist.gov/vuln/detail/CVE-2016-2781
- CVE-2014-4715 / lz4 1.9.4: There are no CPEs for a particular package version. This is likely due to the variation in package versioning (1.9.4 vs r118 per CVE description). As a note, 1.9.4 appears to be much newer than version r118, and the CVE is only for versions up to r118. https://nvd.nist.gov/vuln/detail/CVE-2014-4715
Daggerboard reviews each package, attempts to identify a registered CPE from NVD, and then uses the CPE to identify CVEs to reduce false positives. As you mentioned, this can lead to issues especially with backported patches, packages missing a CPE, and varied formatting in the PackageName and PackageVersion SBOM fields. We take an incremental approach to address the latter issue, but there are always improvements that can be made.
A few ways that this method could be improved are:
- improvements to the Daggerboard code that assigns a CPE to a package. For ex, parsing based on package distribution versioning standards
- adding validation for package-url (purl) in addition to CPE
- validating against additional vulnerability and CPE databases
- NLP or algorithm-based analysis for high confidence commonalities
We are open to collaboration and welcome contributions with new ideas and improvements.
Hi I work on the SEAPATH project, which uses a yocto distribution. I'm currently on generating SPDX files for the SEAPATH image and I want to analyze them. I discovered Daggerboard in a linux fundation talk and find it very promising.
When generating an image with yocto, the compiler will automatically look for and display CVEs that concerned the installed packages. My goal is then to see if those CVE found by Yocto appears in Daggerboard.
That's work well in general, but I found many cases in which Yocto finds a CVE, but daggerboard can't even find the CPE of the packages. Here are a small sample coming from the SEAPATH project:
The original SPDX I gave to Daggerboard. No CPE are found for any packages. seapath-sample.spdx.txt
The CVEs find by yocto. Each one with a link to their page on the NIST website. seapath-cve-summary-sample.txt
It seems to me that Daggerboard first look for CPE and then for CVE associated with it. In some cases (for example here : coreutils, lz4) the CPE for the exact version of the package doesn't exist. But CVE do exist for this version. This is the case for coreutils and lz4 in the files I provided.
It could be that looking first for CPE and then for CVE is too restrictive and will miss some CVEs.
Yocto seems to download the entire NIST database and look in it by itself with its own research algorithm instead of asking the NIST API. Do you think Daggerboard should do the same ?
What's your opinion on that ? Is there something I miss here ?
Thanks Erwann Roussy
PS: Technical details if you need them :
Yocto generates one SPDX file per packages. This is not very suitable for Daggerboard, so I use spdx/tools-python to merge all "packages" part of all SPDX. If you need the original SPDX files form Yocto, here they are (in json format) seapath-spdx-files.zip
I used the docker installation method for daggerboard.