SBOM 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 (Software Bill of Materials)?
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, SBOM security allows 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.
NTIA Minimum Elements for Meeting SBOM Requirements
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.
The 3 Categories of NTIA’s SBOM Elements
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.
Understanding Your Real SBOM Exposure with VEX
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.
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.
Automating and Building SBOM to Scale
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 is where teams do product security.
Device manufacturers such as Jaguar Land Rover, Supermicro, Danaher, and Faurecia use Cybellum’s Product Security Platform and services to manage product risk and compliance across teams and product groups. From Asset & SBOM Management to Assurance & Vulnerability Management, Regulatory Evidence Creation, and Incident Response, teams ensure their connected products are fundamentally secure – and stay that way.
By aggregating asset and risk data into a centralized management system that’s fully tailored to each customer, the platform enables assurance, risk management, and evidence creation for all business units and throughout the entire product lifecycle.
Additionally, Cybellum’s Managed SBOM Analysis Services combine analyst expertise with AI to provide high-quality SBOMs at scale.
FAQs
How do SBOMs facilitate vulnerability management?
Vulnerability management encompasses the entire process of identifying, prioritizing, and mitigating security vulnerabilities in software. SBOMs, or Software Bill of Materials, on the other hand are critical foundational components of vulnerability management.
SBOMs provide a comprehensive inventory of all software components and their dependencies, facilitating more effective vulnerability identification and management. SBOMs enhance an organization’s ability to effectively manage vulnerabilities by offering transparency into software composition.
The key differences between vulnerability management and SBOM are:
- The Scope: Vulnerability Management covers broader security activities. SBOM focuses on listing software components that vulnerability management activities are based on..
- The Purpose: Vulnerability Management reduces security risks. SBOM aids Vulnerability Management by detailing embedded software components.
- The Activities: Vulnerability Management includes scanning, prioritization of risks according to criticality and context, patching. SBOM deals with component identification and relationships.
Do SBOMs have a standard format?
The standard format for an SBOM can vary, but there are minimums set forth by the US federal government– more specifically CISA. They include information such as component names, versions, licenses, and dependencies in addition to supporting documentation such as VEX that identifies mitigated and known vulnerabilities as well as how to address them. Formats vary based on automation, tool compatibility, and industry regulations. (Learn more about SBOM & VEX Minimums)
The aim is clear, detailed software component information for security, compliance, and transparency. Common formats include:
- SPDX: Industry standard with structured data for components, licenses, and relationships.
- CycloneDX: Lightweight JSON/XML format listing components, versions, and licenses.
- Custom Formats: Tailored to specific needs, providing flexibility.
- SBOM Management Tools: Offer standardized SBOMs for widely-used components and continuously update them throughout a product’s lifecycle as components and versions change.
- Industry-specific Standards: Comply with sector-specific requirements
- Package Manager Manifests: Basic lists from package managers, a starting point for SBOMs.
What are SBOM use cases?
SBOMs have several crucial use cases in the realm of software development, supply chain security, and risk management. The primary use cases are:
- Enhancing Supply Chain Security: Identifying and mitigating software vulnerabilities in the supply chain.
- Supporting Vulnerability Management: Rapid detection of vulnerabilities, prioritizing patching.
- Ensuring Regulatory Compliance: Meeting compliance requirements by detailing software components.
- Promoting Transparency: Providing clarity on software composition, aiding trust and licensing checks.
- Facilitating Incident Response Teams (PSIRT): Speeding up incident response efforts by pinpointing compromised components.
- Ensuring Software Lifecycle Management: Tracking versions, updates, and planning for software maintenance.
SBOMs are vital for security, compliance, and transparency in software ecosystems, enabling proactive vulnerability management, compliance, and trust-building.
They enable proactive vulnerability management, support regulatory requirements, and promote trust in software products, making them an indispensable asset in today’s software-driven world.
Is an SBOM mandatory?
The necessity for an SBOM (Software Bill of Materials) varies based on factors such as industry regulations, supply chain security requirements, transparency goals, procurement agreements, industry standards, and the evolving landscape of software security.
In certain industries and regions, such as the automotive, medical device, industrial equipment manufacturing and critical infrastructure manufacturers SBOMs are either required or encouraged to enhance supply chain security and transparency. Beyond legal mandates, many organizations voluntarily adopt SBOMs as best practices for risk mitigation and compliance.
Suppliers may require SBOMs in procurement agreements to ensure software security and compliance. Industry-specific standards, like OWASP and CycloneDX, advocate for SBOM adoption. While not universally mandatory at present, SBOMs are gaining traction by both private entities and legislative bodies. Therefore, future mandates may arise as organizations increasingly recognize their benefits for secure and transparent software ecosystems.
What is the impact of SBOMs?
SBOMs, or Software Bill of Materials, wield considerable influence across various facets of software development and cybersecurity. Foremost, they fortify security by furnishing an exhaustive roster of software components, expediting vulnerability identification and management. This strengthens overall risk mitigation efforts.
Additionally, SBOMs expedite incident response by allowing Product Security Response Teams (PSIRT) to swiftly pinpointing compromised or susceptible software components, mitigating potential damage. They also enhance supply chain security by providing transparency into third-party software dependencies. In terms of compliance, SBOMs are instrumental in meeting regulations in various industries that require transparency and accountability.
How do you generate and manage an SBOM?
Generating an SBOM begins with compiling a list of embedded components and their versions from vendors, open source libraries if used, and any software developed in-house.
However, generating an SBOM only provides a snapshot of embedded software components at the time the bill of materials was compiled. Over the lifecycle of a device there will be updates, patches, component additions, and software removals. Relying on the Product Security Platform’s workflows, SBOMs are updated automatically to always reflect what’s in the device today.
Then, the Product Security Platform allows managers to track the SBOM validation process across all their business units and product lines, from the moment an SBOM is generated to the moment it is approved. Following that, product quality, product security, vulnerability management, and PSIRT teams can run the list of embedded software components against known vulnerability databases– identifying those that matter most and prioritizing others.
As mitigations are applied and existing versions updated, workflows continue to update the SBOM to ensure it is always up to date with what is relevant to specific embedded software components.
Generating an SBOM is an ongoing, integral part of software management, aiding in security, compliance, and transparency.
Why is SBOM management automation important?
SBOM management automation reduces the time and effort required to compile the inventory of software components. This allows managers to track the SBOM validation process across numerous teams and business units.
Properly managed SBOMs also help minimize the risk of human error and ensures consistency across large and intricate software systems.
Automation also allows for real-time updates, ensuring that SBOMs reflect the most current software composition. This is crucial for effective vulnerability management, as it enables timely identification and mitigation of security issues.
SBOM automation can seamlessly integrate with software development pipelines. This means that SBOMs are consistently generated as part of the software deployment process, eliminating missing or outdated SBOMs and ensuring compliance with regulatory requirements.
Automation is especially beneficial in handling the scale and complexity of modern software ecosystems. As software systems grow larger and more intricate, manual SBOM generation becomes impractical and error-prone.
Overall, SBOM automation saves time and costs, improves security, and enhances compliance efforts. It is a crucial component of contemporary software security and development strategies.