Since our previous update on sbom-cve-check, the project has continued to evolve with two new releases: version 1.3.2, released in June, and version 1.3.3, released in August.
These releases bring a number of improvements to the handling of SBOM data, CVE version ranges and vulnerability assessments, as well as fixes for some corner cases encountered when analyzing real-world software projects.
For those discovering the project, sbom-cve-check is a lightweight open-source tool developed by Bootlin for performing vulnerability analysis on Software Bill of Materials (SBOMs). It is based on SPDX SBOMs and can be used both as a standalone tool and through its integration in the Yocto Project. Since the Yocto Project’s Wrynose release, sbom-cve-check has been used as the Yocto Project’s official tool for CVE monitoring.
sbom-cve-check 1.3.2
Released on June 24, 2026, sbom-cve-check 1.3.2 focused on improving compatibility with the data encountered in practical SBOM analysis workflows, with several fixes around compressed SBOMs and Linux kernel source information.
Better Zstandard compression support
sbom-cve-check already supports compressed input and output files, including Zstandard (.zst) files. Version 1.3.2 enhances this by accepting either the backports.zstd or zstandard Python packages for Python versions prior to 3.14.
These packages are optional dependencies, making it easier to use the tool in environments where one or the other is already available.
More flexible simple annotation files
The simple annotation file format has also been extended with support for additional YAML keys.
Annotations are useful when the information available in an SBOM needs to be supplemented with project-specific information during vulnerability analysis. Expanding the supported annotation format makes this mechanism more useful for real-world projects.
Improvements to Linux kernel source analysis
Version 1.3.2 also fixes several cases related to the list of source files compiled into a component.
In particular, Makefile and Kconfig files are now filtered out from the list of affected files, if this is not the only file affected, when determining whether a component is affected through its compiled files. The release also filters out source paths containing <internal> or <built-in>, as well as paths ending in a slash. These entries do not represent actual source files that should be considered when performing the analysis. Finally, sbom-cve-check now detects incomplete lists of compiled Linux kernel sources. Such a list is only considered usable when it contains at least one of init/main.c, include/linux/module.h, or a file ending in .mod.c. This prevents incomplete kernel information from producing misleading vulnerability assessments.
sbom-cve-check 1.3.3
Version 1.3.3 was released on August 3, 2026. While 1.3.2 concentrated on several practical SBOM and source-analysis issues, this release brings important improvements to vulnerability matching and CVE database handling.
Better handling of disputed vulnerabilities
One of the most important changes is the handling of disputed CVEs.
When a vulnerability is marked as disputed, sbom-cve-check can now generate a “not affected” assessment. This makes the resulting vulnerability analysis better reflect the information provided by the CVE ecosystem, rather than treating every disputed vulnerability as an ordinary affected/not-affected matching problem.
This is particularly useful for automated vulnerability-management workflows, where the generated VEX assessments need to accurately represent why a vulnerability is not considered applicable.
More flexible CVE version matching
CVE List entries can express affected version ranges in a number of ways. Version 1.3.3 improves support for the version field for the CVE List database when it contains multiple version expressions, including versions prefixed with comparison operators such as <, <=, >, >= or =<.
This improves compatibility with the increasingly varied version information found in current CVE data.
The release also adds safeguards for two difficult cases encountered when comparing versions:
- Version ranges with a date boundary such as
2024-01-01are ignored when the component version is not itself a date, for example when it is a semantic version. - In some cases, version ranges with distribution-specific packaging suffixes such as
.el7are ignored, following the rules documented in the sbom-cve-check design documentation.
These changes help avoid inappropriate version comparisons and, ultimately, reduce the risk of incorrect vulnerability assessments.
More robust CVE database updates
Version 1.3.3 fixes an issue encountered when a CVE database Git repository was initially cloned from a tag and subsequently updated to another tag.
The release also updates the CVE databases used by the project’s test suite, helping ensure that these tests continue to exercise the tool against current vulnerability information.
Improvements for developers and contributors
Version 1.3.3 also makes the project easier to develop and contribute to.
The release adds support for uv, along with an updated Developer Guide, and introduces a dedicated contributing guide.
These changes are particularly useful as sbom-cve-check continues to grow as an open-source project and is used by a broader community around SBOM and vulnerability analysis.
Get sbom-cve-check
sbom-cve-check is available as an open-source project on GitHub, with Python packages published on PyPI.
We welcome feedback, bug reports and contributions from users of the tool. As SBOM formats and vulnerability databases continue to evolve, keeping the analysis tooling robust and accurate remains an important part of maintaining secure Embedded Linux products.
