The software bill of materials (SBOM) has become a standard to address a number of security concerns around much of the software commonly deployed in many organizations. From regulators in the federal government to contractors building apps, insiders agree that SBOMs provide the first line of defense against supply chain attacks and software vulnerabilities.

The SBOM—a listing of all the components inside a software product—can speed up the detection of remediation of known vulnerabilities and gives DevSecOps teams the ability to move fast and securely at a time when agile development is a must. Once an organization acquires an SBOM, whether it’s provided by a vendor or generated internally, the most important work lays ahead.

Does it meet your needs?

It’s not enough to list all the software contained in an application—the components and which versions are present —but all sorts of additional criteria should also be incorporated. For example, a quality SBOM should also include which repository the components came from and all the hashes and package URLs (PURLs) associated with those components, as well as Common Platform Enumeration (CPE).

Those detailed items are important for security operations staff to effectively scan for vulnerabilities and maintain continuous security. PURLs and CPEs are especially important for vulnerability lookups. PURLs function like a web address pointing to the repositories, while CPEs offer a way to look up vulnerabilities in the National Vulnerability Database.

How to Evaluate SBOMs

A number of tools are available to judge the quality of an SBOM, for example, scorecards for assessing whether it provides the basic requirements the organization needs, which may depend on the sector and industry vertical in which it operates. A comprehensive SBOM enables a proactive approach to security, rather than waiting for a vendor to communicate any known vulnerabilities.

As we’ve seen in many recent incidents, vendor attestation (VEX) is only one piece of the risk assessment puzzle the operational security team needs to manage. Trying to obtain vulnerability disclosure reports (VDRs) from vendors can range from frustrating to futile. This is one area where SBOMs provide valuable visibility and can give organization’s a leg up on maintaining their security posture.

Meanwhile, a relationship map can take an SBOM’s inventory of components one step further by identifying dependencies between components. For example, if an organization has deployed Adobe Acrobat (a very commonly-used PDF reader) to all its Windows desktops, it's not enough to have the SBOM for that program. It’s equally important to know if any relevant and required patches are installed on Windows, and which versions of Java may be deployed to work with it.

This kind of relationship mapping, tracking the hierarchies between components, helps winnow down which functions will be affected in case a vulnerability is detected in one component. In today’s complex environments, the discovery of one vulnerability can trigger a search across hundreds of components that could potentially be affected; with this map, it's easier to rule out those that are safe and instead focus on those that present risk and act more quickly to remediate them.

Effective SBOM Management

Modern software deployment is in many ways similar to nesting dolls that fit inside one another. Even commercial off-the-shelf software (COTS) can contain databases, each with its own list of components. DevSecOps needs to manage SBOMs collectively as a system, and the relationships and dependencies between them.

A few best practices should be top of mind with security teams managing SBOMs:

• ●Get them: SBOMs are no longer a luxury—they’re table stakes now. Depending on the industry, some vendors are meticulous about providing them, some are not. Enterprises need to advocate for SBOM adoption and demand them from vendors, to send a signal that this is to be expected in the normal course of business.
• ●Review them: Getting SBOMs from vendors is good air cover for regulation, but rating the quality of SBOMs is a first step to build a partnership with software suppliers. Use scorecard tools to assess the quality of SBOMs and the knowledge they provide to inform your response. If an SBOM falls short, it’s time to reach out to the vendor and ask them to enrich it with the information you will need to be proactive.
• ●Use them for continuous monitoring: SBOMs are a valuable tool for ongoing risk monitoring and security posture hardening. Management platforms that can consume multiple SBOMs to detect emerging threats, triangulate dependencies, and identify the provenance of components are vital to this process.

SBOMs have too much value to simply be viewed as a box-ticking exercise to appease regulators—especially for enterprises who supply the federal government. When used properly they can become a powerful defensive weapon against security threats. Treating them less as an inventory of software components and more as a tool to maintain supply-chain security hygiene is the first step.