nyph-infosec / daggerboard

MIT License
101 stars 19 forks source link

CVE not found when working with SPDX generated by Yocto #24

Closed eroussy closed 1 year ago

eroussy commented 1 year ago

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.

namtarb commented 1 year 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.

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:

We are open to collaboration and welcome contributions with new ideas and improvements.