The 1960s was the decade in which the car industry, first in the US and eventually across the whole world, found itself at the center of concerns about safety and the high numbers of deaths and injuries caused by collisions on the road. These concerns were felt and expressed both by consumers and by the legislators who represented them.
The car industry was then subject to a huge shift in the public mind, from viewing road safety as solely the responsibility of the driver, to an acknowledgement that the safety of cars and of road systems was a design choice. Subsequently, changes in government policy worldwide became rooted in the assumption that car makers are responsible for providing a high level of safety protection in their products.
Once this new attitude took root, it was reflected in waves of new safety regulation, and in the emergence of institutions such as the National Highways Traffic Safety Administration (NHTSA) in the US and the Ministry of Industry and Information Technology in China to set vehicle safety standards and to monitor compliance.
When safety regulation of the car industry first gathered momentum, it was implemented in the hardware domain - specifying, for instance, the minimum tread depth of tires or the way in which a windscreen shattered on impact. Now, a similar impulse is driving a new wave of regulation through the software domain, as the European Union and other authorities impose strict requirements for cybersecurity capabilities in IoT and other types of connected electronics devices. This new focus on cybersecurity comes in the wake of highly publicized incidents affecting electronics devices in the early 2020s, such as the Log4j vulnerability, and a series of attacks by the cyber espionage group known as Dragonfly.
An enabling element of cybersecurity features is the software bill-of-materials (SBOM), a register of the software components from which a device’s operating system (OS), firmware, middleware and application software are built. The SBOM for embedded Linux® devices is crucial because it helps to determine whether the device contains a software package which exposes the host device to the risk of cyber-attack. This will normally be because a latent vulnerability in the package has been discovered. In complex embedded devices based on a Linux OS, a device might contain hundreds or thousands of software components, obtained from open-source software libraries and commercial software providers.
Properly implemented, an SBOM for embedded Linux devices provides an easily searched, comprehensive and accurate directory of all these software packages, generated individually for each production unit, and kept up to date whenever software patches are installed. This enables the manufacturer to:
- Check whether a product contains software to which any emerging Common Vulnerabilities and Exposures (CVE) notice applies
- If it does, and if there is more than one variant of the product, identify the specific production units that are exposed
- Deliver security updates selectively to those production units that contain the at-risk software
For this reason, the creation and maintenance of an SBOM is one of the main requirements of the European Union’s Cyber Resilience Act (CRA). The provisions of the act apply to any connected electronics device marketed to EU member states. Since Europe is such a globally important and valuable market, in practice, compliance with the CRA is becoming a feature of most new embedded electronics products by default.
The US government’s 2021 Executive Order 14028, ‘Improving the Nation’s Cybersecurity’, also requires SBOMs for products supplied to the federal government.
An SBOM has another benefit, in addition to its role in cybersecurity: an SBOM makes embedded device manufacturers’ supply chains transparent, and allows third-party and open-source software providers to check that a product’s use of their software is properly licensed. This helps manufacturers to meet their legal obligations on software licensing.
Software component logging in the absence of an SBOM for embedded Linux devices
In the absence of a formal, verified record of a product’s software components, it is extremely difficult for the manufacturer of a product to answer the question of whether a given piece of at-risk software is contained in none, some, or all of the production units of any given product.
Many developers maintain spreadsheets or text files which list components – typically a manual rather than an automatic process, and so prone to error and omissions. Others rely on build system logs or package manager outputs, parsing these files when questions about exposure to security risks arise. Some development teams depend on institutional knowledge, trusting senior developers to recall which libraries and versions are deployed. Version control commit messages sometimes serve as informal component tracking, though this captures intent rather than actual composition.
These approaches suffer from fundamental flaws. Manual documentation quickly becomes outdated as dependencies change through updates and rebuilds. Transitive dependencies remain invisible, creating blind spots for vulnerabilities. When security problems arise, teams waste precious hours reconstructing the software that is actually deployed.
Spreadsheets are also an inadequate source of information on software composition: they cannot track component relationships or automatically flag known vulnerabilities.
Human memory fails, especially during staff transitions, leaving organizations unable to answer basic questions about their own products. Perhaps most dangerously, these methods provide false confidence: teams believe that they have an accurate view of their product’s software composition when in fact dangerous gaps exist.
Without automated SBOM generation integrated into the build process, embedded product security remains reactive rather than proactive, and compliance with regulatory requirements becomes extremely difficult, if not nearly impossible.
SBOM: a crucial element of an embedded Linux device manufacturer’s compliance strategy
If cybersecurity requirements call for an SBOM, product manufacturers need to be clear on how to comply with regulatory requirements. In fact, customers, especially in regulated industries such as medical equipment, automotive, and industrial control, today commonly mandate the generation of an SBOM which follows the guidance laid down by the US National Telecommunications and Information Administration (NTIA).
The NTIA's ‘Minimum Elements for an SBOM’ guidance stipulates the requirements of a viable SBOM: component names, versions, suppliers, dependencies, author of SBOM data, and a timestamp.
These guidelines are followed by the two standard SBOM formats specified by the embedded Linux community: SPDX (Software Package Data Exchange) and CycloneDX. While an SBOM in either format can be used to help to meet NTIA guidelines and with regulations such as the CRA, there are differences between the two formats:
- SPDX excels in license compliance tracking. This is valuable for embedded Linux device manufacturers, because of the range and diversity of open-source components used in custom Linux distributions built in the Yocto Project environment.
- CycloneDX is more focused on the management of security vulnerabilities and dependency relationships.
The choice between SPDX and CycloneDX often depends on the features of the manufacturer's chosen toolchain. Many manufacturers generate SBOMs in both formats.
By generating an SBOM in a standard format, developers provide for easier auditing of regulatory alignment.
How to create an SBOM for an embedded Linux device
In embedded Linux device development, SBOM generation should be integrated into the build process itself. The key advantage of build-time generation is accuracy: the SBOM reflects exactly what was compiled and linked into the final firmware image, eliminating guesswork and ensuring that the documentation matches reality.
Build systems such as Yocto Project and Buildroot have native capabilities or plugins which automatically collect component information as the Linux distribution is assembled. During the build, the system tracks each software package, from bootloaders and kernel modules to user-space applications and libraries.
For each component, the build system captures the data points required by NTIA guidance: package names, version numbers, supplier information, and the dependency tree showing how components relate to each other. The system also records authorship metadata, and timestamps the SBOM to create a clear record of when it was generated.
The Yocto Project, for example, offers the create-spdx class which generates SPDX documents automatically during image creation. Similarly, Buildroot can be extended with SBOM generation capabilities through custom scripts or third-party plugins. In container-based systems, the Syft tool can scan container images and generate CycloneDX or SPDX outputs.
Automating SBOM generation in a CI/CD flow
For users of the FoundriesFactory™ platform, SBOM generation capabilities are integrated into the overarching Continuous Integration/Continuous Development (CI/CD) flow, and the SBOM is a common resource available across the entire platform from development through production to device management.
The FoundriesFactory CI generates SBOM artifacts whenever a change occurs in a build. This happens for two kinds of builds:
- Yocto Project: SPDX artifacts are generated using built-in tooling – an output example is
<< lmp-factory-image-intel-corei7-64.spdx.tar.zst >>. The output includes an SPDX file for every package included in the build. - Containers: SPDX artifacts are generated using Syft. Container builds produce an SPDX file for each container/architecture. This will look like
<< https://hub.foundries.io/<FACTORY>/shellhttpd/arm64.sdpx.json >>.
While the native storage format for FoundriesFactory SBOMs is SPDX, the Foundries.io API provides a best-effort conversion to either CycloneDX or a CSV file.
Challenges and solutions in SBOM creation
Developers face problems in SBOM generation and maintenance which arise from the particular characteristics of embedded devices. The resource constraints to which embedded systems are subject – limited processor performance, restricted memory capacity, and, for battery-powered devices, a small power budget – mean that developers cannot simply adopt desktop or server-based SBOM tooling.
The complexity of Linux OS-based embedded systems amplifies these challenges. A typical embedded Linux distribution might contain hundreds or thousands of packages, each with its own dependency tree. Shared libraries create intricate webs of relationships, and static linking can obscure component boundaries. Custom patches applied during the Yocto Project build process further complicate matters, as these modifications may not be properly tracked by standard package managers.
The solution lies in treating SBOM generation as a build artifact rather than as a runtime activity. By capturing component information during compilation, when all dependencies are resolved and all patches are applied, manufacturers avoid imposing any resource burden on the target device. The SBOM lives alongside the firmware image in the development infrastructure, not on the device itself.
This approach enables an SBOM for an embedded Linux device to accurately reflect custom configurations, proprietary additions, and the exact versions of components compiled into the final image, including any security patches or vendor-specific modifications.
Vulnerability monitoring and update management
Even if the generation of an SBOM is made part of the build process when a product design is finalized, the manufacturer still has to take account of the impact of firmware updates on the SBOM. If the SBOM is not updated at the same time as an over-the-air (OTA) update is applied, the SBOM is rendered incomplete and inaccurate.
This is a crucial consideration precisely because an important function of an SBOM is to inform vulnerability monitoring: product manufacturers should routinely cross-check their devices’ SBOMs against CVE notices listing at-risk software packages to determine whether a product requires a security update patch.
When a firmware update is installed on a unit in the field, the SBOM for that unit should concurrently be refreshed to reflect the change in its software composition, and any new dependencies introduced by the update. As with the original SBOM, the changed version should be automatically regenerated during the build process.
The updated SBOM should be stored in the device management infrastructure and associated with the specific firmware version deployed to each device. This creates an auditable history showing exactly which software components are running on which devices at any point in time.
The maintenance of an up-to-date SBOM is handled automatically as part of the FoundriesFactory platform’s device management capability.
SBOMs: a fundamental element of the embedded workflow
A device’s SBOM plays a crucial role in its manufacturer’s process to help resist cyber-attacks. and can use the SBOM to verify that the software components of the device are legitimate and properly licensed.
The impact of regulatory requirements for lifetime cybersecurity protection – particularly the CRA - means that the generation of an SBOM cannot be a one-time-only action: the SBOM needs to be treated as a living document which is automatically updated every time that a software update is applied to a device.
The importance of a continually maintained SBOM for embedded Linux devices proves the value of systems which can automate SBOM generation. The FoundriesFactory DevOps platform offers superior SBOM generation and maintenance features. Using Syft as well as tooling built into Yocto Project, the FoundriesFactory software automates SBOM generation as part of its CI/CD flow both in product development and when developing and delivering update patches.
SBOMs created and maintained individually for every production unit are a core feature of the platform’s device and fleet management systems. This SBOM capability is one of the reasons that customers use the FoundriesFactory platform to enhance cybersecurity features across fleets of devices, even when those fleets are large, complex and geographically dispersed.
If you are looking to acquire an SBOM generation and maintenance capability as part of a wider DevOps system for embedded Linux OS-based devices, you should evaluate the FoundriesFactory platform. You can take a deep dive with a free demonstration of the software system – request your demo today.