Why address vulnerabilities in Zephyr RTOS systems?
Vulnerability management is no longer optional. What was once a voluntary practice for critical systems has become a regulatory requirement, especially with the introduction of the Cyber Resilience Act. Identifying security flaws early in development, prioritizing them, and tracking their resolution is now essential to ensure device security… and maintain user trust over time.
SBOM: The cornerstone of vulnerability management
A Software Bill of Materials is an inventory of software components within an embedded system. In Zephyr, it is generated in SPDX format using the west command.
The output includes several files:
- zephyr.spdx
- module_deps.spdx
- apps.spdx
- build.spdx
The zephyr.spdx file consolidates key system elements: kernel, integrated modules, dependencies, licenses, and versions. It serves as the foundation for any vulnerability analysis.
Zephyr SBOMs limitations
Despite its structured format, a Zephyr SBOM has several limitations when aiming for robust vulnerability tracking.
1. Missing or incomplete identifiers (CPE & PURL)
The most critical issue is the lack of unique identifiers for software components. To match a package with a vulnerability database like NVD or GitHub Advisory, you need a CPE (used by NVD) or a PURL (used in open-source databases). These identifiers are often missing or incorrect in Zephyr SBOMs, making reliable detection difficult and increasing the risk of overlooking critical issues.
2. Unlisted components
Not all components used in Zephyr are listed as distinct modules in the SBOM. For example:
- Bluetooth and MQTT are embedded directly in the kernel or main Zephyr channel, and thus not visible as separate modules.
- On the other hand, components like mbedTLS, Trusted Firmware-M (TF-M), or OpenThread may appear as modules but lack associated CPEs, limiting their usefulness for vulnerability detection.
A promising approach would be to analyze Kconfig flags, as done in Linux, to identify activated features and infer the actual components in use, even if they aren’t listed as modules.
3. Invisible external static library links
Another challenge: external static libraries are not represented in Zephyr SBOMs.
For instance, a dependency like cJSON, often included as source code, won’t be explicitly listed. This makes parts of the embedded code invisible and potentially vulnerable in security scans.
4. Default SPDX format
Zephyr SBOMs are generated in SPDX format by default.
While comprehensive, this format can be overly verbose especially for complex embedded systems where files can reach several gigabytes. This complicates processing, versioning, and CI/CD integration.
In contrast, formats like CycloneDX, which are lighter and security-focused, may be better suited for certain use cases.
5. MCUboot
MCUboot, a commonly used bootloader in Zephyr projects, presents a unique challenge: it has no CPE in the NVD, as no vulnerabilities have been officially submitted. Known issues are only referenced in GitHub Advisory, requiring specific handling via PURLs and databases like OSV. These sources are sometimes incomplete or poorly maintained, making manual monitoring of MCUboot essential (a practice we strongly recommend to our clients).
Our approach to improving Zephyr SBOM accuracy
To address these challenges, we’ve implemented several strategies:
1. Contributing to the Zephyr Project to integrate CPE/PURL
We actively contribute to the Zephyr ecosystem by helping integrate CPE and PURL identifiers into as many modules as possible. This enables reliable component identification and cross-referencing with vulnerability databases.
2. Patching SBOMs for existing Zephyr versions
For systems already in production, we’ve developed a script that enriches SBOMs with missing identifiers. It relies on a local database of package-version associations, making SBOMs usable without waiting for upstream changes.
3. Highlighting modules without CPEs
We’ve built mechanisms to flag Zephyr modules lacking CPEs. This helps our clients quickly identify risk areas in their SBOMs and prioritize manual reviews or corrective actions. CVEScan highlights modules like mbedTLS, cJSON, or Mender components that lack proper metadata.
4. Converting static lib into Zephyr modules
We work to reclassify certain static libraries (e.g., cJSON) as full Zephyr modules. This ensures they are properly included in SBOMs, with associated identifiers, and no longer invisible during vulnerability scans.
5. Tracking nested dependencies
Vulnerability analysis must go beyond top-level modules. We inspect nested dependencies (those used by Zephyr modules themselves). For example, the Mender OTA client uses cJSON via a submodule, but without declaring a CPE in its module.yaml. Without enrichment, this vulnerability remains hidden.
From Zephyr SBOM adaptation to vulnerability analysis
Once enriched, the SBOM becomes fully usable for vulnerability detection. Our CVE scanner cross-references components with databases like NVD, GitHub Advisory, and OSV. An intelligent engine filters relevant CVE, removes duplicates and false positives, and generates a clear, actionable dashboard.
CVEScan also supports manual qualification of vulnerabilities, action planning, and full CI/CD integration, automating the entire detection and remediation workflow in compliance with CRA requirements.
Few known vulnerabilities ≠ no risk
Recent Zephyr versions may show no vulnerabilities in the NVD, but that doesn’t mean they’re risk-free. One of our railway clients successfully backported patches from newer releases, demonstrating the value of active monitoring.
Improving SBOM management in Zephyr is key to securing embedded systems. These files are not just for vulnerability detection, they help document system composition, track licenses, and ensure compliance.
At The Embedded Kit, we’ve developed an enrichment script to address current limitations, while contributing to Zephyr’s long-term evolution. Combined with our CVE scanner, CVEScan, this enables reliable, automated, and regulation-compliant vulnerability management for Zephyr-based systems.
