The cybersecurity landscape is constantly evolving. Last years have shown an increase in supply chain attacks. Even if you put every effort into developing a secure code, it might turn out not to be enough if one of your dependencies contains a serious vulnerability. Your application will be as safe as its weakest link.

One of the control measures you may use to manage software components and mitigate such risks is generating accurate SBOMs.

What is an SBOM?

An SBOM, that is Software Bill of Materials is a list of all software components and dependencies used in the given application. It allows you to track the version numbers and names of the third-party components used in the application. Typically, SBOMs are generated in a machine readable format which makes them easy for searching and including in CI/CD process.

The concept is similar to hardware BOM generated after PCB design, containing part numbers for all the components used on PCB. Such a list can be used to order appropriate components and make sure everything will be ready for assembling the PCB. Especially in embedded systems, by creating SBOMs we use them as an asset in ensuring that our application is safe and that its dependencies don’t introduce serious vulnerabilities. Embedded SBOM generation helps provide list that act as a source of truth for traceability purposes.

The Software Bill of Materials is similar to an ingredients list in the food industry. People who are allergic to selected ingredients need to carefully check the list to make sure it’s safe for them. When you check the SBOM components on your list, you may also find entries that might make you feel not so great, especially if they contain vulnerabilities that were recently detected. SBOM provides visibility into these risks, making vulnerability management much more efficient.

Implementing SBOMs for your application gives you the edge of being able to detect any problems quickly and at an early stage allowing you to implement appropriate corrective measures.

Keeping track of the components used in your application is important for 2 reasons:

  • you can easily make sure you don’t use a component that has some known vulnerabilities

  • you can confirm that there aren’t any licensing issues that could put you in a legal trouble

The easiest way to understand the power of SBOMs is to think about a situation in which you don’t have them. Let’s say you have a company that offers a wide diversity of products. One day you get information about a serious vulnerability detected in one of the popular open source libraries. Without a SBOM management tool, your developers must manually scan every project to see which ones require a security patch. This manual SBOM analysis can take hours or days, only for the same cycle to repeat when the next vulnerability is reported.

What would it look like if you had regularly updated SBOMs? Checking if your projects contain a given dependency would be much quicker and it would take minutes or even seconds. Additionally, if you include implementing SBOMs and safety checks to your CI/CD pipeline, you would be informed about this vulnerability right away. If you add period safety check the vulnerability may be flagged faster even before you will be able to hear about this issue.

What are the standard SBOM formats and components?

The Software Bill of Materials can be generated in the three most common formats, each serving a specific role in vulnerability management and compliance:

  • SPDX (Software Package Data Exchange) – developed by the Linux Foundation, this SBOM standard is ideal for open-source compliance and license verification.

  • CycloneDX – developed by the OWASP Foundation, CycloneDX sboms are specifically tailored for application security. This format makes it much easier to integrate sbom data into automated vulnerability checks, as it supports SBOM generation optimized for modern security tools.

  • SWID (Software Identification) tags – used for asset tracking and inventory control. SWID tags were removed from CISA guidance as an existing format, they still function as a unique identifier within comprehensive SBOMs.

To ensure you generate accurate SBOMs, each entry should specify the following components:

  • component name

  • version

  • supplier name

  • license type

  • dependency relationships

  • unique identifier

Why are embedded SBOMs essential for linux devices?

You may think that collecting all information regarding application’s dependencies and putting them in one document may pose additional risks. It may feel as if you would be giving your hypothetical opponents a list of potential weak links. Actually, you don’t have to make your embedded SBOM public. You may keep it as your internal document and be prepared to provide SBOMs to notified bodies and governing agencies that may need to perform verification. Avoiding gathering these dependencies into a single document makes an application much more difficult to defend than to attack. It could look like attempting to impose one of common anti-patterns called ‘security by obscurity’. It’s not efficient and will not be able to protect you from the upcoming threats.

Why is SBOM management shifting from a "best practice" to a legal mandate?

An SBOM is not only a good practice that you may voluntarily add to your project; it is now a core part of regulatory requirements both in the European Union and the USA. As global security standards tighten, maintaining SBOMs has shifted from a recommendation to a legal necessity for many industries.

In the USA, Executive Order no 14028 in 2021 required that vendors selling software to any of the US federal agencies require SBOMs.

The FDA in its guidance regarding Cybersecurity in Medical Devices introduced the embedded SBOM as a mandatory deliverable.

The European Union introduced a regulation EU 2024/2847 commonly known as Cyber Resilience Act. This regulation also requires preparing the Software Bill of Materials for effective management of vulnerabilities.

As you can see, keeping track of the SBOM components in your system is no longer just a recommended design pattern it is a mandatory requirement. Organizations must now automate SBOM generation to keep up with these mandates.

Managing SBOMs in embedded systems

Keeping SBOM makes sense only if you will keep it updated. Luckily, many SDKs have native tools that allow you to create an SBOM and verify it against known vulnerabilities. Here we are going to show some examples.

How to Handle SBOM Generation in ESP-IDF?

In order to create a SBOM for an esp-idf project you can use the esp-idf-sbom tool. Generating the SBOM is quite simple. You need to install the esp-idf-sbom using pip:

				
					pip install esp-idf-sbom

After that you can create the SBOM using following command:

				
					esp-idf-sbom create <project description file> --output-file <output file path></output></project>

where <project description file> is the path to the project-description.json file located in your build directory. If the path to the output file is not provided, the SBOM will be printed in the console.

Checking for vulnerabilities based on SBOM 

If you save the SBOM to file e.g. sbom.spdx, you can use esp-idf sbom to automatically check against vulnerabilities from National Vulnerability Database:

				
					esp-idf-sbom check sbom.spdx

Similarly as before, if no output-file is provided it’s going to print the result in the console.

Generating SBOM in other environments

Software Bill of Materials can be also easily generated with different embedded ecosystems such as Zephyr:

				
					west spdx --init -d BUILD_DIR

west build -d BUILD_DIR -- -DCONFIG_BUILD_OUTPUT_META=y

west spdx -d BUILD_DIR

For details refer to the presentation on Zephyr project site. For nRF Connect SDK projects it’s also possible to use ncs-sbom command, for details refer to the nRF Connect SDK documentation.

Generating SBOM is also available for Yocto. It’s important to note that in case of Yocto it differs between different versions, e.g. in case of Whinlatter (5.3.3) and Scarthgap (5.0.17) SBOM is generated by default (and may be disabled), while for Kirkstone (4.0.35) it’s not generated and needs to be enabled.

How can you implement a reliable SBOM management strategy for the long term?

Make sure SBOMs are regularly updated

It’s obvious that it’s not enough to generate the SBOM in the development phase and assume it will stay fairly the same. Dependencies evolve quickly and SBOM needs to be regenerated after every code change. 

Automate SBOM generation and make it a part of your CI/CD pipeline

It’s much easier to keep the SBOM updated if you don’t even need to think about it. SBOM generation included in CI/CD pipeline ensures that you can keep track of all the dependencies in your code.

Perform safety check based on your SBOM

It’s not enough to generate the SBOM to fully benefit from it, you have to check it against known vulnerability databases to make sure your dependencies do not contain critical issues. Similarly as with SBOM generation it’s best to include these checks to your CI/CD pipeline. This way you can ensure that you will be notified when trying to add dependency containing known vulnerability. Adding automated periodic checks of SBOM against updated vulnerabilities databases can also inform you about new threats that were reported after your last SBOM generation. Even if you did not change anything in your code in the meantime, new vulnerabilities may have been discovered. That’s why it is not enough to perform safety check only after SBOM generation.

Make sure component identifiers have proper naming format required by the vulnerability database

Common Platform Enumeration (CPE) is a standardized method of identifying software components introduced by National Institute of Standards and Technology. If the entries in your BOM don’t keep this format, then checking your SBOM against the vulnerability database may give you wrong results. You may see that no issues were found even when your application will contain vulnerabilities – they could not be detected due to formatting issues.

Make sure your SBOMs are compliant with appropriate regulatory requirements

It’s important to align your SBOMs with requirements specific for regulatory requirements applicable for your product, make sure if there aren’t any restrictions on format or required information in your case

Why is a Software Bill of Materials the foundation of modern security?

In this article, we have presented an overview of SBOM, we have shown why sboms are important and how you can benefit from them. We have shown what are the most popular formats, such as CycloneDX, and what sbom data should be included in the list. We have looked into regulatory requirements which require sboms and presented how to generate accurate sboms in selected embedded software environments. In the end, we have presented best SBOM management practices for maintaining SBOMs over time.

SBOM provides visibility into the complex web of SBOM components, making it easier to track SBOM updates and address security flaws. All the new regulations in the area of cybersecurity released in last years have one common goal – stop treating security only as an afterthought and start including it early in your design process as an important architectural decision. With an increasing number of cyber threats and attacks, providing security of their users needs to be a priority for IoT manufacturers.