How to Create an SBOM to Secure Your Embedded System

From medical devices for patient monitoring to vehicle control systems for smart cars, businesses across industries use embedded devices to collect information, control equipment, and build smart ecosystems.

But due to their complexity, embedded systems are vulnerable, especially when they include parts created by different manufacturers and software developers. Each driver, configuration file, bootloader, and operating system file can be an entry point for hackers. A breach may result in a critical event that can cost a business its data, integrity, reputation, and finances. To protect your embedded solution in all its complexity, your team needs to document what it consists of and record ongoing updates and changes. This is where a software bill of materials (SBOM) comes into play. 

In this article, you’ll learn how to create an SBOM and how it can help to secure your embedded device fleet. 

This article will be useful for tech leaders, product managers, and CISOs who want to ensure the security of their Internet of Things (IoT) systems and get in-depth knowledge of every device in their ecosystem to be able to effectively protect all devices from exploits and attacks.

What is an SBOM?

A software bill of materials (SBOM) is a document that lists all components, libraries, and modules used in a software application or device. Each component includes detailed information about its origin, version, and any known vulnerabilities, providing a comprehensive view of the software’s makeup.

An SBOM provides visibility into the following:

As you can see, an SBOM contains all the information about your software. But why is an SBOM especially important for embedded devices? Let’s find out.

Why use an SBOM for embedded system security?

Embedded systems usually contain complex firmware with multiple layers, including operating systems, bootloaders, and third-party libraries. It’s challenging to track all components, ensure they are up to date, and double-check for possible vulnerabilities.

One way to enhance the security of your embedded projects is by creating and maintaining an SBOM, which helps you see the intricate software supply chains embedded within your devices. An SBOM serves as a map that:

• Shows potential security risks
• Helps ensure compliance with industry requirements
• Allows for quickly discovering and responding to vulnerabilities

You can use SBOMs to protect your ecosystem of embedded devices and your business in general from risks of:

• Security breaches or exploits that can lead to loss of integrity and data as well as revenue losses, reputational damage, and legal repercussions
• Loss of sales to competitors who offer SBOMs with their products and are more trustworthy and secure
• Complications during mergers and acquisitions that arise from the risk of inheriting security issues when acquiring a company or not being able to provide proof of your product’s security when being acquired
• Compliance and regulatory issues such as fines and blacklists
• Unclear supply chains that lead to risks of unknown vulnerabilities, supply chain attacks, and the inability to respond to incidents quickly, which diminishes trust in the business 

An SBOM is especially important if you use embedded devices in industries that rely heavily on highly specialized, critical devices whose failures or vulnerabilities can have severe consequences. These include:

Understanding the value of SBOMs, specifically for embedded systems, let’s now explore practical tips for building a comprehensive SBOM for your own product.

How to build an SBOM: best practices and tools

Building a high-quality SBOM requires both strategic best practices and adherence to regulatory guidelines. As industries prioritize security and transparency in their software supply chains, the US government has taken steps to formalize SBOM requirements.

In response to cybersecurity risks, President Biden has issued an executive order (EO 14028) recommending that software developers provide SBOMs to their customers in the US. To implement this order, the National Telecommunications and Information Administration (NTIA) has defined the minimum information required for an SBOM in its Minimum Elements for a Software Bill of Materials report. 

This report outlines essential components of an SBOM, such as component names, versions, and supplier information, all in a machine-readable format. The document emphasizes the need for SBOMs to be comprehensive, regularly updated, and easily accessible to enhance transparency and security across the software supply chain.

To meet these requirements and build a high-quality SBOM, your team can follow five SBOM best practices:

1. List all software components

Ensure the SBOM includes every software component, along with details such as dependencies, versions, licenses, and suppliers. This comprehensive inventory helps in tracking and managing the entire software supply chain.

2. Encrypt your SBOMs 

Apply cryptographic hashes to each component to verify its integrity. This ensures that components have not been tampered with. We also recommend documenting any known vulnerabilities associated with components. This proactive approach will allow you to manage cybersecurity risks more effectively and respond to security threats faster.

3. Ensure license compliance

Verify that all components comply with their respective licenses. This will help you avoid legal issues while using and distributing software that’s part of your embedded system. 

4. Regularly update your SBOMs

Keep SBOMs relevant by regularly updating them to reflect new components, patches, and changes. This will keep your SBOMs accurate and useful over time. You should also document every change and ensure proper version control so that all developers and stakeholders can access this information at any time and collaborate efficiently.

5. Automate SBOM generation and management

To simplify SBOM generation and maintenance, you can integrate automated tools into the CI/CD pipeline. Automation will help you ensure consistency, reduce manual errors, and update your SBOMs on time.

The SBOM market offers dozens of tools for SBOM generation, management, and security. Here are some of the tools that Apriorit experts often use to automate their work with SBOMs:

• Syft — a CLI tool that allows you to efficiently create accurate SBOMs from container images and filesystems.
• FOSSA — an automated tool focused on open-source compliance and security, capable of generating SBOMs while ensuring adherence to licensing requirements.
• Tern — an open-source tool that inspects container images, providing insights into software components and their licenses and helping developers ensure compliance and security throughout the container lifecycle.
• CycloneDX — a widely recognized SBOM standard used across various tools and platforms to enhance software supply chain security. It is supported by numerous SBOM generation tools including Syft, OWASP Dependency-Track for Java and other languages, and GitLab for CI/CD pipelines. CycloneDX is versatile and applicable across different programming languages and environments.
• Microsoft’s SBOM Tool — a command-line utility that generates SBOMs for software projects, integrating with Microsoft’s security and compliance frameworks to enhance transparency and security across the software supply chain.

Although tools can aid your team in creating SBOMs for regular software solutions, they can’t always fully capture the complexity of embedded systems. This may lead to overlooking components or vulnerabilities that can expose your systems to significant cybersecurity risks. It’s essential to be aware of issues you can encounter while creating your SBOMs. Let’s discuss them in detail.

What to consider when creating SBOMs for embedded systems

Building SBOMs is inherently complex, but embedded systems add multiple layers of difficulty. To get detailed SBOMs and keep your systems secure, it’s important to watch out for certain nuances typical of embedded systems. Let’s look at them in detail.

• Complex and layered systems. Embedded firmware often includes multiple layers, such as operating systems, bootloaders, libraries, and application code. Each layer and component can have its own dependencies, making it difficult to document everything comprehensively. Moreover, each component often has a different origin, and you have to ensure it is secure and complies with regulatory standards.
• Limited processing power and storage. Embedded devices often have resource constraints that can limit the ability to run tools that might automatically generate SBOMs on the device itself. That’s why tools often can’t give you a full picture of your embedded systems, and you have to explore components manually to create an SBOM that has complete information.

• Frequent updates. Embedded devices are usually frequently updated due to emerging security vulnerabilities or changing standards. This is especially true for IoT devices used in the healthcare and automotive sectors. It can be challenging to keep your SBOM up to date without errors.
• Obscured hardware–software dependencies. Embedded device firmware can consist of a mix of open-source, proprietary, and third-party components, which are often tightly integrated and interdependent. This makes it difficult to discover dependencies and document them correctly, particularly when dealing with specialized hardware drivers or firmware.
• Varying security requirements. Different industries have varying requirements for SBOMs, and ensuring that an SBOM meets all relevant standards (e.g., FDA for medical devices, NHTSA for automotive) can be complicated. Some industries lack standardization, which can make it difficult to ensure security and compliance across the supply chain. In sectors without clear regulatory guidelines, organizations must navigate ambiguous requirements and may struggle to align their SBOM practices with the best security measures. 
• Outdated or incompatible software. Many embedded systems are built on legacy software that may not be compatible with modern SBOM tools. Documenting these older systems requires significant manual effort and expertise.

Creating SBOMs for embedded systems requires extra care, both in tool use and manual processes, to ensure completeness and accuracy.

Apriorit is ready to help you ensure your SBOM is up to date and accurate. Let’s see how we can help you build SBOMs even for the most challenging projects that involve drivers and intricate firmware.

How Aprioirt can help you with SBOMs

At Apriorit, we have extensive experience helping organizations secure their embedded systems for various industries including healthcare and automotive. Our team can assist you with every aspect of SBOM implementation, ensuring compliance with industry standards and improving the security of your embedded devices.

Here’s what Apriorit offers to cover your SBOM needs:

• Generate SBOMs using proven tools. Our engineers leverage embedded-specific SBOM tools to dissect firmware, identify software components, and generate accurate SBOMs tailored to embedded systems.
• Conduct manual source code reviews. When we hit the limits of what automated tools can provide, our experts complement them with manual source code reviews. This ensures that no component is overlooked and that your SBOM is as comprehensive as possible.
• Integrate SBOM management into your CI/CD pipeline. Apriorit experts know how to seamlessly integrate SBOM generation into your continuous integration/continuous deployment (CI/CD) pipelines and version control systems so you can track firmware changes and updates in real time. This ensures your SBOM is always up to date and reflects the latest software revisions.
• Prioritize critical components to secure first. If time is of the essence and the system is too complex, we can identify the most critical components and secure them first. This will allow you to mitigate security risks faster and ensure that high-priority vulnerabilities are promptly addressed.
• Ensure compliance with industry standards. Whether you operate in the automotive, medical, or industrial sector, the Apriorit team will help ensure your SBOM meets relevant regulatory standards, such as those set by the FDA or NHTSA.

With Apriorit, you’ll receive end-to-end support in creating and managing SBOMs, from selecting the right tools to integrating them into your workflows. Whether you need help securing your embedded devices or managing complex software supply chains, we’ll ensure you have the tools and processes to stay secure and compliant.

Conclusion

High-quality SBOMs are crucial for ensuring the security and transparency of your embedded systems. By building comprehensive SBOMs, you can better manage software components, track known vulnerabilities, and ensure compliance with industry standards.

To create a high-quality SBOM for your embedded system, it’s important to use the right tools for firmware analysis, maintain up-to-date records through automation, and have manual reviews performed by experienced professionals who know what can be overlooked in components and their dependencies.

Apriorit’s specialists in kernel and driver development are ready to assist you in implementing the best SBOM practices for your product. Our team prioritizes security and compliance, helping you ensure that your embedded systems are reliable and secure.