SBOM stands for Software Bill of Materials
Before we jump into definitions, let’s quickly level set on how we got here. Over the last few years, the way we build software has changed drastically. With the increasing need to move faster and release more frequently, organizations are opting to get rid of monolithic architectures and adopt a microservices architecture for greater agility, resiliency, and efficiency.
Developers are now able to use more third-party resources and containers to piece together best-of-breed parts for their applications to run on. As a result, less of the code that makes up an application is owned and managed directly by that organization. Unfortunately, it’s difficult to get full transparency into all these pieces since the decision-making process and documentation process can happen in numerous places across an organization. The lack of a concrete way to determine all the components of an application introduces substantial cybersecurity risks, alongside the cost of development, procurement, and maintenance.
What is an SBOM?
A Software Bill of Materials (SBOM) is the full inventory of an application. Using an SBOM, organizations can understand what their applications rely on and identify vulnerabilities or license risks that may impact them.
At the moment, there is no single way to generate SBOM data, however, you can expect them to generally include a complete, formally structured list of components, libraries, and modules that are required to build a piece of software and the supply chain relationships between them. Components can be open source or proprietary, free or paid, and widely available or restricted access.
There are different SBOM specifications in the marketplace today, the top formats include Software Package Data Exchange (SPDX®), Software Identification (SWID) standard, CycloneDX, which was recently accepted as a flagship OWASP project, and others.
What is an SBOM used for?
SBOMs provide critical visibility into software components and supply chains. The aim is that they can be shared without friction between teams and companies as a core part of software management for critical industries and digital infrastructure. An SBOM can help:
- Identify & avoid vulnerabilities
- Manage software supply chain risk
- Determine supply chain quality & qualify vendors
- Improve software security, risk management, and mitigation
- Verify license compliance
- Level-set with a common understanding of software components
Who owns/manages an SBOM?
In the past, SBOMs were used primarily by compliance teams for audits, license monitoring, and to comply with industry-specific regulations. However, with the rise of software supply chain attacks, SBOMs have become critical for security and development teams alike.
Security teams need visibility into what risks exist, the potential impact, the issues that need to be prioritized, and a path for remediating any impending risks. Development teams can use SBOMs to keep a pulse on the open-source, commercial, and custom-built software components that they use across the applications they develop, manage, and operate.
From a cross-functional perspective, SBOMs provide a means to manage dependencies, identify security issues for remediation early, and ensure that an organization is meeting the standards set in its security posture.
Why is there an urgency for this?
In the wake of the SolarWinds hack and the recent Log4Shell vulnerability in Log4j, governments are prioritizing cybersecurity and are actively mapping out plans to ensure their departments, partners, and stakeholders are building greater cyber resilience.
The concept of an SBOM is not new, but it’s garnered much more interest lately due to the recent U.S. Cybersecurity Executive Order and the UK Government Cyber Security Strategy: 2022 to 2030.
As we continue to evolve our software development process, the complexity of the components we use to build our applications continues to grow. Without visibility into these components, it’s virtually impossible to properly assess risk and ensure security across applications and supply chains.
This post was originally published on the Veracode blog.