A software bill of materials (SBOM) is now preferred for all software components supplied to the US government. Let's explore what an SBOM is and why it's becoming standard practice for the software supply chain.
Why do software bills of materials (SBOMs) matter? The average enterprise now uses more than 650 applications, while the largest companies can use up to 3,400. Many of these incorporate components of open-source, third-party, or common code that cybercriminals can easily recognize.
Without a way to track the software components used across your tech stack, and where their vulnerabilities and dependencies are, your organization is at serious risk of security breaches, compliance violations, and unexpected failure. That's where SBOMs come in.
Think of SBOMs as the 'nutrition labels' of enterprise software. SBOMs give IT teams a way to maintain transparency, capitalize on optimization opportunities, keep their infrastructures secure, and respond more efficiently to the inevitable issues that arise from operating a complex enterprise architecture.
Let's take a deeper dive into what an SBOM includes, what can go wrong if you don't use one, and how you can create SBOMs for your business.
A software bill of materials (SBOM) comprehensively lists the components in a given software system. It includes all open-source and third-party components of the codebase, as well as their licenses, versions, file names, publishers, patch statuses, and dependencies.
The Cybersecurity and Infrastructure Security Agency (CISA) calls SBOMs a:
This is due to the range of benefits SBOMs offer, including:“key building block in software security and software supply chain risk management“
Overall, SBOMs are simply detailed and searchable documentation of the parts used to create software. It's no wonder this common sense methodology is becoming industry best practice.
In today’s world of open-source code, the majority of components that make up any single, vendor-provided application don't usually originate with the vendor itself. That means you need a software bill of materials (SBOM) to maintain full visibility of your software supply chain, as well as to protect it from security threats.
Cyber criminals know that exposing a vulnerability within the code of a common software component can enable attacks on thousands of businesses. In an article titled NVD Analysis 2022: Why You Need To Modernize Your Software Security Approach, Reversing Labs found that attacks on open source repositories increased by 289% over the past four years. These include the highly publicized Log4J and PyTorch vulnerabilities that we reported on at the time of their discovery.
In 2021, US President Joe Biden signed an executive order on improving the nation’s cyber security. This includes a call for SBOMs to be provided as standard by all software vendors, particularly when working with the government.
Meanwhile, a recent Linux report shows that, while only about half of organizations actively use SBOMs now, 88% plan to do so by year’s end. All this gives a clear indication that SBOMs are about to become a necessity.
Let's look at how you can get started on creating your SBOMs in your organization.
To make creating your own software bill of materials (SBOM) easier, there are a few accepted standard formats. At LeanIX, we use CycloneDX as our preferred SBOM format.
CycloneDX is led by the Open Web Application Security Project (OWASP). The format is a “lightweight” SBOM standard designed to fit a wide variety of use cases.
Regardless of which format you use, once you have chosen, the next step is to create an inventory of the services that make up your software along with the libraries these services use. LeanIX VSM enables you to do this.
By allowing you to create a comprehensive catalog of services and libraries, LeanIX VSM provides complete transparency across your software supply chain.
Powerful out-of-the-box integrations and easy-to-use APIs will give you a real-time inventory of your services and the teams responsible for them. As a result, you can understand at a glance which services are dependent on a specific library, which teams are responsible, and which products use the service.