Introduction
Today’s products and devices are built on a complex combination of open source and third-party software components from a supply chain – in addition to the code created in-house. The increased use of software that isn’t developed in-house means that device and product manufacturers have little visibility into the risks in the code they are using, outside of what their providers disclose.
The need to gain visibility and control over supply chain risks gave rise to SBOMs (software bill of materials) – a regulatory requirement and an increasingly popular answer to the tricky question of visibility over all software assets in a device. But what does it take to generate an SBOM, what must it include, and how can it help teams address the quickly evolving threat landscape? Used correctly, automated SBOMs and continuous monitoring of threats can significantly increase development efficiencies and decrease device and product time to market.
What is an SBOM
Let’s start from the basics: what do we (and more importantly – regulations) mean when we talk about SBOM?
SBOM’s were initially proposed in 2018 by the U.S. Food and Drug Administration (FDA) as a part of the Premarket Submissions for Management of Cybersecurity in Medical Devices. They were then called a cybersecurity bill of materials (CBOM), emphasizing their importance for product security. The goal was to create a listing of all software and hardware components that made up a device. It allows organizations to effectively manage their assets and fully understand the risks of utilized software.
Supply Chain Security and the SBOM
The threat of software supply chain attacks have made the SBOM a critical part of ensuring supply chain security.
Over the past few years, software supply chain attacks have started dominating headlines. Considering how complex and multi-layered both software and supply chains have become – that’s no surprise. Today’s connected devices and products can rely on tens or even hundreds of software libraries, from multiple sources: some developed in-house, others purchased from third-party vendors, and added to the mix are open source projects.
Add to that the serious supply chain disruptions and outages caused by the pandemic, resulting in business-critical supply chain shortages. Supply chain delays and breakdowns push device and product manufacturers to seek new and unvetted suppliers, adding another set of challenges to supply chain risk management.
CASE IN POINT: SOLARWINDS AND LOG4SHELL
The 2020 SolarWinds supply chain attack that penetrated deep into the Federal government’s infrastructure and into some of the largest and most tech-savvy organizations, called into question exactly how much is known about the software that is utilized every day and makes up the foundation of products and devices .
Another sobering example of how ubiquitous third-party and open source components are in our software and devices was the critical vulnerability discovered in the wildly popular and ubiquitous Log4j open source Java library in late 2021. Once disclosed, the vulnerability made it glaringly clear the risk inherent in the open source components that are an integral part of our software products. The jaw-dropping number of exploit attempts via the vulnerability – within hours of its disclosure was an urgent reminder that visibility and control over open source components in our supply chain is a crucial part of vulnerability management.
When done right, SBOMs allow us to check and monitor components received through the supply chain, and manage threats and vulnerabilities before they become headlines.
President Biden’s Cybersecurity Executive Order (EO 14028) Made SBOMs a Must
In May 2021, in response to the increased threat of supply chain attacks like the SolarWinds breach, President Biden issued an executive order (EO 14028) on improving the nation’s security. EO 14028 called for organizations and federal agencies to work together to improve cybersecurity.
Part of this action was a recommendation for software developers to provide SBOMs to their customers. This software bill of materials includes information about libraries, add-ons, and custom source code utilized by an application.
SBOM Use Cases
While the Executive Order made it clear that regulation is increasingly requiring the use of SBOMs, some organizations still view regulation as a necessary evil that must be endured, rather than a tool that can boost their security and compliance strategies and processes. When used continuously, SBOMs can help product security teams detect and mitigate risks throughout the entire product lifecycle, from the earliest stages of development, to post-production.
Beyond being a regulatory requirement, SBOMs are a practice that’s critical to software or digital product manufacturers managing software supply chain risks. There are several use cases where an SBOM provides value.
Complying with Federal Requirements
After President Biden’s executive order, those providing software to the federal government need to provide SBOMs that detail the components utilized and the changes made between versions.
Reducing Risk for Software Consumers
SBOMs provide visibility into software composition, allowing organizations to verify that the software meets their compliance standards and security requirements and to assess risk. This is especially important for highly regulated industries such as healthcare, critical infrastructure providers/utilities, automotive, and finance.
Shifting Left to Bring Quality Products to Market More Quickly
Device manufacturers have high standards to maintain for their products and in many cases have limited capability to make changes post production. SBOMs allow them to track changes in upstream software to identify and remediate new vulnerabilities early in production when it is easier and less costly to remediate.
Supporting Mergers and Acquisitions
When acquiring a new company, businesses need to complete due diligence in investigating their investment before acquisition. Part of this process involves thoroughly assessing the risk of the purchase. SBOMs provide visibility into the software being used by the company in their product development, enabling a more accurate assessment of the products and devices.
First Steps to Meeting SBOM Requirements: NTIA Minimum Elements for an SBOM
The NTIA created guidance for the minimum requirements to help manufacturers get on board.
In July 2021, accelerated by cybersecurity EO 14028 and after years of hard work, the NTIA (National Telecommunications and Information Administration) published The Minimum Elements for a Software Bill of Materials (SBOM). The NTIA document provides a detailed list that maps out the minimal elements an SBOM must include, so that software developers, manufacturers, buyers, and users could get higher transparency and control over the complex and interconnected software they create and rely on.
In addition to providing the basic use cases for SBOM usage, like vulnerability management, and software inventory and licenses, the document was also created in order to start the conversation on future SBOM requirements and features, both for broader use cases, and for scaling operational use. The document was an important step towards reducing the attack surface of products and devices, as well as deepening the conversation and the standardization processes for suppliers and manufacturers.
The NTIA document creates SBOM standardization, enabling companies, supply chain vendors, and customers to set clear expectations, while shortening iteration cycles. By listing clear criteria of what is expected in an SBOM, the document’s guidelines help build visibility, trust, and security awareness amongst the players in the supply chain.
Working with “The Minimum Required Elements for an SBOM”
The NTIA’s minimum requirements are divided into three categories: data fields, automation support, and practices and processes. Let’s dive a little deeper into each one:
#1 DATA FIELDS
Since the purpose of the SBOM is to provide information about the software components, it makes sense that the first required element covers which data should be included about each component. This data can also be used for tracking the components across the software supply chain and mapping them to databases.
The NTIA defines seven baseline fields:
- Supplier Name – the component manufacturer
- Component Name – the name of the unit determined by the supplier
- Version of the Component – the release number or category determined by the supplier
- Other Unique Identifiers – additional unique data. The NTIA recommends using
- these to support mapping automation efforts across data users and ecosystems. For example, Common Platform Enumeration (CPE), Software Identification (SWID) tags and Package Uniform Resource Locators (PURL)
- Dependency Relationship – the upstream relationship of the component with other software
- Author of SBOM Data – the entity that created the SBOM data (not the software creator)
- Timestamp – when the SBOM data was assembled
#2 AUTOMATION SUPPORT
The NTIA also encourages the use of SBOM data across departments and organizations, to enable transparency, enhanced security, meeting with compliance standards, and more. In order to achieve this, SBOMs must be machine-readable, so these processes can be automated.
Unfortunately, there is no one SBOM format, but various data formats in use across the SBOM community have become quite common. The NTIA supports them and requires that SBOMs comply with at least one:
Ingesting data from up stream providers creates a challenge for those using SBOMs. This requires creating unique processes for each format to normalize and amalgamate data in one location.
For providers, formatting is essential for delivering consistency. Once a format is chosen, it should be adhered to as updates are a burden to consumers down the road. It may require them to change their ingestion processes to accommodate the updates.
#3 PRACTICES AND PROCESSES
Finally, the NTIA acknowledges that established organizational culture and processes are essential to ensure integration across all teams. To help, it defines the following guidelines that organizations should address:
- Frequency – new SBOMs must be created with every new product or device version. They should be recreated when updating data about a component or new code. At Cybellum, we call this a “living SBOM”, i.e an SBOM that represents the product accurately with every new update or release.
- Depth – SBOMs should contain all top-level components – with their transitive dependencies. These top-level dependencies should have enough detail to enable SBOM consumers to find other transitive dependencies. Over time, organizations will be able to provide more in-depth information.
- Known Unknowns – defining whether the dependency graph is complete, or if the dependency graph is unknown and incomplete.
- Distribution and Delivery – making SBOM data available to anyone that needs it, by making SBOM availability known, and ensuring the data can be retrieved and accessed.
- Access Control – access to SBOMs can be controlled, but the terms should be specified, including information on how to integrate the SBOM data into the user’s security tools.
- Accommodation of Mistakes – tolerance of errors and mistakes as SBOM practices are implemented, to enable improvement and evolvement.
VEX – a Critical Framework for Understanding your Real SBOM Exposure
While SBOMs are useful for helping organizations understand potential risks from third-party software components incorporated into a product, it does not grant insight into the actual exposure. To deal with this, the NTIA has proposed a Vulnerability Exploitability eXchange (VEX), which is a companion artifact to an SBOM. It allows device manufacturers to communicate the exploitability of a vulnerability discovered in one of its software components listed in an SBOM. This saves organizations from the need to work backward to determine if a vulnerability for a product listed in an SBOM affects them.
Using VEX allows OEMs to assess whether or not components they are using in their product with vulnerabilities are exploitable in the end product. Several factors might prevent a vulnerability from being exploited, such as:
- The final code may not actually execute any part of the library with the vulnerability
- Conditional compile statements have excluded the vulnerability from the final executable
- Current security controls prevent the vulnerability from being executed
In the above cases, despite a vulnerability existing in a component, it does not result in a vulnerability in the final product. This is an essential and time-saving piece of knowledge for developers. When this is the case, the vulnerability does not need to be further remediated; thus, no additional development time is wasted creating an unnecessary fix.
VEX is also helpful for asset owners that wish to verify the security of devices that vendors provide. In the past, it was complicated to discern what software components were used on a given device. It was almost impossible for an asset owner to know without the manufacturer telling them that the device is vulnerable to attack.
This was the case on many devices using the Treck TCP/IP stack. A Zero-Day vulnerability known as Ripple20 was discovered in the Treck library. This library was already deeply embedded in many devices.
Having a system such as VEX, product owners could have quickly learned that their systems were vulnerable, allowing them to take steps to mitigate it. This is especially important for industries such as Utilities, Medicine, and Government Agencies that are already major targets for malicious actors.
Being able to identify and remediate vulnerabilities quickly can make all the difference whether they become compromised.
VEX is conceptually similar to a context-based analysis system for determining if components of a digital system are vulnerable.
Advanced context-based analysis goes further in reducing the supply chain risk than VEX by incorporating the underlying hardware architecture, OS configurations, encryption mechanisms, keys, hardening mechanisms, full control flow, and API calls that are used. This allows for a more in-depth and accurate analysis of a given product.
Protecting the supply chain for development is an important factor in developing more secure products. Knowing what components are utilized is not enough. Instead, in-depth analysis is required to identify the vulnerabilities and determine their applicability.
VEX may not provide as in-depth an assessment as the context-based analysis; it is still helpful for defending against supply chain attacks. Using automated tools such as VEX combined with SBOM and context-aware vulnerability analysis is necessary to manage supply chain vulnerabilities efficiently.
SBOM AREAS THAT SHOULDN’T BE IGNORED
In order to increase transparency and visibility, the NTIA recommends supporting broader use cases with more elements, and encourages organizations to ask suppliers for them. These include:
- Additional data fields – hash of the component, lifecycle phase, other component relationships, and license information
- Cloud-based software and SaaS – creating and maintaining an SBOM for cloud providers, not just for on-premise software
- Integrity and authenticity – mechanisms to verify the source of SBOM data, like digital signatures
- Vulnerabilities – linking to external vulnerability data sources, instead of just relying on vulnerability data in the SBOM
- Vulnerability and exploitability in dependencies – determining the impact of a vulnerability on a software component and communicating this information downstream through VEX
- Legacy software and binary analysis – implementing binary analysis tools when SBOM data is not available, e.g. with legacy code
- Implementation flexibility/uniformity – combining broader rules and procedures with leeway in specific areas
WHAT DOESN’T THE NTIA’S DOCUMENT PROVIDE?
While the document goes a long way in helping companies gain visibility and control over their supply chain and software components, vulnerabilities and compliance risks, it’s worth noting that an SBOM will not solve all security issues. NTIA’s guidelines present a list for getting started now, and improving as we progress. Being a work in progress, it’s not comprehensive and the components on the list are not necessarily complete.
What Else to Look Out For: Threat Modeling and Risk Assessment
While detecting and managing vulnerabilities is a critical part of a cybersecurity strategy, there are other security risks product and device security teams need to watch out for, that can be detected through SBOMs:
- Debugging and remote access software that may be legitimate and vulnerability-free but are also considered risky software if a hacker can gain access to them. Careful consideration should be made when using them in connected products and devices.
- Unnecessary software packages, like a printing utility in a vehicle ECU, or drivers for unavailable hardware. These too might be legitimate and vulnerability-free, but should not be in the product if not needed – a malicious player could find a way to exploit them sometime in the future.
- Outdated and end-of-life software: software packages that are no longer supported, or have reached end-of-life could put the security of the entire product at risk. Careful consideration is required when choosing to use them.
Getting it right
Anyone that’s already started on their SBOM journey knows it’s not as easy as it sounds.
When it comes to connected products and devices, the task becomes that much more complex.
Just producing SBOMs manually is doable in theory, the practice is unwieldy if you have thousands of components, new software added all the time, software updates – just to name a few of the challenges in tracking increasingly complex and layered connected devices. This pretty quickly becomes an impossible task. To do it right, you need to automate the process and build it for scale.
Leveraging the SBOM for Ongoing Cybersecurity and Compliance
As the software behind our connected devices becomes increasingly complex and distributed, the first step towards protecting your entire product portfolio is knowing what it contains. SBOMs can provide a strong framework for the visibility that helps teams start the vulnerability detection and remediation process.
However, at the end of the day, an SBOM is a list of software components, and many businesses are rushing to generate SBOMs per current regulation guidelines. If businesses want to ensure their cybersecurity compliance as regulation continues to evolve across industries and global markets – the basic SBOM is just the first step.
There are many aspects to cybersecurity and compliance that a standard SBOM doesn’t include, like API calls, passwords, control flow, PII, cryptography, hardware bill of materials, licenses, and operating system configurations – to name a few.
Continuous cybersecurity compliance for a constantly increasing number of software components, must go beyond the basic SBOM containing a detailed list of software libraries and versions. Compliance requires vulnerability management that goes beyond detection and includes prioritization and mitigation of vulnerabilities – both CVEs and zero-day, during development and once products and devices are released to market, through continuous monitoring and incident response.
It’s important that these processes can be easily integrated into the tools and processes already in use, so that your teams can import SBOMs that have already been generated, or manually created elsewhere.
In a world where devices are becoming increasingly software-dependent, and supply chain threats – and regulations, dominate headlines, these essential cybersecurity practices can’t be done separately. Product and device development teams need a unified product security process that leverages the SBOM to address all cybersecurity compliance requirements quickly and efficiently.
Maximizing your SBOM investment with Cybellum
Cybellum provides product security teams with the platform they need to gain complete visibility and control over their products’ components, so they can keep their entire portfolio secure and compliant.
Powered by Cyber Digital Twins™ technology, Cybellum’s product security platform provides teams with an exact blueprint of their products’ components – including make-up, characteristics, and the context in which they operate. Cybellum’s Cyber Digital Twins enable teams to detect, prioritize, and mitigate licensing, compliance and security risks in real-time.
Cybellum helps organizations unlock the full potential of SBOMs, and leverage this investment to create a robust product security process that extends beyond a basic software bill of materials.