Tech Insights / Software Bill of Materials

Software bill of materials: Enhancing cybersecurity through software inventories

Today’s application ecosystem is more sophisticated than ever before. What may have been a more rudimentary amalgamation of internal codebases in the past, today’s applications depend on a variety of third-party services, open source software stacks, and internal codebases to power these sophisticated applications. Add on top of this the growing proliferation of applications within today’s enterprise business, and the management of these applications and the software components within these applications becomes a sizable task. This is where the software bill of materials (SBoM) comes into play.


What is a software bill of materials (SBoM)?

A software bill of materials is a list of an application’s dependencies, such as third-party services, software packages, open source software stacks, and codebases. These SBoM go further than simply maintaining a list of dependencies by managing software dependencies in an automated, machine-readable manner. This unique approach provides organizations with an intuitive inventory of software components, allowing them to track application changes and identify and remediate vulnerabilities. Further, with a healthy SBoM, organizations can easily share the list of application dependencies, enhancing the efficiency of development teams.

The vital role of SBoM in cybersecurity

An SBoM not only provides an effective way to inventory application dependencies, but it’s also a critical component for today’s cybersecurity initiatives. With an SBoM, every individual, department, or partner has access to a comprehensive list of software services. Now, when a software vulnerability is identified, patching and remediating the vulnerability is simple—just locate the specific third-party service, software package, open source software stack, or codebase listed in the SBoM and make the proper remediations.

SBoM and the software supply chain

The software supply chain, although different from an SBoM, is another critical software management strategy used in today’s enterprise business. A software supply chain accounts for a set of procedures or steps required to deliver a piece of software to production. Rather than a list of software dependencies represented by the SBoM, a software supply chain may include creating and maintaining an SBoM as one of the unique steps to package and deliver software to production.




Building and maintaining a software bill of materials

Although each organization may take a unique approach to developing and maintaining the SBoM, there are some common design patterns that organizations can follow to increase the likelihood of a successful, efficient deployment. This is, in itself, a best practice, as a company should align on a consistent format to use, as well as on trusted tools for creating the SBoM. That way, teams don't have to spend cycles evaluating the tools themselves.

There are some common pillars to building and maintaining an SBoM:

  • Engage key stakeholders. One of the more challenging aspects of developing an SBoM is getting all key stakeholders involved. Consider that executive leadership, development leadership, and the entire development team now need to follow a new process for identifying and cataloging software dependencies. Without complete compliance, software dependencies can go uncategorized, exposing vulnerabilities and increasing security risks.
  • Collect SBoM content. Building and maintaining the SBoM begins with the development team. Here, developers and managers lead the initial stages of building and maintaining the SBoM by gathering all of the current software components to be included.
  • Software analysis tools. Software analysis tools, such as software composition analysis (SCA) and binary composition analysis tools, can help augment the efforts of the development team in gathering and processing software dependencies. These tools can audit software and identify code dependencies that may have otherwise been missed.

Required components of a software bill of materials

SBoM need to follow a predefined scaffolding for how software dependencies are identified, characterized, and maintained. A common list of required components provided by the National Telecommunications and Information Administration (NTIA) is as follows:

  • Author name: The author of the SBoM document describing the Primary Component; the author may not be the same as the supplier of the Primary Component
  • Supplier name: The supplier of a component
  • Component name: The name of the component
  • Version: The version of the component
  • Component hash: A cryptographic hash used to identify the binary instance of a component; it has not been investigated yet by the Healthcare POC, and is currently not provided in the SBoM content
  • Unique identifier: A unique identifier for a component; multiple identifiers may exist for a component because different systems may use a different identifier
  • Relationship: Used to establish that a component is included in another component

SBoM lifecycle and best practices

Each and every SBoM is going to look somewhat different depending on the unique requirements of the organization. There are, however, some key SBoM lifecycle and best practices that can be shared among organizations to deliver the best application dependency management policy.

  • Automate the creation. Generating a SBoM in an automated fashion is critically important for today’s modern software development practices. First and foremost, the more automated the SBoM process, the less time your development team needs to design, develop, and maintain the SBoM. Furthermore, automation processes that can come out of the SBoM generation process limit the risk of human error.
  • Lean on CI/CD development. Building on the concept of automating an SBoM, any automated process can work synergistically with an existing continuous integration/continuous development (CI/CD) approach. CI/CD is a DevOps design pattern that automates the building, testing, and deployment of applications to a production environment.
  • Leverage metadata. When developing an SBoM, lean on your development team to add as much metadata as possible regarding the software dependencies. Metadata might include information regarding the software license, patches, who developed the package, and other key indications. By adding as much metadata as possible, organizations deliver more useful data to systems and individuals using the SBoM down the line.
  • Update the SBoM. Updating is another key differentiator that organizations can leverage to make the best use of their SBoM initiative. An SBoM should be updated every time significant changes are made to the application, such as patches, updates, or new releases. Set appropriate standards regarding updating so as to not fall into the trap of an outdated SBoM.

Software bill of materials examples and tools

Having a well-maintained SBoM isn’t just a nice-to-have; it’s a requirement in today’s sophisticated business ecosystems. Understanding some of the use cases for SBoMs can give organizations a better understanding of just how valuable these data management tools are. Here are a couple of the most common use cases for an SBoM:

  • Maintaining compliance: Maintaining an SBoM is now a requirement for organizations selling to the federal government per the Presidential Executive Order on Improving the Nation’s Cybersecurity. This marks a major change in how the U.S. government views the importance of clearly managed and maintained SBoMs.
  • Enhanced security: An unfortunate aspect of today’s application ecosystem is that a large majority of applications contain vulnerabilities. A recent report from Osterman Research found that upwards of 85% of applications contain critical vulnerabilities. Maintaining an SBoM is one way of tracking vulnerabilities, thereby allowing organizations to get ahead of their security initiatives.
  • Historical record keeping: Whether it’s for performing due diligence on the technical aspects of an application or to identify which applications use an application package, maintaining a historical record of application dependencies is critical.



Enhance your cybersecurity SBoM stack with Tanzu

With Tanzu, achieving a secure software supply chain supported by an SBoM couldn’t be easier. Tanzu Application Platform is a modular, application-aware platform that helps developers build and deploy software on any compliant public cloud or on-premises Kubernetes cluster. Application design spanning the public cloud or on-premises Kubernetes cluster requires a secure software supply chain.

Tanzu Application Platform includes a rich set of features to enhance the security of your software supply chain:

  • Supply Chain Security Tools - Scan enable automated source and image vulnerability scanning, as well as configuration of policies to block critical vulnerabilities.
  • Supply Chain Security Tools - Store is a centralized metadata store that can be configured to automatically store SBoMs and vulnerability metadata. Centralized storage of dependency information is an important step to enabling fast and easy identification of where dependencies are used.
  • Vulnerability scans review source code and container images for vulnerabilities. Any identified vulnerabilities flowing through the software supply chain are captured and notified to application operators.

You can also take a look at Tanzu Build Service, which leverages Cloud Native Buildpacks to automatically generate SBoMs for Java- and Node.js-based projects. Tanzu Build Service v1.3 includes a kpack/cosign integration that allows users to configure their build system to sign container images at time of build.