Blog

Have you heard? CISA has recently released their guidelines for crafting a Software Bill of Materials.

Here's what your organization needs to know:

What is the SBOM Guidance?

Vulnerabilities are continuously disclosed in security advisories such as the National Vulnerability Database (NVD), the Common Vulnerability Exposure (CVE), as well as more directed advisories from national CERT agencies such as Cybersecurity and Infrastructure Security Agency (CISA), the Canadian Centre for Cyber Security (Cyber Centre) in Canada, or the EU's European Union Agency for Cybersecurity (ENISA). 

To effectively and efficiently address vulnerabilities across an entire organization IT security teams need a method of tracking digital components across assets to quickly identify vulnerabilities and prioritize mitigation efforts according to the impact they could have. Known as a vulnerability management program, this process is a complex orchestration of many interdependent activities. 

One of the most important components is maintaining an inventory of all assets in the organization's infrastructure including hardware and the software used on each device.  A Software Bill Of Materials (SBOM) is an inventory document that tracks the components that comprise an individual asset.  In today's article, we dive into what an SBOM is, its core purposes, and review CISA's recent guidance for building effective SBOMs.

What is a Software Bill Of Materials (SBOM) And What Is its Purpose?

A Software Bill of Materials (SBOM) is an inventory of all components, libraries, and modules that make up a piece of software, or that are present on a system, server including Embedded and Internet of Things (IoT) products, personal computers, servers. Essentially, an SBOM is akin to a detailed list of ingredients, providing transparency into the subject's composition and a reference for assessing its security. The most critical purpose that SBOM plays is in order to support the quick identification of vulnerabilities within a software application, system, or across an entire network of assets. 

SBOMs are also crucial for understanding the software supply chain, managing open-source components, and ensuring compliance with licensing requirements. SBOMs play a pivotal role in security, risk management, and software development practices. To accomplish these goals, an SBOM needs to uniquely and unambiguously identify components and their relationships to one another. 

Because SBOM contain all the relevant details about the names, versions, dependencies, and licenses of components, when a vulnerability is disclosed publicly in the National Vulnerability Database (NVD), Common Vulnerability Exposure (CVE) or another security advisory, cybersecurity team will already know whether it impacts them and where the affected components are in use.  An application or system's SBOM can be used to create a Vulnerability Exploitability eXchange (VEX) document that indicates whether a product or products are exploitable via any known vulnerabilities.  A VEX is essentially a security advisory built from an SBOM and some standard VEX formats include Common Security Advisory Framework Version (CSAF).

The formal standard for SBOM is maintained by  the National Telecommunications and Information Administration (NTIA) (part of the U.S. Department of Commerce) and is a community driven effort. Furthermore, the importance of SBOMs increased after the Executive Order on Improving the Nation’s Cybersecurity (Executive Order 14028) by the U.S. government in May 2021, which emphasized the for enhancing software supply chain security.  Here are the most prominent SBOM format standards used in the cybersecurity industry

• CycloneDX: Maintained by the OWASP Foundation (Open Web Application Security Project) and is designed primarily for use in application security contexts and software supply chain component analysis.

• SPDX: Developed by the SPDX Workgroup, part of the Linux Foundation. It is aimed at providing a standard way to communicate the components, intellectual property licenses, and copyrights of software packages.

• SWID (Software Identification) Tags: Defined by ISO/IEC 19770-2, SWID tags provide a standard for uniquely identifying and describing software products. These tags are designed to support software inventory and asset management processes, offering a detailed representation of software information including version, name, and publisher.

CISA's Guidance for Building a Software Bill of Materials

This section outlines CISA's guidelines for creating a Software Bill of Materials (SBOM) for assembled product lines, including both hardware and integrated software components. It details the mandatory and recommended elements necessary for documenting and tracking the components within these product groups effectively. The full advisory can be found here.

Required Information for a Product Line Build SBOM (PLB-SBOM)

• Choose an appropriate identifier for the subject of the SBOM (software product or asset)

• Adopt a versioning system for the chosen identifier.

• Catalog all components distributed as part of the product group

• Assign a version number to each component

• Reference the build SBOM that produced each component image included in the product group

Recommended Information for a Product Line Build SBOM (PLB-SBOM)

• Provide a hash for the artifact associated with each component to verify integrity and detect changes to integrity. This could be for individual files or their compressed contents (tarballs, zip files, container images, install packages, disc images, source files, etc.) and should account for any differences between machine architecture (e.g., x86, ARM) or other versioning differences.

• Include available identifiers (such as PURL, CPE, SWID tags) for each product component where suitable.

• The entity releasing the product line should be listed as the author of the PLB-SBOM data.

Conclusion

CISA has recently emphasized the importance of Software Bills of Materials (SBOMs) in enhancing cybersecurity across enterprises. SBOMs serve as detailed inventories of software components, enabling IT security teams to swiftly pinpoint and address vulnerabilities within their software supply chains and infrastructure. By maintaining an SBOM for each asset, organizations can effectively identify affected components when new vulnerabilities are disclosed, facilitating a proactive approach to cybersecurity. CISA's guidance outlines best practices for creating and utilizing SBOMs, highlighting their importance in vulnerability management programs. 

This move aligns with the broader cybersecurity strategy encouraged by the U.S. government's Executive Order on Improving the Nation’s Cybersecurity, underscoring SBOMs' pivotal role in securing software supply chains and managing software components' security and compliance.

Contact us today or join our newsletter for more cybersecurity education and implementation that goes beyond the checkbox.