SBOMs: It’s All About Transparency into the Complexity of Your Software

Over the past few years, the software industry has increasingly relied on open-source software. It’s rare to find an application that solely uses proprietary components, with most enlisting a mix of third-party and open-source components. While this has led to a greater scope of what applications can do, as well as speeding up the production process, it comes with increased software complexity.

Alongside the increased usage of OS, security exploits are similarly rising, with these factors creating a perfect storm that has made the software supply chain a central focus of the industry. Companies now understand that they must have complete visibility of not just their own code, but the code used in every component that makes up their application.

The desire for complete and full transparency has led to the need for the frequent production and distribution of SBOMs (Software Billing of Materials) which is becoming an industry-wide occurrence. The 2021 White House Executive Order–despite the focus on companies supplying software to the government– solidified many industry notions that businesses should be requesting SBOMs from their software suppliers. the Linux Foundation’s prediction that 78% of organizations will either produce or consume an SBOM in 2022 seems extravagant without context. However, with the EO, increase in security exploits, and numerous other industry groups regulating security and license compliance steps, that number seems much more grounded.

As the software supply chain becomes increasingly complicated, SBOMs must equally shift to visualize the full scope of software, no matter how complex.

Why Are SBOMs So Important?

Requesting SBOMs from suppliers is quickly becoming an industry-wide standard, and it’s not hard to see why.

As the complexity of software has increased, more companies now create products with components sourced from third-party vendors and partners. The question becomes, are they aware of exactly what’s in their software and where it came from? After a product is shipped downstream or to customers, any vulnerability found becomes the responsibility of the software supplier. Even if the component with a vulnerability in your application was made by someone else, the distributing company takes the responsibility and possible inherent risks upon itself.

This structure of legal responsibility is mirrored in the hardware industry. When a commercial airliner manufactures a plane, they are responsible for its safety, despite the vast majority of its parts not being proprietary. The difference between software and hardware, in this case, is that the latter has an excellent system of supply chain tracking in place.

While the aforementioned airline company could give you a detailed breakdown of every single part and who created it, many software companies could not say the same about their own application. With up to 80% of software in a platform being from a third-party, the mass movement to create and distribute SBOMs is the software industry’s method of providing complete visibility.

SBOMs are vital because, just like the hardware industry, an application is never truly developed solely by the company that ships it. With the complexity of the modern software supply chain, complete transparency is imperative, with comprehensive SBOMs being the way forward.

SBOMs Still Have Room to Grow

Organizations are typically very good at scanning their applications. With a range of available tools, they can create an SBOM of all the code they’ve written and contributed to. The main issue is that proprietary components might only composite around 20% of a final application.

Expanding the field of view to not just the parts that a company controls and audits, but all of the individual components that make up a final product is vital. Taking both an inside perspective and an outside-in approach allows for complete visualization of what’s in a product. Beyond just internal code, a complete SBOM includes data ingested from a wide range of sources, unifying internal and external data.

Even when requesting SBOMs from upstream partners to have a comprehensive overview, many SBOMs are still in different formats, making coherence across several different sources challenging to follow. Especially when a security event occurs, not having the full picture of what’s in a software application can reduce the efficiency of mitigation techniques, as teams have to spend longer searching for impacted components.

As the software supply chain becomes more mature, ever-increasing in complexity, the level of detail that SBOMs provide must equally increase. Collecting data from every corner of your organization, as well as upstream partners, is vital when creating a detailed SBOM. All code must be scanned, license compliance and security vulnerabilities uncovered, remediation performed, and a complete, accurate SBOM produced that has collected information from all corners of the organization as well as from upstream supply chain partners.

If you’re looking for a comprehensive solution, then Revenera’s SBOM Insights offers a complete view of all your applications. With SBOM Insights you can:

  • Unify all SBOMs into single, actionable view in the cloud
  • Ingest data from a wide range of data sources—both inside and outside of your organization
  • Give full open source and third-party component visibility to legal teams, security, and supply chain partners