It’s Time to Get Hip to the SBOM

The DevOps, IT security and IT governance communities will remember 2021 as the year when the Software Bill of Materials, or SBOM, graduated from a “nice to have” to a “must have.” 

Around for years, the SBOM has now become a critical DevSecOps piece, which everyone must thoroughly understand and incorporate into their SDLC (Software Development Lifecycle). In a nutshell, SBOMs provide visibility into which components make up a piece of software, and how it was put together, so it’s easy to determine if it contains security and compliance issues.

In this blog post, you’ll learn what an SBOM is, how it will benefit you, which misconceptions exist around it, and why it must be a key element of your SDLC security and compliance. 

How the SBOM moved from the wings to center stage

The SBOM standard was proposed in 2018 by the U.S. Food and Drug Administration (FDA) to ensure that medical device software has the same level of accountability as food items, since it directly affects individuals’ health. But SBOM’s rise in prominence can be directly tied to two recent events: the devastating SolarWinds hack in late 2020, and the White House’s cybersecurity executive order from May of 2021.

The SolarWinds breach highlighted supply chain attacks, in which malware is hidden in legitimate software that then gets distributed via authorized channels to unsuspecting end users. In the case of SolarWinds — an IT monitoring vendor — hackers injected malware into the software build process of its Orion Platform in the form of indirect transitive dependencies. 

For months, SolarWinds inadvertently shipped product updates with the vulnerability, designed to help hackers compromise customers’ Orion servers using a backdoor. About 18,000 customers received compromised updates, and several dozen got breached, including prominent multinationals and U.S. federal government agencies. 

At the time, it was the latest in a string of supply chain hacks, but its extent and consequences set it apart, prompting intense scrutiny and increased attention on software development security and on DevSecOps. With its disastrous fallout still being felt, it was cited by the White House as a driver for U.S. President Joe Biden’s Executive Order on Improving the Nation’s Cybersecurity. 

The order highlights the SBOM’s importance as “a formal record containing the details and supply chain relationships of various components used in building software.” Likening SBOMs to a list of food ingredients, the White House declares them useful for software makers, software buyers and software operators alike.

The transparency an SBOM provides into all the dependencies between the software components of an application can help prevent, or more quickly mitigate, supply chain hacks. “Understanding the supply chain of software, obtaining an SBOM, and using it to analyze known vulnerabilities are crucial in managing risk,” the order reads.

Although the U.S. government will provide more specific security requirements for software makers, it already stated in the order that it will require that every piece of software that it buys come with a detailed SBOM.

SBOMs: Visibility and transparency

The security of open source software can’t be overlooked, and it’s critical to know what’s in the software you’re selling to customers, buying from vendors, or downloading for free from the Internet.

Study after study have shown that open source software makes up most of the average application’s code base, often upwards of 90%, including risky components that have critical vulnerabilities or that haven’t been updated for years by their creators.

In other words, un-inspected software is inherently insecure or flawed.

It’s no surprise then that having SBOMs for the software you develop has become a core best practice for DevSecOps, as well as an increasingly common regulatory requirement — especially in highly regulated industries, like finance and healthcare — and a condition for doing business with a growing number of public- and private-sector customers.

By providing transparency and visibility into the components of the software you market and use, SBOMs help your organization protect its employees, its customers, and its reputation, as well as reduce remediation costs and the risks of legal liability and government fines.

Although the SBOM information will be required in order to sell software to the U.S. government, regulated industries, as well as governmental organizations around the world, will also likely demand this information. Thus, documenting and reporting the SBOM of the software you build should become a universal required practice.

What’s in an SBOM?

An SBOM contains a list of the “ingredients” that make up a piece of software, including libraries and modules — whether they are open source or proprietary, or free or paid — as well as information about the development tools, and CI (continuous integration) environmental variables used during the build process.

The SBOM can also outline when the software was built, what SDLC stages it went through — dev, QA, staging, production — and what security and compliance issues have been detected and fixed.

This information boosts DevSecOps efforts and helps maintain security and compliance in a variety of use cases, including:

• For software producers: An SBOM helps them build and maintain their applications by detailing all the upstream components being used, and by tracking changes between the different versions of the application. When a vulnerability is disclosed that affects their application, software vendors can detect right away which versions are impacted and how, and quickly fix the issue and notify their customers.

• For software buyers; The SBOM helps them have visibility into the make-up of the product they’re purchasing to make sure it’s up to their security and compliance standards and requirements, especially if they’re in a highly-regulated industry. It also helps them anticipate and quantify the inherent risks in a particular software package.

• For software operators: The SBOM helps inform their processes for vulnerability and asset management, licensing compliance verification, and identification of risky software components. The SBOM can also help them optimize the performance and reliability of the software, lowering the risk of outages and malfunctions.

The more complex an application, the more valuable an SBOM, as it provides clarity into all the inter-dependencies within the components, and among the multiple container layers of the software, including the application layer, the runtime layer, and the base OS layer. 

For example, like a big, sophisticated cake, a complex web service has multiple layers with many ingredients. In the case of the web service, the layers are often Docker images, and each one should have its own SBOM. There should also be a primary, umbrella SBOM that encompasses all the individual ones.

That way, you can track all the dependencies and sub-dependencies, and isolate individual components of the web service to pinpoint the ones impacted by a security or compliance issue, such as a critical vulnerability or a misconfiguration. With this information, you can detect and remediate issues early and quickly, reducing the chances of a breach. For instance, it’s estimated that almost 75% of applications with vulnerable libraries can be fixed by moving to a new version with updated libraries.

SBOM misconceptions

Over the years, unfounded objections to SBOMs have emerged, including:

• Won’t an SBOM provide a roadmap for hackers? No, the information in an SBOM won’t give attackers the clues they need to hack your software, and they won’t even bother looking at SBOMs. They have much more powerful and sophisticated tools at their disposal to carry out their nefarious deeds.

• Won’t you have to disclose your source code in an SBOM? No, you don’t. An SBOM contains information about what’s in your software and about the environment in which it was created, but not your source code.

• Won’t an SBOM expose my confidential intellectual property? No, SBOMs don’t contain proprietary IP data.

It’s important to understand that the SBOM is simply metadata about the software and not the software itself. It contains data about what was used to make the software, but not about the process with which it was assembled.

How JFrog and AWS can help

With the JFrog DevOps Platform — and in particular with JFrog Artifactory, JFrog Xray and JFrog Distribution — hosted on AWS, you can easily get all the granular data you need for an SBOM, including: 

• All of your software’s transitive dependencies
• Detailed CI environment information
• Security and compliance data, including the “blast radius” of vulnerabilities and non-compliant licenses across all builds in your applications
• Distribution data, such as how, when and where your software was deployed, which customers received it, and more

This treasure trove of information about your software is available both via the JFrog UI and via the JFrog REST API, so you can export it to third-party tools of your choice.

(For hands-on, technical details about how the JFrog DevOps Platform can help you determine if you’re impacted by the SolarWinds breach, where you’re impacted and how you can remediate the impacted libraries, read our recent blog post “Automatically Assess and Remediate the SolarWinds Hack.”)

In summary, the time has come to devote more attention to the SBOM and move it up on your list of DevSecOps priorities, for all the reasons outlined above. 

Don’t hesitate to reach out to us if you want to discuss this topic further.