Register for the webinar Bridging the Board - CISO Gap

Software Bill of Materials (SBOM)

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.
Reasons why an SBOM is needed
Reasons why an SBOM is needed

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:

Minimum requirements of an SBOM as defined by NTIA (Image content source: NTIA)
Minimum requirements of an SBOM as defined by NTIA (Image content source: NTIA)

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?
Constituents of an SBOM
Constituents of an SBOM

 

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:

A table outlining the differences between CycloneDX and SPDX SBOM standards
A table outlining 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:

  1. Identify software components
  2. Determine component type
  3. Determine the versions and nested components
  4. Create the SBOM and review it
  5. 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:

  1. 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.
  2. 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.
  3. Balbix’s RVBM solution helps you to continuously assess, prioritize and dispatch software component vulnerabilities for mitigation.
  4. 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.

 

Frequently Asked Questions

What is in an 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).

In response to the Executive Order 14028, the National Telecommunications and Information Administration (NTIA) have defined the minimum elements for a SBOM. According to the NTIA guidelines, an SBOM should contain three broad, but interrelated categories of information:

  • Data fields (supplier name, component name, version, unique identifiers, dependency relationship, author, timestamp),
  • Automation support (data format standard like CycloneDX, SPDX),
  • Practices and Processes (frequency, depth, known unknowns, distribution and delivery, access controls, accommodation of mistakes)
Is an SBOM mandatory?

It is not mandatory for all organizations to have an SBOM. The importance of maintaining a SBOM gained momentum after the May 2021 U.S.Executive Order 14028, which included specific directives related to SBOM. The order requires software vendors to provide an SBOM for their software products. Organizations may be required to maintain an SBOM as part of their compliance with other regulatory or industry standards.

Why do we need an SBOM?

An SBOM is useful to both software consumers and software producers, the teams that operate and maintain the software. Some of the reasons SBOM is needed are:

  • Identifying vulnerabilities
  • Managing supply chain risk
  • Understanding dependencies
  • Improving software quality
  • Licensing compliance
Where is an SBOM stored?

Security and operations teams can store an SBOM in a variety of ways. Their chosen medium depends on their purpose, for instance, an SBOM can be stored in a spreadsheet or a text file as a reference. In terms of the structure used to store an SBOM, standard formats are used to  generate and share an SBOM with end users or customers. Two of the most popular SBOM formats are:

  • Software Package Data Exchange (SPDX)
  • CycloneDX.

Balbix supports full SBOM export for a given asset in two industry standard JSON formats: the Open Web Application Security Project (OWASP) Cyclone DX and Software Package Data Exchange (SPDX).

How do I make an SBOM?

The process for creating an SBOM is pretty logical. Here are some of the steps you might take to create an SBOM:

  1. Identify software components
  2. Determine component type
  3. Determine the versions and nested components
  4. Create the SBOM and review it
  5. Update the SBOM

Balbix makes it easy for you to export SBOM inventories in industry-standard formats. Balbix supports two formats: Open Web Application Security Project (OWASP), Cyclone DX, and Software Package Data Exchange (SPDX). You can export your SBOM inventory from Balbix to popular configuration management database (CMDB) tools.

How do you automate the management of an SBOM?

A variety of tools are available to help you automate the management of an SBOM. Software composition analysis (SCA) tools are designed to investigate the various components that make up a piece of software, including the source code, manifest files, container images, and binary files. Dependency scanners are another category of tools that can be used to scan a software product and provide an SBOM.

Balbix can also automatically provide an SBOM inventory including multi-level dependency mapping and the ability to export that mapping in industry standard formats. Balbix leverages package managers and live process analysis at run-time to perform a full dependency analysis of all installed software to provide a comprehensive inventory of software components (including open source and third-party packages). You can also use Balbix to detect and mitigate vulnerabilities in software components like log4j, Spring4Shell and OpenSSL at unparalleled speed and scale.

What is 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.

What is SPDX?

Software Package Data Exchange (SPDX) 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 software bill of material information, including provenance, license, security, and other related information.

Recommended Resources

EBook
How to Calculate your Enterprise’s Breach Risk
Guide
9 Slides Every CISO Must Use in Their Board Presentation
Case Study
Oerlikon Reduces Patch Time and Improves Management-Level Cyber Risk Visibility