The new importance of knowing what your software is made of

Software systems in the modern world are built upon a complex set of dependencies of different components. Just like building a car requires a complex supply chain, so does software. The importance of the software supply chain has grown immensely over recent years. There have been numerous vulnerabilities found in software components, and companies need to know what their software is made of.

This is applicable to creators, vendors and consumers of software

This applies to all sorts of companies:

  1. Companies that create software need to know what components they are using.
  2. Companies that consume software from other vendors need to know what components the software is made of.

Customers now demand to know

Companies that consume software wanting to know the composition of software they use is a relatively new situation, as in the past companies would buy / subscribe to software and just use it. However, a series of incidents, such as Log4j vulnerabilities, WannaCry ransomware, Heartbleed OpenSSL vulnerability, the Equifax breach due to Apache Struts remote command injection, and so on, have created *really* high level momentum to bring software supply chains under control.

SBOMs are becoming mandated

A US Presidential Executive Order, Executive Order 14028, https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity has been issued which means that anyone who supplies software to the US Government needs to provide a Software Bill of Materials (SBOM) outlining what components are in a piece of software. This is a wake up call that organizations need to be on top of their software supply chains.

So, if you supply Government, and likely other organizations in the future, you will need to provide an SBOM for your software.

How do you go about getting an SBOM for your software?

  1. You need to understand your open-source dependencies at the source and binary level. There are a variety of tools out there to analyze your dependencies, typically aligned with the ecosystem you are using, such as Java or Python. There are also ways to identify components used within containers as well (which is yet another reason to containerize your software).
  2. You need to understand your commercial dependencies at the source and binary level.
  3. Use all of this information about the dependencies to create a Software Bill of Materials (SBOM).

SBOMs are created with a specific format, which allows for consumption and use by others. It is a standardized list of the components in use – be they source or binaries. There are two main representations of an SBOM, SPDX and CycloneDX. SPDX at https://github.com/spdx is a more heavy weight standard with flexible output formats such as JSON, YAML, XLS, etc while CycloneDX, https://github.com/CycloneDX/specification is a more industry oriented approach, with outputs in XML/JSON.

The clock is ticking

While you may not have been asked to provide an SBOM yet, the time is coming when you will need to do this. Thought Source can help you with working through the world of SBOM, particularly around understanding what your open-source footprint is, and then using that information to create your SBOM.

Contact us now to discuss creating an SBOM for your software product

INTRODUCING

THE TECHNICAL DUE DILIGENCE SHOW

The Thought Source team have produced a video series covering the "behind the scenes" of performing technical due diligence for M&A projects.