Comprehensive SBOMs can help address software supply chain risks
One way to address the risks inherent to the complex applications we are building is to use “Software Bill of Materials” also known simply as “SBOM”. At its simplest, a SBOM is a list of all the different component parts of an application. This typically includes several types of information about each component: Its name, who supplied the component, what license it uses, the version number, any known vulnerabilities, and a list of all the component’s dependencies.
Application complexity is increasing
The reality is that modern applications are complex and dynamic, and therefore hard to secure. They use programming languages that run entirely in the browser, they talk directly to their dependencies on the internet and they use technologies like containers, serverless and public cloud. All of these bring their own challenges, so we need visibility into all these other application components and dependencies as well. What third-party APIs and public cloud components is it using? Is it using an identity provider like Auth0 or Cognito? What infrastructure is required to make the app run? All of these things need to be understood to really be able to better represent what is in an application and how to secure it.
Traditional SBOM tools do not produce accurate results
Most SBOM tools that exist right now, simply focus on showing customer the open-source libraries that they are using in their applications. Moreover, most SBOMs are stand-alone XML or JSON documents. By themselves these documents don’t provide much value. Even worse, most SBOMs are point in time generated and then never updated. So, these “static” SBOMs quickly become out of sync with the actual application they are supposed to describe.