Software Bill of Materials (SBOM). Four words you’ve most likely heard on repeat over the last few months. Why is this the case? Well, aside from the Executive Orders and Memorandums issued by the White House - which specifically call out the need for SBOMs in critical software - it appears the industry as a whole is starting to wake up to the very real problem(s) that come from a lack of visibility into our software supply chains.
This post is not meant to be a deep-dive into why SBOMs are important - there are plenty of great resources available that cover this topic in depth. Rather, as the title suggests, we are here to announce the release of enhanced SBOM functionality in the NetRise Platform which includes a host of exciting new features and enhancements that continue to equip our customers with the best resources for identifying risk in XIoT firmware. Before we get to that, however, I do think it’s worthwhile to discuss why generating SBOMs from compiled code (particularly firmware) is such a challenge, and some of the unique approaches that NetRise is taking to tackle this challenge. Of course, if you’re only interested in reading about the new features, feel free to jump ahead to the NetRise Platform Enhanced SBOM section below.
In order to avoid writing an 80-page whitepaper, let’s focus - at a high level - on two primary challenges: extraction of the firmware, and accurate identification of the underlying components.
Firmware Extraction
What do we mean when we talk about firmware extraction? Initially, it may sound like this refers to the acquisition of the firmware from a device or piece of hardware. While this terminology can indeed be used to refer to this process (which could be a blog post of its own), what we’re talking about in this context is getting from an “unknown” firmware binary to the root of what the heck type of firmware we’re actually dealing with. In the firmware world, there are hundreds of permutations of firmware type, file system, operating system, architecture, and more.
Given an unknown binary, you could be dealing with anything from a 5GB image with an embedded OS and multiple file systems, to bare-metal firmware where the code runs directly on the hardware, which has no OS or filesystem and only carries out a small number of very specific tasks. When conducting manual analysis of a sample, determining what type of firmware you’re looking at isn’t all that difficult (at least for folks that are well versed in reverse engineering arbitrary file formats); the real difficulty in building a firmware analysis platform is achieving this in an automated fashion. Sure, you can write signatures and specific support for certain firmware types, OSes, filesystems, etc., and build up support for different firmware samples over time, but at NetRise, we are taking a more agnostic approach to support any given firmware image, regardless of any of the aforementioned attributes. Again, this is something that humans can do quite well given an unknown sample, but doing this in an automated fashion is arguably the most significant challenge in this space.
Component Identification
After extracting the firmware, the next unique challenge is iterating through the underlying software components and accurately identifying what they are. Accurately identifying components is the most critical aspect of measuring supply chain risk - if you're not succeeding at this step, there's little value in what comes after. Before we dive into this topic, it might be worth first asking ourselves - what is a component? As it turns out, the answer to that question may not be so clear. One reason for this is something that we already discussed in the previous section - firmware varies so heavily from one sample to another; in an Embedded Linux firmware image a component might be an application (binary), library, framework, or other file, whereas in a Real Time Operating System (RTOS) or bare-metal firmware image, perhaps you could consider a function or particular section of code to be one component.
For the sake of simplicity, let’s focus this discussion on component identification for Embedded Linux firmware. Initially, one might think, “Embedded Linux is just a stripped-down version of Linux, right? So why would it be difficult to identify the applications and libraries that exist in the file system of an Embedded Linux image?” I myself wondered this when I was first introduced to the wild west that is the firmware space. If we identify a file named openssl, couldn’t we just hash that file and compare it to known hashes of openssl to determine what version of openssl we’re looking at? As it turns out - rather unfortunately - this is almost never the case due to one simple fact; almost every single device manufacturer recompiles the third party applications and other code that is used in their firmware images before building the final firmware image, which renders hashes essentially useless.
Okay, so hashes are no good, then how can we go about identifying components in firmware? Well, as many may have guessed, there are a multitude of strategies that can be used, all ranging in efficacy and efficiency. Without getting too far into the weeds, here are a few examples potential options for identifying components in firmware:
Signature-based methods
In some cases, simply searching the component data for signature-based matches can yield useful information for determining the identity and version of a component.
Emulation
When dealing with application or binary type components, one option for determining the version is to emulate and execute the binary, supply it with a -v or –version flag (or something similar), and see what you get. While this can actually be one of the more high fidelity options, it is also much more compute-intensive than many other methods.
- Some package managers will include package manifests which list installed packages and associated versions, which can be used to obtain a list of included software in a given firmware image.
- It’s important to note however that these are often not representative of what is actually on disk in a given image (depending on the type of manifest), and can be misleading.
- This is the primary component identification method that many SBOM tools on the market use.
- At NetRise, we certainly use these in our component identification as well, but package manifests make up less than 5% of the components that we identify, highlighting the need to use a multitude of component identification methods to get the whole picture.
The above list is far from exhaustive, but gives you an idea of a few of the approaches that can be taken regarding component identification.
NetRise Platform Enhanced SBOM
With some of those technical details out of the way - let’s get to the exciting stuff, and the primary purpose of this blog post. While the NetRise Platform provides much more than just a SBOM for firmware images, we certainly do consider SBOM to be one of the core features of the platform. As such, we’ve put a lot of thought and effort into creating the best SBOMs in the industry, which means a few things:
- Implementing industry-leading component identification
- Taking advantage of the CycloneDX and SPDX specifications to provide more than just the minimum SBOM elements
- Enriching our SBOMs with as much additional, actionable data as possible
- Providing an interface natively within the platform to efficiently interact with SBOMs, without needing additional tools
Over the last few months, our product team has been hard at work redesigning our SBOM features and workflows - both from a UI/UX and technical capability perspective - to provide an industry-leading SBOM that empowers our customers to conquer the difficult challenges regarding software supply chain visibility.
What Changed, and What’s New?
So, what exactly has changed, and what are the new features that come with our newly improved SBOM experience? Let’s explore the enhancements to both component identification and the user experience in the sections below:
Component Identification Changes
From a technical perspective, a number of things have changed regarding component identification. When we first developed our SBOMs, we made a conscious decision not to include any components which we were not 99.99% sure of (from both an overall identification and version identification standpoint). This stemmed from a desire to provide accurate SBOMs, even at the potential cost of seeming to identify fewer components than other tools on the market. After speaking with our customers, design partners, and industry groups, however, it became apparent that folks want to see everything in an SBOM, regardless of the degree of certainty of the version. As such, we are now including components which we may not be certain of the version. To support this, for every component and version that we surface in the SBOM, a confidence level will be displayed (which can also be used as a filter), so that the fidelity level of the version is apparent.
Additionally - and perhaps more excitingly - we have implemented a number of additional component identification methods. In addition to the methods that we mentioned in the Component Identification section above, we are also using some bleeding-edge, proprietary techniques - which leverage the machine learning and reverse engineering expertise of our product team - to identify components in ways that no one else in the industry is doing. To avoid a painfully long blog post (perhaps that ship has sailed), we’ll take a deep dive into all this awesome-ness in future posts.
All of these factors have led to an order-of-magnitude increase in the number of components that make their way into our SBOMs within any given image.
User Experience Updates
As we discussed previously, one of the goals of the NetRise Platform is to provide an interface for our customers to store and interact with SBOMs without needing to export them (though of course you can export, if that’s your preference) or use additional tools. To support this, we have also completely revamped our SBOM user interface to provide the most streamlined user experience possible, regardless of your particular goal or use case.
Some of the notable updates to our SBOM user interface include:
Quick Filter Options
The ability to instantly toggle filters to display certain component types, vendors, CVE severities, components with public exploits, license types, and more.
Component dependency mapping
View component dependencies and dependents natively in the NetRise Platform.
Direct links to associated files
Where applicable, you can instantly view, access and download associated files for a given component. Including if there are multiple files that make up one component.
Vulnerability prioritization data
All of the vulnerability prioritization data we already provide in the vulnerabilities section of our reports will be accessible directly from the SBOM and component view as well.
Of course over time our Platform as a whole, including our SBOM features, will continue to evolve but to say we are excited for this significant release is a huge understatement!
If you’re interested in learning more, or looking for a way to get a handle on your software supply chain - whether a device manufacturer or asset owner - reach out to us today and schedule a chat with our team!
SHARE