SBOMs

National Institute of Standards and Technology (NIST)

Executive Office of the President. (2021). Executive Order 14028 on Improving the Nation's Cybersecurity.
See: https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity

"Section 10(j) of EO 14028 defines an SBOM as a “formal record containing the details and supply chain relationships of various components used in building software,[1]” similar to food ingredient labels on packaging. SBOMs hold the potential to provide increased transparency, provenance, and speed at which vulnerabilities can be identified and remediated by federal departments and agencies."  See: https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-security-supply-chains-software-1

SBOMs are Important for Cyber Security Risk Mitigation

Software Bill of Materials (SBOMs) are often describes as an inventory list of software components. This component list is increasingly important for helping identify components within a computer system with vulnerabilities.  

Cybersecurity risk associated with legacy and new software development has always been important but our reliance upon open-source software and third-party components changes the attack surface area. SBOMs enable organizations to assess and mitigate the risks associated with software dependencies, ensuring the security, reliability, and compliance of software products is maintained.

BOMs (as a generic use term) are important to resolving vulnerability identification and license compliance. As our understanding of BOMs increased, many new use cases have appeared. The role of BOMs has broadened and deepened to include hardware, cryptology, AI, systems and other types of metadata important to securing our computing environments.

SBOM Overview and History

Software Package Data Exchange (SPDX) 

The concept of software bill of materials supply chain dates back to 2010 when "SPDX” was announced as one of the pillars of the Linux Foundation’s Open Compliance Program. In 2011, the SPDX Version 1 specification was released to handle single packages. to review a complete history, See: https://spdx.dev/about/overview/

SPDX Version 3.0 was released in April of 2024 along with a name change to Systems Package Data Exchange (SPDX) to better reflect changing requirements. See: https://github.com/spdx/spdx-3-model

CycloneDX 

CycloneDX, like SPDX, is an evolving SBOM standard developed by Open Web Application Security Project (OWASP). 

"CycloneDX was designed in 2017 for use with OWASP Dependency-Track. An open-source Component Analysis Platform that identifies risk in the software supply chain. The primary use-cases CycloneDX was designed to solve were vulnerability identification, license compliance, and outdated component analysis. Additional capabilities were added in subsequent releases of the specification." See: https://cyclonedx.org/about/history/ and https://cyclonedx.org/docs/1.6/json/ 

SPDX and CycloneDX are key standards related to capturing SBOM information. Similarities and difference exist between the two standards. Most companies working in the SBOM space work with both standards for a variety of reasons.

Working with SBOMs

The Cyber Security and Infrastructure Agency (CISA) defines SBOMs as a nested inventory, a list of ingredients that make up software components. 

An SBOM list is a static document listing all the software found on a computing device. It is correct to assume there may be hundreds or thousands of packages on a device. Software developers are responsible for producing and providing SBOMs to customers. Developers may also be responsible for all included or upstream packages used in the development process.

In reference to the SBOM process image numbers below refer to the following:

1. Corporate inventory identification processes per device.

2. Accessing a vulnerability exchange service (VEX) to determine existing vulnerabilities. This is an ongoing process.

3. Employing a method for comparing one's software inventory with known vulnerabilities. (Unknow vulnerabilities may become known.)

4. Identified software with identified vulnerabilities needs to be analyzed to determine if the vulnerability is exploitable, establish a level of severity related to the potential exploit and define a course of action based on risk factors.

5. Manual intervention is the most common resolution method. A resolution process is determined. Software supplies patches may need to be requested based on the type, nature and severity of a vulnerability. 

(This drawing and explanation is an illustration of some of the steps involved with SBOMs, vulnerabilities and processes. Significant variation's exist by company, suppliers and venders.)

Security processes and use of SBOM concepts are evolving as part of a maturation process. Many issues need to resolved related to software naming, versions, licensing, modification, attestation and much more. 

Automation and use of BOMs in real time operations does not exist in the use or implementation of SBOM solution sets.

To learn more email info@smarttalkbeacon.com