What is a Software Bill of Materials (SBOM)?
A software bill of materials (SBOM) is a nested inventory, a list of ingredients that make up software components, according to the U.S. Cybersecurity & Infrastructure Security Agency (CISA).
The idea of SBOM is derived from the term ‘bill of materials (BOM),’ that has its origins in the world of manufacturing. Think of a BOM as an extensive list of raw materials, components, and instructions required to construct, manufacture, or repair a product or service. There are various reasons a BOM is needed. At a fundamental level, a BOM helps organizations get visibility into the parts that constitute a physical product. This knowledge helps manufacturing units proactively plan, purchase and control inventory. It also minimizes production delays, and in case of any quality issues, it also helps with effectively managing a recall process.
The present day software is built on the foundation of a complex supply chain of software components, much like the manufacturing components that rely on a robust supply chain process.
Why is an SBOM important to cybersecurity?
While the modern approach to architecting applications greatly accelerates delivery and reduces cost, it also presents a critical cyber risk management problem due to a lack of visibility into the software components. If the software has a vulnerable component, it can pose a risk to the cybersecurity posture of the organization using the software.
An analogous situation would be the purchase of a box of cereal without knowing if it contains nuts, wheat, soy, or other standard ingredients. If you are allergic to nuts, then consuming it could harm you. Listing the ingredients on the package could be critical to preserving your health.
These risks are not just hypothetical. Let’s look at a real-life example:
In Dec 2021, the world was hit with a vulnerability that was widely regarded as the most serious security flaw. Yes, we are talking about the Log4Shell vulnerability that was based on the Java logging library, Log4j.
A couple of things are worth noting about the Log4Shell vulnerability:
- Ubiquity: Log4j is everywhere as it is a part of the Apache/Java ecosystem. Most mission critical applications, IT tools, cybersecurity tools and the enormous number of the applications connected to the internet use Log4j.
- Existence in many forms: One peculiar thing about Log4j is that it exists in software in many forms, as (1) a library resource, (2) a JAR file in a third party application or (3) embedded in a custom application.
Both these factors make it hard for organizations to identify and mitigate affected Log4j instances. Since the Log4Shell vulnerability was discovered, organizations across the world have struggled to find answers to questions such as:
- How do I know if I am impacted?
- Where is the component used?
- What is the impact if the vulnerability is exploited?
- What is my mitigation path?
- How long would it take to mitigate completely?
Software component vulnerabilities like Log4Shell can be serious. When Log4Shell emerged, many of our customers, including a Fortune 100 company, contacted us for urgent assistance. Fortunately, at Balbix, we were in a position to help. We had the ability to produce a software bill of materials (SBOM) on demand for these application packages and applications. And we have continued to help as additional critical software component vulnerabilities have been identified (like Spring4Shell and OpenSSL).
The ubiquity of open source software components and its potential impact on your security posture is highlighted in the 2022 Open Source Security and Risk Analysis Report:
Of the 2,409 codebases analyzed by Black Duck Audit Services for this year’s report, 97% contained open source. Eighty-one percent contained at least one known open source vulnerability.
The importance of managing software supply chain vulnerabilities is also cited in the United States’ President issued Executive Order 14028. It states that, “an initial step towards its goal of ‘enhancing software supply chain security’ is transparency”. And further adds that, “The trust we place in our digital infrastructure should be proportional to how trustworthy and transparent that infrastructure is, and to the consequences we will incur if that trust is misplaced”. An SBOM advances transparency in the software supply chain, similar to a “list of ingredients.”
In essence, for software components vulnerabilities, if you don’t know what components constitute the software you use, you won’t know what you need to patch. This lack of visibility into software components could result in a rapid increase in your cyber breach risk that catches you unaware.
Having an SBOM can help you improve your cybersecurity posture by providing you with visibility into the software components used in your environment. This knowledge, combined with efficient vulnerability management practices can allow your security team to quickly and accurately evaluate the risk posed by software component vulnerabilities and implement a remediation plan.
Why is an SBOM needed?
An SBOM is useful for both software consumers and software producers, the teams that operate and maintain the software. Let’s now look at a few reasons why an SBOM is needed:
- Identifying vulnerabilities: By providing a comprehensive list of all software components and their versions, an SBOM can be used to help identify vulnerabilities that need to be addressed.
- Managing supply chain risk: By providing visibility into a software product’s components, an SBOM can help security teams prioritize and mitigate potential software supply chain security risks.
- Understanding dependencies: An SBOM makes it easier for developers and operators to understand dependencies across components. This knowledge can help software developers identify opportunities to optimize the software and reduce its complexity.
- Improving software quality: Having knowledge about software components, and the component versions allow organizations to ascertain if they have the most recent component versions. This helps organizations avoid issues with earlier versions of components, and improve overall quality.
- Licensing compliance: An SBOM ensures that organizations are aware of software components and dependencies. Using this information, compliance with licensing agreements can be verified.
What’s in an SBOM?
An SBOM generally includes information such as software component version numbers, the source of the component (e.g., a specific open source project or commercial vendor responsible for creating the component), supply chain relationships between the components and any licenses or other legal agreements that apply to the component.
In response to the U.S. Executive Order 14028 mentioned above, the National Telecommunications and Information Administration (NTIA) have provided a more formal definition for the minimum elements in an SBOM. According to the NTIA guidelines, the SBOM should contain three broad, but interrelated areas: data fields, automation support, and practices and processes.
Let’s look at each of these areas in more detail:
Data fields provide the fundamental information required to enable identification and tracking of software components. That minimum required data fields are listed in the image below:
Automation Support: This requirement ensures that the SBOM is available automatically, in a machine readable format. It can help the software consumer in a variety of use cases such as incorporating software component information into their vulnerability management processes, and development processes like troubleshooting.
Example of data formats that support automation include:
- Software Package Data eXchange (SPDX)
- CycloneDX
Practices and Processes: Practices and processes define the operational aspects and mechanics of how an SBOM is used. They consist of the guidance specific to the following questions:
- Frequency: How often, and under what conditions, should SBOM data be updated?
- Depth: Should the SBOM show only top-level dependencies, or multi-level dependencies too?
- Known Unknowns: If the full dependency tree is not available, then how does the software vendor convey “known unknowns”?
- Distribution and Delivery: How is the SBOM delivered and distributed? Who should have access to its content?
- Access Controls: Are there any software component vendors who have asked for their SBOM data to be kept private and confidential?
- Accommodation of Mistakes: The area of SBOM is constantly evolving, this element calls for software consumers to be tolerant of ‘growing pains’ and the occasional incidental error. Are software suppliers regularly sending updates to the SBOM by offering corrections without the fear of penalty?
SBOM Standards: CycloneDX and SPDX
There are a number of issues that you or your security and operations teams need to think through to ensure the widespread consumption of SBOM for cybersecurity and other key use cases, for example:
- How do I automatically create and maintain an SBOM?
- How do I facilitate widespread adoption of an SBOM?
- How do I organize an SBOM for distribution?
- How do I organize software components in a way that IT tools can understand?
- How can I use an SBOM as part of a continuous integration/continuous delivery (CI/CD) pipeline?
This is where SBOM standards help.
Think of an SBOM standard as a format that defines a unified structure for generating SBOMs and sharing them with end users or customers. It is a representation that describes the composition of a software application.
Two of the most popular SBOM formats are:
- Software Package Data Exchange (SPDX)
- CycloneDX.
CycloneDX:
CycloneDX is a lightweight Software Bill of Materials (SBOM) standard designed for use in application security contexts and supply chain component analysis. CycloneDX is an Open Web Application Security Project (OWASP) project. OWASP is the world’s largest non-profit organization concerned with software security. It works to improve the security of software through its community-led open source software projects.
Software Package Data Exchange (SPDX):
The SPDX specification is an international open standard (ISO/IEC 5962:2021), an open source project hosted by the Linux foundation. SPDX is an open standard for communicating SBOM information, including provenance, license, security, and other related information for software components.
The following table outlines the differences between CycloneDX and SPDX SBOM standards:
SBOM Myths vs Facts:
There are a few common misconceptions about SBOM. Let’s demystify seven key myths:
Myth #1: SBOM is difficult to generate and maintain.
Fact: The process for creating an SBOM is pretty logical. Here are some of the steps you might take to create an SBOM:
- Identify software components
- Determine component type
- Determine the versions and nested components
- Create the SBOM and review it
- Update the SBOM
It is difficult to generate and maintain SBOMs if these steps are executed manually every time. But, the good news is that there are tools available to ease the process of generating and maintaining an SBOM. A few example categories for these tools are: software composition analysis (SCA); binary code analysis; and cybersecurity posture automation solutions, like Balbix.
Myth #2: It is not possible to generate a near real-time SBOM
Fact: One of the disadvantages of traditional SBOM tools is that they need to be configured and run each time you need to generate or view changes to the SBOM. This approach doesn’t provide real-time visibility into the SBOM. However, it is possible to generate SBOM in near real-time for your environment. For instance, Balbix leverages package managers and live process analysis at run-time to perform a full dependency analysis of all installed software in order to provide comprehensive visibility of software components (including open source and third-party packages) in near real-time.
Myth #3: An SBOM is only necessary in specific industries like financial services and healthcare
Fact: Financial services and healthcare industries were early adopters of the SBOM. But, given the importance of an SBOM for identifying and mitigating software component vulnerabilities, it can be useful in an industry. It can also be useful to track and manage software components for products or systems of any size, including those of relatively small size and scope.
Myth #4: An SBOM is only useful for compliance purposes
Fact: While compliance is one of the key applications of an SBOM, its usefulness extends far beyond simply meeting regulatory requirements. For instance, an SBOM can help organizations track and manage the components in the software they use, which helps them to identify and address vulnerabilities in those components, in turn improving their overall security posture. An
Myth #5: An SBOM is only relevant for open source software
Fact: Open source components are widely used in modern software development. An SBOM is often used to track the components of open source software (OSS) but they are not limited to tracking just OSS. An SBOM can also be used to track the components of proprietary code, binaries and libraries. An SBOM is an effective tool for tracking and managing all software components regardless of their origin.
Myth #6: An SBOM helps you solve all your software component security problems
Fact: Unfortunately, there is no silver bullet. An SBOM alone does not solve all your software component security problems. However, it does provide you with visibility and the foundational knowledge of the software components in your environment. When you combine an SBOM with other tools, such as the risk based vulnerability management capabilities of Balbix, your security team can accurately assess the risk associated with software component vulnerabilities and speedily remediate them.
Myth #7: Even if you have an up-to-date SBOM, it is quite difficult to remediate vulnerable software components
Fact: From a cybersecurity standpoint, having near real time visibility of your SBOM is important but not enough. It is also critically important to prioritize and remediate assets with software component vulnerabilities. There aren’t many tools which can help you quickly identify and respond to vulnerable software components. With its SBOM capabilities, Balbix makes it easy to search and remediate software components vulnerabilities.
For more SBOM myths and facts, review this resource from NTIA.
How can Balbix help?
Traditional scanning tools have limitations when it comes to identifying vulnerabilities in software modules.To get visibility into module vulnerabilities, organizations can use more advanced vulnerability assessment methods.
Typically, generating an SBOM is hard, particularly for large and complex software applications that are made up of many different components. Without access to the source code, it can be difficult to identify all of the components that make up the software, as well as the respective version numbers.
Balbix’s cybersecurity posture automation platform helps address these challenges, and more. Balbix recently extended its cybersecurity posture automation solution to include the SBOM, including multi-level dependency mapping and an ability to export that mapping in industry standard formats. There are four ways Balbix can help your security team:
- Balbix provides a near real-time inventory of your SBOM so your security and IT teams know exactly which software components (and versions) are deployed in your environment, including installation location and the full path and version of the software components. Balbix uses package managers and live process analysis at run-time to perform a full dependency analysis of all installed software.
- Balbix identifies vulnerable assets by combining CVE data, information from the SBOM inventory and additional asset inventory information (including ports, services, related environment variables, etc) to infer software component vulnerabilities with high accuracy and speed.
- Balbix’s RVBM solution helps you to continuously assess, prioritize and dispatch software component vulnerabilities for mitigation.
- Unlike other CAASM vendors, Balbix supports full SBOM export for a given asset in the Open Web Application Security Project (OWASP) Cyclone DX and Software Package Data Exchange (SPDX), the industry standard JSON formats. This capability allows you to export the SBOM inventory from Balbix to popular configuration management database tools (CMDB) tools like ServiceNow using industry standard formats.
