Understanding Software Bill of Materials (SBOM) and It’s Role in Software Supply Chain

In May 2021, the US government signed an Executive Order mandating that software suppliers selling to the government must include a Software Bill of Material (SBOM) in their software. This move was made in response to the increasing trend of supply chain attacks, which increased by a staggering 650% from 2020 to 2021.

Why Do We Need SBOM?

Modern software often includes open source components that vendors do not have to disclose. In fact, as per estimates, open source code can be found in as much as 80-90% of all modern software. While it is common for vendors to rely heavily on modules and libraries already developed and available as open source for various portions of their code, they do not have to disclose what was used or why. This means that organizations are completely unaware of whether they are running affected code on their systems when attacks occur.

The lack of transparency in the software supply chain makes it difficult for organizations to respond quickly to attacks. The need for supply chain transparency was critical in the fight against attacks on open source code. The Executive Order signed by President Biden would aim to make software bill of materials a standard for all software vendors.

What is an SBOM?

In response to the US Executive Order, the National Telecommunications and Information Administration (NTIA) formally defined an SBOM and the minimum requirements it must include. According to NTIA, an SBOM is “a formal, machine-readable inventory of software components and dependencies, information about those components, and their hierarchical relationships.”

In simple terms, an SBOM is a bill of materials that lists all the software components, modules, packages, libraries, and dependencies that make up a software. The inventory list should be comprehensive and include any dependencies or libraries from which code was used.

SBOMs in Cybersecurity Programs

As more organizations and government agencies around the world begin to demand more transparency from their software vendors, SBOMs have quickly emerged as a key building block in software supply chain risk management and cybersecurity programs. SBOMs enable organizations to measure risk and respond quickly to attacks.

In conclusion, the implementation of SBOMs is a significant step towards ensuring transparency in the software supply chain, reducing the risks of supply chain attacks, and strengthening cybersecurity. It is essential for software vendors to embrace SBOMs to help organizations mitigate cyber threats and strengthen their security posture.

NTIA Requirements for SBOMs

The National Telecommunications and Information Administration (NTIA) mandates seven requirements that must be included in a software vendor’s bill of material. These requirements are:

• Supplier name
• Component name
• Version number
• Other unique identifiers
• Dependency relationship
• Author of SBOM data
• Timestamp

Furthermore, the SBOM itself must be in a standardized format, such as SPDX, CycloneDX, or SWID tags. These formats are machine-readable, making it easy for other tools and processes to use them. SBOM inventory tools are one example of such tools that help catalog all of the software components being used by various applications on your network. These tools are extremely beneficial in telling you which of these components may have open vulnerabilities.

It’s important to note that the SBOM must be generated for every new code release from the software vendor. Each software release should include its own report that was included to make the software for that given release.

Third-Party SBOM Tools

Third-party SBOM tools provide tremendous value in the software industry. These tools not only visualize the SBOM reports and make them human-readable but can also keep inventory of all your software and correlate components with potential vulnerabilities. This is important because SBOMs only tell you what software is made up of, but third-party tools can take it a step further to provide vulnerability reports of those specific components.

In addition to the SBOM requirements, third-party tools may provide a cross-reference to known CVE numbers, CVSS scores, severity, and other detailed information. If a vulnerable component is found in the application, these tools can immediately tell you your risk and other vital information.

Moreover, most organizations have tens or even hundreds of business-critical applications. This makes the need for a centralized inventory and tracking of vulnerabilities in real-time even more critical, as doing so manually is nearly impossible.

Benefits of SBOMs

SBOMs have many benefits, in particular for organizations that rely on several different software to run their organization. Recent supply chain attacks are perfect examples of why SBOMs are needed. The slow response from organizations that did not know they were actually running Log4J is part of the impact that it had. Log4j, like so many other open source vulnerabilities of the last few years, was embedded in so many vendor applications that it made it a nearly impossible task to know your exposure without a vendor disclaimer.

However, organizations using SBOMs and third-party tools tracking their software inventory can centrally locate vulnerable components and mitigate the risks. A good SBOM tool should alert you of new vulnerabilities before the vendor can provide a disclaimer or patch.

Another major benefit is that it provides transparency about the software components and versions that a vendor may be using. Applications using old, outdated, and possibly vulnerable modules will be visible for everyone to see. While we would all like to think that vendors update their modules and internal components to patch against the most critical vulnerabilities, this is often not the case. In fact, the longer a software vendor has been around, the tighter the dependencies may be to old modules that were used early on in the design phase, leaving them often ignored.

Conclusion

In summary, software supply chain attacks are becoming more common and more sophisticated, and they can have serious consequences for organizations. To mitigate the risks, the NTIA has issued guidelines that require software vendors to produce an SBOM for their products. The SBOM must contain key information about the software components used, and it must be provided in a standardized format that is machine readable.

Third-party SBOM tools can add further value to the SBOM process by providing vulnerability reports and cross-references to known CVE numbers, CVSS scores, severity, and other information. These tools can help organizations to centrally locate vulnerable components and to mitigate risks, and they can also alert organizations of new vulnerabilities before vendors can provide a disclaimer or patch.

*** This is a Security Bloggers Network syndicated blog from The CISO Perspective authored by [email protected]. Read the original post at: https://cisoperspective.com/index.php/2023/02/21/understanding-software-bill-of-materials-sbom-and-its-role-in-software-supply-chain/