Written by: Joe Schneider
The EU Cyber Resilience Act (CRA) has fundamentally changed embedded software development by mandating proof of a product’s secure operation and ability to remain safe throughout its lifecycle. Despite being an EU regulation, the CRA is applicable to any globally manufactured product targeting EU markets and has led many other jurisdictions to introduce similar cybersecurity initiatives. These include the USA’s Executive Order 14028, Japan’s METI’s Cybersecurity Management Guidelines and the UK’s Product Security and Telecommunications Infrastructure (PSTI) Act, each with their own subtleties and guidelines that add extra hurdles for developers.
For the most part, however, these steps do not call on manufacturers to prove compliance through completely new frameworks. Producing and documenting a software bill of materials (SBOM), for example, has been considered a cybersecurity best practice for many years. SBOMs provide regulatory bodies with a structured, comprehensive list of the components, libraries, dependencies, and more, in a software stack, increasing transparency into the supply chain, wherein vulnerabilities may lie. As such, the CRA has shifted the SBOM’s status from non-essential documentation to a legal requirement for meeting market compliance standards, presenting yet another challenge for many embedded teams.
This article will examine why SBOMs are an important part of modern cybersecurity infrastructure before outlining the core requirements for CRA-aligned SBOM generation and other obligations placed on manufacturers to ensure long-term compliance. It will then introduce Dojo Five EmbedOps as a tool for streamlining compliance efforts and provide a brief guide as to how EmbedOps can be used for CRA-aligned SBOM generation and logging to ease these new regulatory requirements.
The Importance of SBOMs in Cybersecurity
For developers unfamiliar with regularly generating SBOMs, it may seem odd that the CRA emphasizes this documentation as particularly important for cybersecurity. Nevertheless, SBOMs provide a foundation for identifying software component vulnerabilities so that manufacturers can proactively address security issues as they arise.
For example, consider a scenario where a widely used software component, such as a module for handling network communications, is publicly disclosed to be exploitable by a buffer overflow attack. An easy-to-access SBOM allows manufacturers to quickly check whether their products use the vulnerable component so that teams have more time to test and push out security updates that address issues, before more devices are exploited.
It is also important to acknowledge that SBOM generation under the CRA is not just a one-time thing; the CRA mandates that SBOM reporting is required throughout the complete product lifecycle as updates and changes are made, such as the aforementioned security update or a standard direct firmware update (DFU). This regular SBOM reporting helps track and catalog vulnerabilities while providing proof of successful remediation. Reporting vulnerabilities and fixes then helps the wider embedded community assess risks when integrating third-party software components into their stacks.
In short, ongoing SBOM reporting is what keeps consumers safe from cybersecurity vulnerabilities throughout the lifecycle of a product. Moreover, it helps mitigate recalls that can have dire financial and reputational costs for manufacturers, especially in an age where fines for non-compliance serve as a primary enforcer for legislation.
Core SBOM Requirements and Obligations Under the CRA
There are many different ways to create and store SBOMs, but the CRA requires strict formatting, inclusion, retention and minimum scope requirements to conform with regulations. For starters, CRA-aligned SBOMs must be generated in a machine-readable, commonly used format like SPDX (as opposed to a static PDF). This standardization helps automate vulnerability scanning and reporting and simplifies external auditing efforts.
In addition, the CRA mandates that SBOMs are included in the technical documentation for each product and must be retained for at least 10 years after a product has been placed on the market. As previously noted, SBOMs must also be kept up to date for the purpose of lifecycle management, with all update patches and changes noted as part of this documentation. It falls on the manufacturer to ensure these records are kept safe during this time frame.
In contrast, the requirements scope for CRA-aligned SBOMs is not as well defined at the time of this writing: Current CRA guidelines indicate that SBOMs are only required to cover the top-level dependencies of the product, but the inclusion of deeper transitive dependencies is now becoming best practice for future-proofing compliance as part of a manufacturer’s vulnerability management obligations.
As an example, Germany’s BSI TR-03183-2 guidelines suggest including the following details when generating a CRA-aligned SBOM-note that these are not yet mandated but are illustrative of the depth expected for future compliance:
- Component name
- Component version
- Component supplier
- Component unique identifier (PURL (Package URL), CPE (Common Platform Enumeration), etc.)
- Cryptographic hash
- License information
- Dependency relationships
- Name of SBOM generation tool used
- Name of the SBOM author
- Timestamp (i.e., the date of generation)
While CRA compliance requires that manufacturers create, update and store SBOMs, the legislation itself does not mandate public disclosure. However, in the event of a request by market surveillance authorities or conformity assessment bodies, manufacturers must be able to provide relevant documentation for validation, audit or to assist with cybersecurity incident investigations.
EmbedOps as a Route Toward CRA-aligned Development
Managing SBOMs and software testing processes can feel like an unnecessary extra burden for developers pressured with tight deadlines, but the importance of compliance cannot be overstated in the new cybersecurity landscape defined by legislation like the CRA.
To make matters worse, embedded C and C++ lack the standardized package management and tracking systems for facilitating easy SBOM generation and versioning, so manual SBOM generation is the most common approach for these languages, adding yet another step to the compliance process. By building SBOM generation into the development workflow as well as collecting and archiving SBOMs for each build, DevOps orchestration platforms like Dojo Five EmbedOps® can help lower the stress level and protect manufacturers from costly recalls or outright compliance violations.
EmbedOps integrates with popular continuous integration (CI) and continuous delivery (CD) platforms like GitHub and GitLab and supports embedded development teams by automating software testing (and reporting) to ease compliance efforts. Its primary advantage is providing scaffolding and harnesses for many testing processes that help verify whether software meets the compliance standards set out by the CRA.
By providing this core functionality, EmbedOps enables developers to concentrate on writing the essential tests for finding and removing vulnerabilities from code, instead of focusing on time-consuming reporting.
Among other functions, EmbedOps streamlines:
- Unit testing to verify that individual software components handle data securely and fail safely.
- Hardware-in-the-loop (HIL) testing that evaluates software performance on target hardware, where timing and memory constraints may produce new vulnerabilities.
- Automatic SBOM generation of embedded software stacks for detailed traceability, compliance, and Common Vulnerabilities and Exposure (CVE) reporting.
- CVE scanning to flag software components for known vulnerabilities across public databases and indicate the risk they present to device security.
Furthermore, EmbedOps stores the results of these tests, and the build environments to reproduce them, in an intuitive web-based dashboard. This provides a central hub for manufacturers to catalog and view documentation and enables easy traceability for CRA auditors and other regulatory bodies. Since users must generate a machine-readable SBOM for the purpose of CVE scanning, EmbedOps can be used to assist development teams in meeting the stringent SBOM requirements of the CRA (see Sidebar).
Conclusion
The CRA has forced many manufacturers to reconsider their legal cybersecurity obligations, placing new pressures on development teams as best practices like SBOM generation become part of long-term mandatory reporting efforts. While many details of this legislation are yet to be decided, by design Dojo Five EmbedOps offers developers a powerful tool for integrating SBOM generation as part of each software build to assist in CRA compliance, with all the relevant documentation logged and accounted for.
In addition, EmbedOps presents a comprehensive environment in which developers can accelerate essential code verification tasks like unit testing, HIL testing and CVE scanning to support greater product reliability and ensure secure builds throughout a product’s lifecycle.
Learn more about EmbedOps’ testing frameworks by exploring EmbedOps Docs, or alternatively, check out our Automating Reliability Engineering article series for full unit testing, HIL testing and CVE scanning demos for a Bluetooth-enabled device running Zephyr RTOS.
Sign up for EmbedOps to streamline your embedded DevOps today.
Additional Resources: SBOM Generation Through EmbedOps
Setting up SBOM generation and reporting through EmbedOps is a relatively straightforward process. To do this, developers must connect their repository to the EmbedOps platform, as demonstrated in the full EmbedOps CLI Quickstart guide. Since the following instructions combine aspects of this and several other guides, only key steps are included in this article, for brevity and clarity.
First, developers must sign up for a free EmbedOps account, which will require verifying an email address to access the platform and templates. Next, several dependencies and the EmbedOps command line interface (CLI) will need to be installed:
- Docker (or an alternative container engine) for running the development containers used by EmbedOps
- VS Code with the Dev Containers extension for interacting with these development containers
- EmbedOps CLI for interacting with EmbedOps features and functionality through the host machine.
Installing EmbedOps CLI can be done by running the following commands on the host machine:
mkdir -p /usr/local/bin && cd /usr/local
curl -fsSL https://gitlab.com/embedops-public/embedops-cli/-/raw/main/install.sh | sh
Running the eo command should return the following output (or similar) if everything is installed correctly:
EmbedOps CLI
Usage:
eo [flags]
eo [command]
Available Commands:
...
Next, developers must log into EmbedOps and connect their repository to the platform. The eo login command will open a browser and prompt the user to sign into the account created earlier.
By then running the eo init command in the root of the repository of interest, developers can create the initial development container and CI setup. This command will prompt the user to select their preferred CI provider and Linux distribution, and then will create:
- A repo_id.yml file that connects the repository to the EmbedOps platform
- A template-settings.yml file that saves the above CI provider and Linux distribution selection
- An initial empty development container configuration
- An initial empty CI configuration file and the /ci folder
This concludes the basic EmbedOps setup process. To integrate SBOM generation into the CI/CD pipeline, developers need a project that contains a complete software build.
A HIL testing workload, such as one that applies the EmbedOps nRF54L15 HIL Quickstart project template, can be used to populate the repository with files that can be modified to initialize the build directory for SBOM generation.
Once the relevant shell script and configuration files have been modified for SBOM generation (in this case pipeline.sh, zephyr.sh and prj.conf) the build directory can be initialized for running tools like Zephyr’s west spdx. This builds the project and generates an SBOM consisting of multiple files in the CRA-compliant SPDX format.
Once generated, this SBOM can then be reported to EmbedOps using the eo report sbom command, which uploads the files to the EmbedOps platform and scans them for CVEs. The results of these scans are then logged in the Binary Analysis section of the dashboard, under the Security tab, where known security vulnerabilities are identified and given a severity ranking so they can be addressed and/or disclosed by the manufacturer to meet CRA compliance requirements.
