Software Bill of Materials (SBOM)

Gartner predicts that 70 percent of organizations without a firmware upgrade plan in place will suffer breaches due to firmware vulnerabilities. 

When it comes to device firmware and connected device security, where does a manufacturer or buyer start? Here’s the good news: you can find everything you need to know to mitigate your device risk within the firmware itself. 

What you need is a Software Bill of Materials, an SBOM.  

For manufacturers, their ability to keep their new connected devices secure has not kept pace with their ability to scale their production capabilities or the overall growth of the Internet of Things (IoT), Operational Technology (OT), and other embedded systems. Their buyers struggle with grasping the risks inherent in embedded technology. Nearly two-thirds of respondents to the PwC 2022 Global Digital Trust Insights Survey claim limited to no knowledge of IoT-related risks. 

Since 2017, attacks against firmware have spiked 500 percent according to NIST data compiled by Microsoft. This spike in firmware attacks comes at a time when just 29 percent of companies have any budget allocated to protect firmware even though 73 percent of respondents to a 2021 Ponemon Institute Study are committed (33 percent) or very committed (40 percent) to securing their supply chain.

But protecting firmware is not as easy as it may sound. Like a car is assembled from parts, manufacturers create firmware from parts as well. These include operating systems, bootloaders, drivers, and configuration files. Nearly all of these parts come from other manufacturers—open-source software providers or third-party vendors.

Just like faulty tires may expose a vehicle to a serious, or even fatal flaw, a security flaw in a device’s firmware can be integrated into a finished product, most often unintentionally.     

As these realities become clearer to manufacturers and their customers, worry grows about rising cyberattacks against products and critical networks. While many organizations have invested in application security and network monitoring, much fewer have implemented product security programs that can identify and mitigate connected device risk. 

Starting with a Software Bill of Materials can help.

Many firms first learn how to define SBOMs when they realize that they need one. The headlines announce the discovery of a zero-day vulnerability in an open-source library. Huddled around a conference table, stakeholders ask questions about where they face risk. The answers eventually coalesce around device firmware. 

But, no one has a clear answer about the composition of that device firmware or the location or extent of the zero-day vulnerability. 

Many Original Equipment Manufacturers (OEMs) do not know what software or which software versions are in their product because they source a lot of their components from third-party vendors. While OEMs may know what software (and which versions) they have used in the components they have created, this becomes much less so in components that have been sourced from third parties. 

If you have a Software Bill of Materials, and you know that a vulnerability affects certain versions of a specific software, a simple search on that SBOM can tell you if you’re at risk, and where.   

Simply put, an SBOM provides the foundation for product and supply chain security for device manufacturers and their customers. But, that’s where the simplicity in defining SBOMs ends. 

Even though standardization is coming—through new regulations—to define what an SBOM is and what it contains, today, SBOMs can go to any level of granularity. There’s no standard SBOM and every vendor offers its own version.    

Today, many organizations scan first-party, and not third-party, code. Many organizations know that the level of detail in their SBOMs—if they even have SBOMs—creates security gaps, but many don’t know how to confront this risk or simply do not have the resources. So they do nothing. 

Without the right tool, constructing an SBOM is hard to do. It requires manual processes, which are not scalable. Building an SBOM means defining the components within your components—breaking down those compound parts into their atomic parts. The challenge is reaching supply chain transparency where we can get to the list of atomic parts we have—software and its versions—so we can understand if we have vulnerabilities before we can decide how to address them. 

What happens when your product experiences a security breach? What if you didn’t even know your product was vulnerable?

SBOMs can serve as valuable tools in determining if, and where, you face exposure to security breaches and vulnerabilities. They can also help you fulfill your obligations under current and developing regulations. 

With the recent publication from the U.S. Department of Commerce on what a Software Bill of Materials (SBOM) should minimally include, the NTIA advises software vendors that SBOMs should be machine-readable—so their details can be uploaded into a larger database.  

With these new regulations, organizations are searching to find an SBOM solution, and a solution that is scalable.

But, it’s not just regulations and compliance. Device firmware now performs many of the functions that were once controlled by physical systems. Residing in the memory of connected devices, firmware is ubiquitous in our IoT-enabled world. Many users and even manufacturers don't know or understand all the components—and risks—that come with their device firmware. That doesn’t mean that these risks shouldn’t be identified and mitigated. 

When your work product experiences a security breach, this creates a problem with trust in the brand. It also creates problems in revenue. According to a Ponemon Institute Study, 59 percent of organizations have lost sales following product security concerns.  That can affect public company stock prices, reputation risk, and can even result in governments banning the sale of devices within their territories. 

Six of every ten product security leaders say that their organization finds it difficult to respond rapidly to new vulnerability disclosures that may impact their devices. SBOMs represent an effective first step to gaining an understanding of your connected device exposures by providing a map showing where those risks lie. But SBOMs also help to protect against other risks like:

• Security breaches or exploits, and associated losses of revenue, impacts on reputation, and resources spent on customer support and mitigation
• Loss of sales and revenue to competitors who offer SBOMs with their products
• Complications during mergers and acquisitions (inheriting security issues when acquiring a company OR not being able to provide proof of your product security when being acquired)
• Compliance and regulatory issues such as fines, black lists, etc.
• Not knowing when your products are impacted by new vulnerabilities
• Opaque supply chains

You cannot protect what you cannot see. Seeing into the firmware of connected devices is harder to do than, say, detailing the components of a web application. Web applications are singular programs, whereas a device firmware is a complex system of programs that can contain libraries, operating systems, boot loaders, configuration files, and numerous other components and component clusters that can be broken down even further. So, naturally, SBOMs for firmware and connected devices are more complex than SBOMs for web applications and other singular programs where traditional AppSec tooling might suffice to create an SBOM. 

So, what happens when you try to use traditional AppSec tooling to create an SBOM for your embedded products?

Traditional AppSec tooling will create an incomplete SBOM for an IoT device or other embedded product. It won’t find libraries that were recompiled or modified and will only focus on visible source packages. It misses out on vulnerabilities, which end up in the binary files. A product security tool purpose-built for connected products will create a comprehensive SBOM of open source, custom/first-party, and third-party/COTS components.

That’s important when you consider that, based on Ponemon Institute research, some 60 percent of respondents report that their organizations have trouble responding quickly when new vulnerabilities that may impact their devices are disclosed. 

That’s a problem for manufacturers, vendors, and buyers of those devices.  

You can’t protect what you can’t see—unpacking the supply chain and third-party components 

Today, supply chains have grown increasingly opaque, complex, and vulnerable to attack. It’s one of the most common challenges facing connected device manufacturers. When different manufacturers provide both hardware and software components—and these providers interweave with each other—risks and vulnerabilities abound. Even though these exposures may be confusing and difficult to identify, they must still be managed. 

Even if your vendors are running their DevSecOps processes, they likely still won’t know what’s in their software if they don’t have the right tool that can produce an SBOM with device-level detail. To fully control the process, even if your vendors won’t, you can detect and mitigate vulnerabilities if you can analyze the binary files within your device firmware. 

In the market today, you’ve likely experienced the limitations of tools for secure embedded development. Maybe you’ve overcome them by creating your own toolset. But that requires time, resources, and expertise that’s hard to find and even harder to hire.

With the emerging technologies inherent in connected devices, we all face new challenges, regardless of whether we manufacture or use: 

• Medical devices (IoMT)
• Industrial Control Systems devices (ICS) 
• Operational Technology devices (OT) 
• Consumer and enterprise Internet of Things devices (IoT)

You’re here because you’re considering upping your investment in product security. But, some questions remain:

• What challenges will you face as you work to instill confidence in your product?
• How will you stay ahead of cyber criminals who may target your connected devices?

With SBOMs, you can take some control back from your supply chain. With the emergence of new connected-device technologies, our supply chains are growing more opaque. Increasing complexity leads to more vulnerabilities, which require more time and expertise to identify and manage. CVEs and CWEs can exist, undetected, in your firmware code for years and expose you to potential backdoors. 

You have some suppliers who provide hardware for your connected devices. Others provide software. Often, these components are tightly coupled with each other. This growing number of vendors means you need to get a handle on the vulnerabilities in your product. 

Your vendors probably have their own security processes, but relying on that means blindly trusting that their processes are air tight. You need to be able to validate what’s inside the components you’re putting into your connected devices. 

You need the right tools, and the current tools available for secure embedded development are lacking.  

Finite State’s robust Software Bill of Materials (SBOM) can help. Using Device Composition Analysis (DCA), our automated platform creates a comprehensive SBOM that can help you identify vulnerabilities in your products and provide actionable guidance.