Efficient management of CVEs with Yocto

Generate SBoM and extract clean CVE list using Yocto

Both the RED-DA together with EN18031 standard and the upcoming Cyber Resilience Act require products placed on the EU market to be free of public vulnerabilities. In addition, starting from September 2026 all vendors of "products with digital parts" willing to place their products on the EU market will have to send a notice to ENISA and the CSIRT designated by their country when vulnerability impacting their products is actively exploited. Hence, to be compliant with the EU regulations, vendors need to carefully track published vulnerabilities to spot those that are impacting their products, to implement the appropriate mitigations and publish the corresponding update as fast as possible.

In theory, tracking the vulnerabilities impacting your software does not seem really complicated. All you need to do is generate a Software Bill of Material and cross-reference it with data from a CVE database such as NIST's NVD database. In practice, it's a completely different story!

First, it is not even sure that your toolchain is able to generate a useful SBoM. Then, you will have to deals with several SBoM file formats and various versions of this file formats (SPDX, Cyclone DX, OpenVEX, etc.). You will also face obsolete or inaccurate CVE databases that return barely usable results with hundreds of potentially applicable vulnerabilities. Finally, you will pass a hard time in annotating the identified vulnerabilities to mark them as addressed.

In the remainder of this blog post, we will present you with how to tackle these problems one by one without using commercial (and expensive) tools such as CVE Scan, Vigiles or Black Duck. To keep things as simple as possible we will remain focused on managing CVEs using Yocto but do not hesitate to contact us if you are using another toolchain.

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 a 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 the applicable CVEs. However, the problems start there. Due to the nature of Yocto, there is one SBoM per architecture, recipes or packages. All these SBoMs can be found here build/tmp/deploy/spdx. Fortunately, as explained in the Yocto’s documentation, you will find a 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 these 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. Worst, 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’s 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 CVE 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 to annotate the kernel’s SPDX file with the list of the source files actually used to compile the kernel. 

Then, you will need to retrieve the Github repository that contains 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 the Daniel Turull’s tool to filter the cve-summary.json file. You will have to pass to 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 CVE 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 expurged 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 (but is this 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 the Vulnscout’s documentation is not so great, using it is actually quite easy. First, you need to write a configuration file:

1. Create a .vulnscout folder at the root of, for example, the poky directory.

2. Copy & paste the Yocto example in this folder

3. Modify the source path to point to you 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 to the connections on port 7275 and, by using your favorite web browser, you will be able to manage and annotate your CVEs. Vulnscout stores your annotation 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 with NIST’s database

Most of tools including CVE-check are using the NIST’s database to retrieve the CVE list. Unfortunately, NIST seems to be overwhelmed by the continually increasing number of vulnerabilities. Indeed, their tracking system requires input a lot of annotations (CVSS, CPE, etc.) where others (e.g. Linux kernel maintainers) did the choice to not attribute any CVSS to a given CVE. In consequence, NIST’s database does not track the CVEs as fast as it would be required.

There is, at least, one open-source project willing to escape from NIST’s database dependance. The approach presented here has been presented to 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.