Recent research shows that the majority of software produced today is not written from scratch, but rather cobbled together from existing software components or libraries. An SBOM, or Software Bill of Materials, is an itemized list of components that make up a software application. Bills of materials have been in use in the manufacturing industry for decades in order to track the required inventory for production and ensure replicability in the outputs. For those familiar with DevOps, this manufacturing analogy may sound familiar. In the same way manufacturers judiciously manage the parts for building products, SBOMs help developers track their dependencies in a more shareable format and align third party library usage across application teams and reduce wasteful “component sprawl”.
Our focus in this piece is the benefit of SBOMs to product security. The application security community has long recognized the risk involved in using vulnerable components. In 2013 the famous OWASP Top Ten introduced “A9 Using Components with Known Vulnerabilities”. A9 recommends organizations “Continuously inventory the versions of both client-side and server-side components (e.g. frameworks, libraries)”. Understanding the components in an application, especially which of those are vulnerable, reduces the work required to then secure that application before and after a security incident.
Depending on how you arrived at this post, you may have never heard of an SBOM before. But you are also probably wondering why you have never heard of one before. While the term SBOM is largely new, the concept is straightforward. Among developers package managers have this same library itemization capability at the core of their functionality. However, more recently, Software Composition Analysis (SCA) tools have begun leveraging this SBOM concept to provide digestible reports of components for security use cases. These reports can be shared throughout an organization via a centralized versioning repository. This then enables a plethora of teams to leverage the SBOM contents in their workflows including: Application Security, Threat Intelligence, the Security Operations Center (SOC), Supplier Security, Developers and Internal Audit teams.
With value for so many teams, a natural question is, “how does one get started with SBOMs in his/her organization?” The first step to utilizing SBOMs is generating them, which can be done using developer IDE plug-ins and SCA tools. After the SBOM has been generated, the information needs to be distributed effectively. You might consider forwarding these SBOMs to your organization’s data lake or knowledge management system. Downstream consumer teams in the security organization or elsewhere can then pull this information from the central repository to ensure they have up to date and accurate information.
In any case: start small. You will want to segment the adoption of SBOMs across development teams and the security functions we discussed above. Rather than a sudden mandate that SBOMs be created by every application team across the organization, start small with a select group. Understand roadblocks, ensure the knowledge base is utilized effectively, and ask downstream consumers what could be improved. Learn. Then expand the refined process out to the rest of the organization. Security champions programs are effective vehicles for spreading such practices.
SBOMs are a low level of effort mechanism to improving the efficiency of various teams in the security organization. Despite their benefits to various groups, Application Security teams are chiefly responsible for recognizing their value and initiating their adoption. In order to do that, Application Security teams need only reflect on a belabored security mantra: you can’t secure what you can’t see.