Efficient Management of CVEs with Yocto

Generating an SBoM with Yocto

In short, SBoM generation using Yocto is not mature, and things are moving fast. For now, the best way to generate an SBoM and extract the applicable CVEs at the same time is to use the officially supported CVE-check tool. Using CVE-check is as simple as putting these lines in your local.conf file:

INHERIT += "cve-check"
include conf/distro/include/cve-extra-exclusions.inc

The tool will take care of generating an SPDX SBoM and the corresponding list of applicable CVEs. However, the problems start there. Due to the nature of Yocto, there is one SBoM per architecture, recipe or package. All these SBoMs can be found in build/tmp/deploy/spdx. Fortunately, as explained in Yocto's documentation, you will find an IMAGE-MACHINE.spdx.json file in tmp/deploy/images/MACHINE/ that merges (almost) all the individual SBoMs. You will also find in tmp/log/cve a bunch of JSON files listing all the applicable vulnerabilities found in the NIST's NVD database. All these files are merged into a single file named cve-summary.json.

At this point, you could use the IMAGE-MACHINE.spdx.json file and a third-party CVE scanner to manage the applicable CVEs. However, keep in mind that this file does not necessarily contain all the open-source packages used in your application (e.g. this file seems to only contain the SBoM of the root file system when you are compiling for QEMU, excluding the Linux kernel). You can also just use the CVE Check output and the summary file to manage the vulnerabilities, but this is not convenient considering that the summary may contain hundreds (or thousands) of CVEs. Worse, the Linux kernel team recently changed its CVE management procedure, and SUSE expects around 4,000 kernel CVEs per year!

Management of CVEs with Yocto and filtering the kernel's CVEs

Fortunately, most of the identified vulnerabilities come from the Linux kernel, and you certainly do not use the full kernel but instead use a "customized" kernel where numerous source files are excluded from the build. In addition, the NIST database is not really accurate, as it only uses the first two version numbers of the Linux kernel. So, there is room for improvement.

Recently, Daniel Turull from Ericsson proposed several patches to improve the way Yocto manages the Linux kernel's CVEs. Starting from Scarthgap, it is possible to use a tool called improve_kernel_cve_report.py to filter the kernel's CVEs and remove those that are not applicable to our specific kernel version and configuration.

If you are using the Walnascar version of Poky, using this tool is pretty simple. First, be sure that your local.conf file contains the following lines:

INHERIT += "cve-check"
include conf/distro/include/cve-extra-exclusions.inc

SPDX_INCLUDE_COMPILED_SOURCES:pn-linux-yocto = "1"

This line allows annotating the kernel's SPDX file with the list of source files actually used to compile the kernel. Then, you will need to retrieve the GitHub repository that contains an accurate description of the vulnerabilities impacting the Linux kernel. This repository is maintained by the kernel maintainers, so don't worry about its freshness.

git clone https://git.kernel.org/pub/scm/linux/security/vulns.git

Once you have downloaded the repo, use Daniel Turull's tool to filter the cve-summary.json file. You will have to pass the tool the path to the kernel's SPDX file. This file should be located in tmp/deploy/spdx/<MACHINE>/recipes/recipe-linux-yocto.spdx.json. You will also have to pass the path to the downloaded repo and the path to the cve-summary.json file. The tool will generate a new CVE summary with the unwanted CVEs excluded (they are only annotated, so they are still visible for tracking purposes).

python3 ../scripts/contrib/improve_kernel_cve_report.py --spdx tmp/deploy/spdx/qemuarm64/recipes/recipe-linux-yocto.spdx.json --datadir ./vulns --old-cve-report tmp/log/cve/cve-summary.json

Annotating the vulnerabilities

Now that you have an expurgated version of the summary file that lists all the applicable CVEs, you are certainly wondering how to annotate it, to mark some vulnerabilities as irrelevant, some others as patched, etc. To do that, there are, for now, not so many solutions available. You can use one of the commercial tools listed previously (in which case they will take care of filtering the kernel CVEs for you), or use the only tool I found able to annotate the summary file in a relatively friendly way: Vulnscout.

While Vulnscout's documentation is not so great, using it is actually quite easy. First, you need to write a configuration file:

• Create a .vulnscout folder at the root of, for example, the poky directory.
• Copy & paste the Yocto example into this folder.
• Modify the source path to point to your cve-summary-enhanced.json file (or cve-summary.json file if you did not filter the kernel's CVEs).

YOCTO_CVE_SOURCES=(
 "PATH/TO/cve-summary-enhance.json"
)

Then, copy the vulnscout.sh file to the root of Poky and execute the following command:

./vulnscout.sh scan

The script will take care of downloading a Docker container of the server and launching it. The server will listen for connections on port 7275, and by using your favorite web browser, you will be able to manage and annotate your CVEs. Vulnscout stores your annotations in a VEX file in its cache folder, so you can shut down the server without losing your work. Finally, you can use the export function to retrieve your work when required.

Breaking the dependency on NIST's database

Most tools, including CVE-check, use the NIST database to retrieve the CVE list. Unfortunately, NIST seems to be overwhelmed by the continually increasing number of vulnerabilities. Indeed, their tracking system requires inputting a lot of annotations (CVSS, CPE, etc.), whereas others (e.g. Linux kernel maintainers) have chosen not to attribute any CVSS to a given CVE. As a consequence, the NIST database does not track CVEs as fast as would be required.

There is at least one open-source project willing to break away from the NIST database's dependency. The approach presented here was presented at FOSDEM 2025, and it is pretty interesting, considering that this project can use CVEs directly from the cve.org repository. Please note, however, that the project has not received any commits for a year.

To go further

TrustnGo is a company that provides software products, consulting, development and training services in the area of embedded cyber-security. Do not hesitate to contact us whether you have any questions about our offers or just want to have a discussion about this blog post.