The software supply chain is now under close scrutiny. With the Cyber Resilience Act (CRA), Europe has made it clear: software security is no longer optional. For connected product manufacturers, integrators, and developers, this regulation is a game changer.

Ensuring the security, traceability, and transparency of embedded software components is becoming mandatory. Manufacturers must provide a clear inventory of what their firmware includes and demonstrate that it can be updated and secured throughout the product lifecycle.

To meet this challenge, development teams must adopt new tools, processes, and architectural strategies. In this article, we delve into the essentials of the CRA, explore how to leverage the Yocto Project for robust firmware development, and outline how to generate and manage a Software Bill of Materials (SBOM) that aligns with regulatory requirements.

What is the CRA (Cyber Resilience Act)?

The Cyber Resilience Act is a European regulation aimed at strengthening the cybersecurity of connected products and software placed on the EU market. Its goals are to:

• Ensure that connected products and software are designed securely from the ground up.
• Guarantee the ability to update products securely during their lifecycle.
• Require manufacturers to provide a list of software components used.
• Mandate timely disclosure of vulnerabilities.

The CRA introduces strict compliance obligations for product developers, software publishers, and integrators. It applies to a broad range of devices, from smart home devices to industrial IoT systems.

The timeline: The regulation is expected to enter into force in 2025, with compliance becoming mandatory in the following years. This leaves little time for organizations to get ready.

What is the Yocto Project?

The Yocto Project is an open-source initiative that provides tools and templates to help developers create custom Linux-based distributions for embedded systems.

Key Features:

• Layered Architecture: Organize code by functionality (machine, distro, BSP, application, etc.).
• BitBake Build Engine: Build images, packages, and SDKs from metadata and recipes.
• Reproducibility: Ensures consistent builds across teams and versions.
• Customization: Developers can tailor their firmware to hardware constraints and business needs.

Yocto is widely used in industries requiring long-term support, traceability, and control over dependencies: automotive, industrial, medical, etc.

Firmware Platforming with Yocto

“Platforming” refers to the practice of building a common base image or set of reusable layers for multiple products. It brings major advantages:

• Consistency: All products share the same core OS and base libraries.
• Maintainability: One security update can benefit multiple products.
• Scalability: Easier to manage a product line with hardware variants.
• Faster Time-to-Market: Reuse leads to faster integration.

Example:

You manage a line of industrial gateways based on three different SoCs. With Yocto, you define a common layer for application logic and security tools, then add machine-specific configurations for each SoC. Updates, SBOMs, and patches are managed centrally.

In short, platforming with Yocto is a strategic investment for managing product evolution, security, and compliance.

What is an SBOM?

A Software Bill of Materials (SBOM) is a detailed list of all software components, libraries, and dependencies used in a firmware or application. Think of it as the “ingredient list” of your software.

Why SBOMs Matter:

• Transparency: Know what your firmware contains.
• Security: Identify and monitor vulnerable components.
• Compliance: Meet legal and industry requirements.
• Incident Response: Quickly assess exposure in case of CVE disclosures.

The CRA explicitly requires manufacturers to provide SBOMs as part of their product documentation.

How to Generate an SBOM with Yocto

Thanks to its metadata-driven build system, Yocto can automatically generate SBOMs using formats such as SPDX or CycloneDX.

Steps:

1. Enable SBOM Generation: Add relevant tools and settings in your local.conf or layer recipes.

   # Required to enable SPDX file generation
   INHERIT += "create-spdx"
   
   # Optional: If set to "1", the output SPDX files will be formatted
   SPDX_PRETTY = "1"
   
   # Optional: If set to "1", the output SPDX files will include file information
   SPDX_INCLUDE_SOURCES = "1"
   
   # Optional: If set to "1", BitBake will create a source files archive for each package
   SPDX_ARCHIVE_SOURCES = "1"
   
   # Optional: If set to "1", BitBake will create an output binary archive for each package
   SPDX_ARCHIVE_PACKAGED = "1"
   

2. Build the Image: Yocto will emit SPDX documents along with the build.

   bitbake core-image-minimal
   

3. Export and Analyze: Use tools to inspect the SBOM, filter by license or CVE, and generate reports from your tmp/deploy/spdx/ file.

Tips:

• Structure your layers to isolate third-party components.
• Use SPDX tags in your recipes to clarify license, source, and version.
• Validate SBOM completeness using available linter tools.

Integration into a CI Pipeline:

It is highly recommended to integrate SBOM generation into your CI/CD pipeline, so it follows the complete lifecycle of each firmware release. This ensures clear traceability and enables automated vulnerability monitoring.

How to Process and Manage SBOMs

Generating an SBOM is only the beginning. To meet CRA requirements, you must:

1. Store and Version SBOMs

Treat SBOMs like source code: store them in version control alongside the firmware builds. Link them to CI/CD pipelines.

2. Automate Vulnerability Scanning

Integrate tools like:

• Grype for vulnerability détection.
• FOSSA, Whitesource, Snyk for licence analysis.
• OWASP Dependency-Track for continuous follow up.

These scan your SBOM against CVE databases.

3. Monitor for Updates and Alerts

Use SBOM-aware monitoring tools to receive alerts when vulnerabilities are discovered in listed components.

4. Integrate in Product Documentation

Provide SBOMs to customers and authorities as part of the compliance package. Prefer machine-readable formats.

5. Create a Response Process

Establish a clear vulnerability response plan:

• CVE monitoring
• Patch prioritization
• Communication protocol with users and regulators

Conclusion: Turning Compliance into Competitive Edge

Preparing for the CRA is more than a regulatory checkbox. It’s an opportunity to improve product quality, reduce security risks, and streamline your development pipeline.

By adopting Yocto and implementing platform-based firmware design and SBOM workflows, you can build secure, traceable, and maintainable products that are ready for market and audit.