What is a Software Bill of Materials (SBOM)?

SBOMs in Software Supply Chain: Lessons Learned from the XZ Utils Backdoor

The XZ Utils backdoor case, identified as CVE-2024-3094, involved a malicious backdoor inserted into a widely used Linux utility. This vulnerability was discovered by Andres Freund just before its integration into main Linux distributions, putting millions of servers at risk. The researcher found this vulnerability before it went to production, preventing any actual harm. While SBOMs didn’t play a role in this specific instance, they would be crucial if the vulnerability had gone into the wild, as seen with Log4j in 2021. In a widespread vulnerability like Log4j, SBOM platforms could effectively help in understanding the blast radius and conducting impact analysis. If the XZ Utils vulnerability had been deployed, tools like Scribe Hub could have been instrumental in alerting companies, enabling them to search their software inventory, block the deployment of compromised versions, and enhance their overall security posture.

Definition of Software Bill of Materials

The software bill of materials (SBOM) lists all component parts and software dependencies involved in the development and delivery of an application. SBOMs are similar to bill of materials (BOMs) used in supply chains and manufacturing. There hasn’t been a common feature for all vendors in the IT industry to accurately describe the foundational code components on which an application is built.

Typical SBOM would include licensing information, version numbers, component details, and vendors. A formal list of all the facts decreases risks for both the manufacturer and the user by allowing others to understand what’s in their software and act accordingly. SBOMs aren’t new to the software industry, but they’re becoming increasingly vital as development becomes more sophisticated and expensive. They’ve lately become a basic requirement in a number of businesses.

Securing Cloud-Native Apps: The Power of Enhanced SBOMs

The rise of cloud-native applications has introduced increased complexity in securing modern software environments. These applications, characterized by their dynamic and distributed nature, comprised of interconnected microservices and external components, increasing the attack surface. Enhancing SBOMs becomes critical in this context, as they provide detailed visibility into all components and dependencies within a cloud-native architecture. An effective SBOM helps identify vulnerabilities, ensures compliance with security standards, and facilitates rapid incident response. By leveraging robust SBOMs, organizations can maintain a comprehensive inventory of their software assets, track changes, and detect potential security risks early. In the era of cloud-native applications, enhancing SBOM practices is indispensable for bolstering security and maintaining the integrity of complex software ecosystems.

Benefits of the SBOM

Deals with Threats to Integrity

Assaults may happen at any point in a normal software supply chain, and these attacks are becoming more visible, disruptive, and expensive in today’s world. Integrity can be maintained using an SBOM by verifying that the components and files that appear in it are the same as were intended. For example, one of the components of the CycloneDX format is a hash value that can be used in the exact matching of files and components. As an SBOM is not a static document, it should be updated anytime there is a change in the described software or its components.

Allows visibility of Product Components

Companies must create client trust to generate loyalty and promote repeat purchases. Rather than assurances or promises, shared SBOMs provide enhanced visibility into the quality of the technologies they use.

Allows for easier Vulnerability Scanning

Companies may use SBOMs to identify and eliminate vulnerabilities before they reach production. New vulnerabilities in production software can be fixed quickly. SBOMs, in the end, aid engineers in discovering and resolving security flaws more quickly.

Leverages Licensing Governance for Your Product

Software Bill of Materials adoption can help enhance software licensing governance. Every piece of software comes with a license that specifies how it may be used and distributed legally. The constituent components of a supply chain that make up a full application might have a variety of different licenses. Any business that uses the program is legally obligated to follow the licensing. There may be no way to determine what the licenses need or how to comply with them without a software bill of materials.

Principles of a Well-Formed SBOM

A well-formed SBOM’s minimal components are divided into three categories:

Data Fields

The purpose of these fields is to provide adequate identification of these components. This allows you to monitor them over the software supply chain and relate them to other useful data sources, such as vulnerability or license databases. Some examples of data fields are supplier name, component name, version of the component, other unique identifiers, dependency relationship, author of SBOM data, and timestamp.

Automation Support

Organizations that want to keep a close eye on SBOM component data will require it provided in a consistent and easy-to-understand style. This is addressed in the SBOM basic requirements section under “Automation Support”. When sending SBOMs across organizational boundaries, there are three standards to choose from:

1. Software Package Data Exchange (SPDX)
2. CycloneDX
3. Software Identification (SWID) Tags

These are further discussed a little later in this article.

Practices and Processes

Finally, the “Practices and Processes” section lays out six standards for how and when SBOMs should be updated and supplied. They are as follows:

• If the software component is upgraded with a new build or release, new SBOMs must be produced.
• Authors of SBOMs should include top-level components as well as their transitive dependencies.
• If the SBOM doesn’t offer a complete dependency tree, the SBOM author should explain whether this is because (a) the component has no more dependencies, or (b) the existence of dependencies is unknown and incomplete.
• SBOMs must be distributed and delivered in a “timely” manner, with “proper access rights and roles in place”.
• Companies that want to keep some components of an SBOM secret must specify access control parameters, which would contain specific rules and procedures for incorporating SBOM-related information into the user’s manual and tools. To put it simply: if there’s something that must be kept secret for the organization’s sake, then the process of keeping it secret is defined in this section. 
• Because the standards controlling SBOM generation are new, SBOM users are advised to forgive (unintentional) faults or omissions.

Different SBOM Formats

Of course, you may manually generate an SBOM bill by listing out the many components inside the software you’ve produced. However, maintaining huge codebases with dozens or even hundreds of dependencies and third-party components is a tiresome and time-consuming task, especially for developers who manage large codebases with multiple third-party components and dependencies. Some developers may have included third-party components in an application without documenting it. As a result, current developers may not be familiar with the entire codebase.

To make adoption a reality, SBOMs must adhere to industry-accepted standards that allow for interoperability between diverse sectors and organizations. Organizations already have the architecture in place to develop, manage, and distribute software component data, thanks to a few standards.

SPDX: Software Package Data Exchange

The Software Package Data Exchange (SPDX) is the primary open standard for Software Bill of Materials formats developed by the Linux Foundation in 2010. Software components, copyrights, licenses, and security references are all included in SPDX files. The SPDX specification is compatible with the NTIA’s proposed SBOM minimum standards and use cases. Organizations can use SPDX Lite to exchange data since it is a condensed version of the SPDX standard. The SPDX got an official standard as ISO/IEC 5962 in August 2021.

spdx document

SWID: Software Identification Tagging

The International Organization for Standards (ISO) began establishing a standard for marking software components with machine-readable IDs before the end of the decade. SWID tags, as they’re now known, are structured embedded metadata in software that transmits information such as the name of the software product, version, developers, relationships, and more. SWID Tags can aid in automating patch management, software integrity validation, vulnerability detection, and permitting or prohibiting software installs, similar to software asset management. In 2012, ISO/IEC 19770-2 was confirmed, and it was modified in 2015. There are four main types of SWID tags that are used at various stages of the software development lifecycle:

1. Corpus Tags: These are used to identify and characterize software components that aren’t ready to be installed. Corpus tags are “designed to be utilized as inputs to software installation tools and procedures”, according to the National Institute of Standards and Technology.
2. Primary Tags: A primary tag’s purpose is to identify and contextualize software items once they’ve been installed.
3. Patch Tags: Patch tags identify and describe the patch (as opposed to the core product itself). Patch tags can also, and often do, incorporate contextual information about the patch’s relationship to other goods or patches.
4. Supplemental Tags: Supplemental tags allow software users and software management tools to add useful local utility context information like licensing keys and contact information for relevant parties.

When it comes to determining which tags and precise data pieces to offer with their products, businesses have considerable leeway. In addition to the mandatory data, the SWID standard specifies a number of optional components and characteristics. Finally, just a few characteristics that characterize the software product (such as name and Tag ID) and the entity that generated it are required for a basic valid, and compliant tag.

CycloneDX

In 2017, the OWASP Foundation released CycloneDX as part of Dependency-Track, an open-source software component analysis tool. CycloneDX is a lightweight standard for multi-industry use, with use cases like vulnerability detection, licensing compliance, and assessing old components. CycloneDX 1.4 was launched in January 2022. Cyclone DX can handle four different types of data:

• Material Flow Chart Metadata: It contains information on the application/product itself, such as the supplier, manufacturer, and components described in the SBOM, as well as any tools used to create an SBOM.
• Components: This is a comprehensive list of both proprietary and open-source components, together with license information.
• Services: Endpoint URIs, authentication requirements, and trust boundary traversals are all examples of external APIs that software can use.
• Dependencies: include both direct and indirect connections.

Source: CycloneDX

What Does an SBOM Look Like?

For risk identification, a thorough and accurate inventory of all first-party and third-party components is required. All direct and transitive components, as well as the dependencies between them, should be included in BOMs. For example, the following types of components can be described using CycloneDX:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "serialNumber": "urn:uuid:3e673487-395b-41h8-a30f-a58468a69b79",
  "version": 1,
  "components": [
    {
      "type": "library",
      "name": "nacl-library",
      "version": "1.0.0"
    }
  ]
}

XML format:

<?xml version="1.0" encoding="UTF-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.4"
     serialNumber="urn:uuid:3e356687-875b-78f5-a30f-a9754ka69j79"
     version="1">
    <components>
        <component type="library">
            <name>nacl-library</name>
            <version>1.0.0</version>
            <!-- The minimum required fields are:
            component type and name. -->
        </component>
        <!-- More components here -->
    </components>
</bom>

Why Sign Your SBOM?

What is a Digital Signature?

A digital signature is exactly what it sounds like: an electronic version of the traditional paper and pen signature. It checks the validity and integrity of digital communications and documents using a sophisticated mathematical approach. It ensures that a message’s contents are not tampered with while in transit, assisting us in overcoming the problem of impersonation and tampering in digital communications. Digital signatures have increased in adoption over time and are a cryptographic standard. 

How Digital Signatures Work

Digital signatures are created using public-key cryptography, also known as asymmetric cryptography. A public key approach such as RSA (Rivest-Shamir-Adleman) generates two keys, one private and one public, leading to a mathematically related pair of keys. One of the core mechanisms behind digital signatures is hashing. It effectively transforms data into a fixed-size output regardless of the size of the input. This is done through hash functions which are basically algorithms, and the output they produce is called a hash value. Cryptographic hash functions generate a hash value that acts as a digital fingerprint, making it unique for everyone. Like how everyone’s fingerprint is different, different input messages will generate different hash values. Public key cryptography (PKC)’s two mutually authenticating cryptographic keys are mainly used for digital signatures. The creator of the digital signature uses a private key to encrypt signature-related data, and that data can only be decoded using the signer’s public key. This is how a receiver knows that the sender is not compromised, and the received data is correct. Currently, dealing with public key infrastructure is costly and complicated as people often lose their private keys like one would lose their physical keys. Certificate Authorities (CAs) act as trusted third parties and issue digital signatures by accepting, verifying, issuing, and maintaining digital certificates. CAs help prevent fake digital certificates from being created. It also validates the trust service provider (TSP). A TSP is a person or legal entity that validates digital signatures on behalf of a company and communicates the results of the validation.

Benefits of a Digitally Signed SBOM

A signed SBOM provides a checksum, which is a long string of letters and numbers that represent the sum of a piece of digital data’s accurate digits and can be compared to find faults or changes. A checksum is similar to a digital fingerprint. On a regular basis, it checks for redundancy (CRC). Changes to raw data in digital networks and storage devices are detected using an error-detecting code and verification function. As a digital signature is meant to serve as a validated and secure way of proving authenticity in transactions – that is, once signed, a person cannot claim otherwise – it holds all signatories to the procedures and actions laid out in the bill. 

Problems with an Unsigned SBOM

As one of the core purposes of digital signatures is verification, an unsigned SBOM is not verifiable. Think of it as a contract: if a contract hasn’t been signed by participating parties, there’s no real way to enforce it. Similarly, an unsigned SBOM is just an unsigned document: your customer cannot hold you accountable.  This can also lead to further problems down the road, as an unsigned SBOM can also pose risks for your organization’s security. Anything that might have otherwise been protected by a signed SBOM is now not protected, and therefore data and information can be sent or replicated anywhere. One of the main purposes of signed SBOMs – accountability – is lost when an SBOM is unsigned as changes can then be made to it without consequences from the creator’s or client’s sides. 

Using SBOM for Enhancing Cybersecurity

SBOMs are amongst the best ways for organizations to maintain the safety and authenticity of their data and procedures. They also set a precedent in the industry by increasing openness between developers, software suppliers, and clients. Organizations can safely tell partners of operational details throughout the contracting process if standards are in place. Organizations will be more successful in identifying flaws, vulnerabilities, and zero-day threats as SBOMs become more widespread. Software Bill of Materials adoption is a clear gain for software supply chain security all over the world.

Using VEX To Gain More Usability Out of Your SBOM

Vulnerability Exploitability eXchange (VEX) is a security advisory aimed at exposing the exploitability of vulnerabilities in the context of the product in which they are found. When running a vulnerability scan on most modern applications the results could easily be in the hundreds or thousands of vulnerabilities. Out of the total number of vulnerabilities discovered only about 5% are actually exploitable. It’s also important to remember that exploitability is almost never a stand-alone issue. More often than not it’s a complex use-case of open-source libraries, modules, and the code that uses them working together that turn a vulnerability into an actually exploitable problem. Until you change your application and run a new SBOM to describe it, the inventory described in a BOM will typically remain static. The information on vulnerabilities is much more dynamic and liable to change. Having your VEX information available as a stand-alone list makes it possible to update VEX data without having to generate and manage additional BOMs. CISA provides a list of the recommended minimum data elements that should be included in a useful VEX advisory or document. These are:

VEX Metadata: VEX Format Identifier, Identifier string for the VEX document, Author, Author role, Timestamp. 

Product Details: Product identifier(s) or Product family identifier (e.g., unique identifier or a combination of Supplier name, product name, and version string, as laid out in established SBOM guidance3 ). 

Vulnerability Details: Identifier of the Vulnerability (CVE or other identifiers) and vulnerability description (e.g. CVE description). 

Product Status Details (i.e., status information about a vulnerability in that product): 

• NOT AFFECTED – No remediation is required regarding this vulnerability.
• AFFECTED – Actions are recommended to remediate or address this vulnerability.
• FIXED – These product versions contain a fix for the vulnerability. 
• UNDER INVESTIGATION – It is not yet known whether these product versions are affected by the vulnerability. An update will be provided in a later release.

Overcoming the Challenges of SBOM Adoption

Incorporating SBOM into an organization’s software development life cycle (SDLC) presents several challenges. First, generating and maintaining accurate SBOMs can be time-consuming and expensive, requiring significant investment in tools and processes. SBOM challenges also include integrating SBOM management with existing CI/CD pipelines, which may involve streamlining CI/CD pipeline integration. Additionally, ensuring the completeness and accuracy of SBOMs demands meticulous tracking of all software components, including third-party dependencies. Another significant hurdle is fostering a culture of transparency and security awareness among development teams, which is crucial for the successful adoption of SBOM practices. Overcoming these SBOM challenges requires a strategic approach, combining robust tools, effective training, and strong organizational commitment to enhance software supply chain security.

Summary

In conclusion, while SBOMs are still a novel idea for most organizations, the ability to produce SBOMs is expected to become more significant in the future. If you haven’t already started incorporating SBOM creation into your software delivery process, this is a great moment to do so.