What Is SBOM? Why Software Component Inventory Is Gaining Momentum
Momentum Building for Software Bill of Materials (SBOM) Attestation
You’ve probably noticed the acronym SBOM popping up a lot recently—headlines and subject lines trying to liven up the subject with the notion of someone or something “dropping the SBOM.” Will software bill of materials (SBOM) become a household word in supply chain security management and compliance, and become a requirement in additional industry standards and regulations? Here, and in upcoming video podcasts, we’ll examine SBOM as a software system and supply chain auditing control and security and risk management measure, and discuss where cybersecurity, industry and regulatory pressures likely will further drive SBOM requirements and adoption.
The Definition and Origins of SBOM
The concept of a software bill of materials (SBOM) has been around since 2010, longer by some interpretations. It was formalized via the open source Linux community’s FOSSBazaar/SPDX project, which sought a way to create an open standard for communicating software bill of material information, including provenance, license, security, and other related information. SPDX along with a coinciding open-source OWASP security-oriented project have since developed into two different but common standards for helping to meet SBOM requirements across multiple industry and federal sectors. A decade and a half later, SBOM’s importance toward software security, compliance, and IT observability has only intensified.
Another influential SBOM predecessor was the software composition analysis (SCA) work of the late 1990s, which evolved from spreadsheets to more automated ways to track, secure and optimize software components. The software identification (SWID) tags proposed in joint ISO/IEC standard 19770-2-2015 also helped ultimately define SBOM.
A more recent pioneering force was The National Telecommunications and Information Administration (NTIA), which under EO direction, defined SBOM as early as 2018 as a nested inventory and list of software components, and “a formal record containing the details and supply chain relationships of various components used in building software.”
According to global IT analysis firm Gartner, “A software bill of materials (SBOM) is formally structured, machine-readable metadata that uniquely identifies a software package and the components used to build it — the components can be open source or proprietary. SBOMs are designed to track and share the details of software components and their supply chain relationships across organizations.”
Analogically, an SBOM is an example of a detailed systems parts inventory, not all that different from the ingredients on packaged food labels. In the case of SBOM, however, the listed ingredients under the package are things such as software supplier, software product name, version number, operating system, third-party components, cloud provider(s), license number, proof of certification, and all libraries, frameworks, and editions utilized in the software.
SBOM is a deep look into the components of the software you use, where all the parts are coming from, and the ability to report that toward vulnerability management and mutual software integrity in the supply chain. The bill of materials should include your software applications and dependencies, including those in the cloud. SBOM is a way to gain greater transparency and security control over all software parts, cloud SaaS ingredients included. SBOM hasn’t yet reached the status of a widespread required set of controls, domestically or internationally.
SBOM Standards: Guidelines vs. Requirements
Open source, industry, and commercial standards, formats and solutions for SBOM continue to develop, but SBOM is by no means just a private, B2B, or grass roots enterprise. Executive Orders (EOs), the Cybersecurity and Infrastructure Security Agency (CISA), and the National Institute of Standards and Technology (NIST) have all moved to encourage and, in some cases, mandate that federal agencies, critical infrastructure providers, and software supply chain partners provide SBOM transparency and attestation. Some of the important U.S. standards and legislation include:
NIST 800-53 cites SBOM as recommended practice for federal agencies handling Controlled Unclassified Information (CUI). NIST 800-171, SBOM attestation is required for contractors involved in the federal software supply chain and foundational toward FARs, DFARs and JSIG compliance. As NIST writes, “If a manufacturer is part of a DoD, General Services Administration (GSA), NASA or other federal or state agencies’ supply chain, the implementation of the security requirements included in NIST SP 800-171 is a must.” SBOM also has application toward NIST SP 800-161, which provides guidance for organizations to improve supply chain risk management (SCRM) through an ability to scan, detect, notify, and resolve vulnerabilities in the software and IT.
FDA requirements for SBOM are spelled out in Section 524(B)(c) of the FD&C. Section 524(B)(c) requires that manufacturers of medical cyber devices provide a software bill of materials (SBOM) for the commercial, open source, and off-the-shelf software components contained within the device.
The National Highway Traffic Administration (NHTSA) recommends SBOMs as a best practice for modern vehicle safety, particularly toward vulnerability identification and protection of the vehicles’ electronic control unit (ECU).
CISA. Although not a regulatory agency, CISA oversees information security policies and practices for Federal Civilian Executive Branch (FCEB) Agencies. CISA develops and directs information security parameters and works with federal agencies to enhance their cybersecurity and incident response postures. CISA specifies SBOMs and related Vulnerability Exploitability eXchange (VEX) attestation as key building blocks in software security and SCRM. More recently, CISA announced the release of its Secure Software Self-Attestation form in March 2024 to assess the SBOM capabilities of federal contractors.
FedRAMP. An SBOM requirement package fell off The Fiscal Year (FY) 2023 National Defense Authorization Act (NDAA), which would have made SBOM a FedRAMP requirement, but we may not have seen the end of these potential requirements for cloud providers serving federal IT.
Are there public standard formats to get started on SBOM?
CycloneDX, SPDX, and SWID are all listed by NTIA as an acceptable format. Each provides automation support for data field generation and process optimization.
The OWASP standard and format for SBOM we mentioned earlier evolved into CycloneDX in 2017. It is a broad popular tool that offers a general-purpose Bill of Materials (BOM) standard capable of representing software, hardware (HBOM), services, and other types of inventory.
The Software Package Data Exchange (SPDX), which started as an open source Linux Foundation project in 2010, was formally published as standard in August 2021 in ISO/IEC 5962:2021. By its very name, SPDX helps us to define the crux of SBOM: a software package data exchange that provides a foundation for retrieving information from a software system and the ingredients and dependencies of that software system.
CycloneDX and SPDX represent the most used SBOM formats, and there are additional methods such as generic SWID that can be used toward meeting SBOM standards. However, using these formats alone won’t deliver SBOM unless your inventorying processes, detection, and CVE scanning systems can report all your software components and their vulnerabilities.
As the NTIA put it, “SBOM will not solve all software security problems, but will form a foundational data layer on which further security tools, practices, and assurances can be built.”
SBOM Security Benefits
The global SBOM market is valued at somewhere between several hundred millions to billions of U.S. dollars. It has developed to help the commercial and public sectors account for the security and validity of their software components through tools, templates and other solutions. The market is expected to grow as voluntary efforts, B2B agreements, and federal and other requirements further develop.
By adding SBOM capabilities to intrusion detection and SIEM solutions, organizations and agencies can derive the following benefits:
- Easier IT service management / IT asset management. Facilitate the inventory and administration of IT, software, and software applications in a standardized SBOM and reporting format.
- Enhanced software security and integrity. Scan for and detect vulnerabilities including CVEs, expired certifications, and missing patches in your software systems.
- Stronger supply chain risk management (SCRM). Gain greater insight into the integrity of the third party software in your supply chain. The transparency works two ways, enabling partners to understand the risk their software may pose and what they, in turn, may be ingesting from other supply chain members or integrators.
- Evolving compliance capabilities. Be able to meet NIST 800-171, NIST 800-161, JSIG, FDA FD&C Act Section 524(B)(c) requirements, and develop your SBOM capabilities for looming or future requirements.
- Software development and DevSecOps. Again, it’s all about the ingredients. SBOM can help software development organizations maintain the integrity of the components they use to build, maintain, and integrate software.
SBOM Success Factors
During SBOM tool evaluation, determine if the SBOM tool or solution can:
- Satisfy customer and partner requests for transparency. Software users and supply chain partners may request to know the composition of your software. Can you accurately audit and report not just the name and version of the software but the component programs and API dependencies, and whether software is certified and CVE-free?
- Address or adapt to the growing requirement for machine-readable SBOM formats. This automated process makes it far easier to generate and consume SBOM reports while reducing manual administration and total cost of operation.
- Support different use case scenarios. Industry and federal compliance guidelines and regulations vary in their specifications; so, too, can software partners’ SCRM, SBOM and licensing requirements. Look for SBOM tools that inventory and monitor software, identify vulnerable artifacts, and display findings in a common format, regardless of disparate operating systems, programming languages, or your demanding custom SBOM use case scenarios.
- Facilitate active response and compliance. Knowing the ingredients of your software and software ecosystem is a promising start to supply chain integrity, but it isn’t in itself a complete cybersecurity and compliance solution. Be able to to turn on XDR engine capabilities such as AV, intrusion detection, file integrity monitoring (FIM), CVE scanning, audit and accountability (AU) controls, and automated response rules to ensure and protect the defined SBOM elements and software integrity in general.
Discover why organizations are turning to Atomicorp to help them with their SBOM attestation and SCRM.
– Visit www.atomicorp.com
Discuss your SBOM, detection, response, and compliance needs with us.
– Check out the Atomic OSSEC page and request a demo.
Contact us to discuss SBOM and other security and compliance objectives.