The May 2021 executive order from the White House on improving U.S. cybersecurity includes a provision for a software bill of materials (SBOM), a formal record containing the details and supply chain relationships of various components used in building a software product.
An SBOM is the full list of every item that’s needed to build an application. It enumerates all parts, including open-source software (OSS) dependencies (direct), transitive OSS dependencies (indirect), open-source packages, vendor agents, vendor application programming interfaces (APIs) and vendor software development kits.
Software developers and vendors often create products by assembling existing open-source and commercial software components, the executive order notes. It’s useful to those who develop or manufacture software, those who select or purchase software and those who operate the software.
As the executive order describes, an SBOM enables software developers to make sure open-source and third-party components are up to date. Buyers can use an SBOM to perform vulnerability or license analysis, both of which can be used to evaluate risk in a product. And those who operate software can use SBOMs to quickly determine whether they are at potential risk of a newly discovered vulnerability.
“A widely used, machine-readable SBOM format allows for greater benefits through automation and tool integration,” the executive order says. “The SBOMs gain greater value when collectively stored in a repository that can be easily queried by other applications and systems. Understanding the supply chain of software, obtaining an SBOM and using it to analyze known vulnerabilities are crucial in managing risk.”
An SBOM is intrinsically hierarchical. The finished product sits at the top, and the hierarchy includes all of its dependencies providing a foundation for its functionality. Any one of these parts can be exploited in this hierarchical structure, leading to a ripple effect.
Not surprisingly, given the potential impact, there has been a lot of talk about the proposed SBOM provision since the executive order was announced. This is certainly true within the cybersecurity community. Anytime there are attacks such as the ones against Equifax or Solarwinds that involve software vulnerabilities being exploited, there is renewed interest in this type of concept.
Clearly, the intention of an SBOM is good. If software vendors are not upgrading dependencies to eliminate security vulnerabilities, the thinking is we need to be able to ask the vendors to share their lists of dependencies. That way, the fear of customer or public ridicule might encourage the software producers to do a better job of upgrading dependencies.
However, this is an old and outmoded way of thinking. Modern applications and microservices use many dependencies. It’s not uncommon for a small application to use tens of dependencies, which in turn might use other dependencies. Soon the list of dependencies used by a single application can run into the hundreds. And if a modern application consists of a few hundred microservices, which is not uncommon, the list of dependencies can run into the thousands.
If a software vendor were to publish such an extensive list, how will the end users of that software really benefit? Yes, we can also ask the software vendor to publish which of the dependencies is vulnerable, and let’s say that list runs into the hundreds. Now what?
Clearly, having to upgrade hundreds of vulnerable dependencies is not a trivial task. A software vendor would be constantly deciding between adding new functionality that generates revenue and allows the company to stay ahead of its competitors versus upgrading dependencies that don’t do either.
If the government formalizes an SBOM mandate and starts to financially penalize vendors that have vulnerable dependencies, it is clear that given the complexity associated with upgrading dependencies the software vendors might choose to pay fines rather than risk losing revenue or competitive advantage in the market.
Revenue drives market capitalization, which in turn drives executive and employee compensation. Fines, as small as they are, have negligible impact on the bottom line. In a purely economic sense, the choice is fairly obvious.
In addition, software vendors typically do not want to publish lists of all their dependencies because that provides a lot of information to hackers and other bad actors as well as to competitors. It’s bad enough that cybercriminals are able to find vulnerabilities on their own. Providing lists of dependencies gives them even more possible resources to discover weaknesses.
Customers and users of the software, for their part, don’t want to know all the dependencies. What would they gain from studying a list of hundreds of dependencies? Rather, software vendors and their customers want to know which dependencies, if any, make the application vulnerable. That really is the key question.
Prioritizing software composition analysis (SCA) ensures that when dependencies are analyzed in the context of an application, the dependencies that make an application vulnerable can be dramatically reduced.
Instead of publishing a list of 1,000 dependencies, or 100 that are vulnerable, organizations can publish a far more manageable list in the single digits. That is a problem that organizations can much more easily deal with. Sometimes a software vendor can fix an issue without having to upgrade the dependency. For example, it can make changes in the code, which is not always possible if we are merely looking for the list of vulnerable dependencies.
There is no reason to disdain the concept of SBOM outright. By all means, let’s make the software vendors responsible for being transparent about what goes into their software products. Plenty of organizations have paid a steep price because of software vulnerabilities that could have been prevented in the form of data breaches and other cybersecurity attacks.
Indeed, it’s heartening to see the federal government take cybersecurity so seriously and propose ways to enhance the protection of applications and data.
However, let’s make SBOM specific to the list of dependencies that actually make the application vulnerable. This serves both the vendor and its customers by cutting directly to the sources of vulnerabilities that can do damage. That way, we can address the issues at hand without creating unnecessary burdens.
