This article was originally posted on Solution Review.
Supply chain professionals should be familiar with a bill of materials (BOM), which is used to build quality products and support the procurement, inventory management, and resolution of problems involved in creating those products. A BOM is also used to manage parts and maintenance supplies when buying products. However, software procurement is often more concerned with licensing terms, security requirements, pricing, maintenance, and support needs. While the BOM concept for software procurement is relatively new, it is now becoming an essential piece of managing the software supply chain.
A Software BOM (SBOM for short), like a traditional BOM, is a list of third-party and open-source components that make up a software product. The SBOM is also responsible for listing the features that various subcomponents rely on and identifying licensing info, software versions, and vulnerabilities.
In the past, software was assumed only to contain code and intellectual property developed by the product vendor. However, modern software is no longer developed entirely from scratch and almost always contains third-party and open-source software components. These components may include potential security vulnerabilities the buyer could be introducing into their environment.
To put the problem in context, a study by Osterman Research found that 100-percent of widely used commercial software contained vulnerable open-source components. A worrying 85-percent of those analyzed applications had critical vulnerabilities which pose a significant security risk. The most vulnerable applications are daily email and online meeting applications, which is a problem because enterprise organizations widely use these applications and these vulnerabilities present a severe cybersecurity risk.
With many high-profile security breaches and attacks linked to purchased software, there’s now a heightened awareness of software supply chain security and the demand for SBOMs. The recent Presidential Cybersecurity Executive Order specifically identified the importance of improving the software supply chain. It spotlighted the critical need for SBOMs as a mandated prerequisite for software vendors doing business with the federal government.
While RFPs, RFIs, and vendor questionnaires are part of the procurement due diligence process, the vendor fills these documents, and the procurement team has to trust them. Meanwhile, an SBOM is a document of “truth” of what is actually in the software. Generally speaking, procurement departments are not expected to have technical knowledge of the software they purchase. However, it does help to understand what an SBOM should include so you can evaluate supplier SBOMs. At the very least, the components listed in an SBOM need to be well identified to have:
- Author Name: The author of the SBOM, usually the organization supplying the software.
- Supplier Name: The name of the software supplier and should include aliases. The supplier and the author might be different if the supplier makes a claim on the author’s behalf.
- Component Name: The name of the software component and possible aliases.
- Version String: The format of the version information is free for but should follow common industry usage.
- Unique Identifier: A unique identifier is needed for each component.
- Relationship: The relationship field defines the relationship between the component and the software package. In most cases, this relation is “includes,” as in software package X includes component.
It’s important to note that basic SBOM information doesn’t necessarily include any security information. To get the most out of SBOMs, they must contain vulnerability details such as:
- Severity and Impact: The report should indicate the severity of the vulnerability and possible impact if left unmitigated. There are standards for this, such as a CVSS score.
- Vulnerability Identifying Information: To be used by the security experts in your organization. You are looking for vulnerability details from publicly available databases such as the National Vulnerability Database. This will have IDs, severity, and information on the vulnerability.
- Description: A summary of the vulnerability associated with an identified component.
Now is the time to start getting more proactive in requesting SBOMs from your software vendors. This requirement is already becoming standard practice for U.S. federal government purchasing, as documented in the recent Executive Order on Cybersecurity.
SBOMs will soon become an important decision factor in software procurement since increased visibility into products being considered may expose risks organizations are unwilling to take. Regardless of the outcome, SBOMs will undoubtedly help buyers improve their security and risk posture to protect their supply chain organizations proactively.
