A Software Bill of Materials (SBOM): What it is – and why it is important to software supply chain security

SBOMs are essential to address the security of the software supply chain. Here’s what you need to know to start using them in your organization.

Software Bills of Materials (SBOMs) have become a key tool to mitigate threats to the software supply chain by revealing a form of nutritional labeling for your software. And it’s important to note that SBOMs aren’t the end game for ensuring software security either, but are an essential first step nonetheless.

But first, you need to understand what exactly an SBOM encompasses — and how it helps secure your software supply chain. Here’s what you need to know.

[ Get a free SBOM and supply chain risk analysis report ]

The rise in software supply chain risk coincides with modern software practices

Risks to the software supply chain have never been greater. The consequences of software supply chain attacks became known thanks to the December 2020 SolarWinds compromise. Since the SolarWinds attack, countless other attacks and proof-of-concepts have emerged, resulting from multiple vulnerable risks. These risks, such as open-source software, software tampering, malicious binaries, and insider developer threats, have become a necessity to manage.

These risks have continued to arise because both software development teams and those running the software in their organizations have not been fully informed about the components in their software products. For this reason, the visibility of open-source, third-party, and in-house developed software components—all of which are on the rise given the fast pace of modern software development practices and the methods of developing software using a pipeline of tools—is crucial in combating them risks.

Every company that produces or uses software must create, use, and continuously update software bills of materials (SBOMs) for each software product.

What’s in a SBOM: Let’s break it down

Simply put, according to the National Telecommunications and Information Administration (NTIA), an SBOM is “a formal record that contains the details and supply chain relationships of various components used in the creation of software.” The Cybersecurity and Infrastructure Security Agency (CISA) also characterizes it as a key building block in software security and software supply chain risk management. Most SBOMs contain the following key elements: component name, publisher name, component version, file name, software license, and dependencies.

SBOMs are often likened to the infamous black-and-white nutrition label most Americans are accustomed to, which lists all of the food’s ingredients and the daily value as a percentage. SBOMs serve a similar purpose by listing the most important “parts” of a software product, e.g. B. Third party software, open source software, statically linked packages and internally developed software. Similar to a nutritional label, an SBOM identifies the severity of a software product’s components, as well as the origin and authenticity of the components.

However, it is important to emphasize that not all SBOMs are created equal. There are ways an organization can modernize SBOMs to make them as effective as possible, to minimize software bloat, and to defend against software supply chain risks, including attacks on software repositories.

The consequences of dependency on open source software are already evident for the software industry. A recent analysis of ReversingLabs’ National Vulnerability Database (NVD) found that attacks on open source repositories, particularly PyPI and npm, have skyrocketed by 289% over the last 4 years.

For this reason, a good SBOM must provide a clear overview of all layers and dependencies in the software development lifecycle (SDLC). An SBOM that doesn’t expose every layer “leaves you at risk that could have been avoided.”

In addition to the risks associated with using open source software, threat actors pursue other malicious actions such as injecting malware into code, exposing secrets, and tampering with software packages. Attackers can also target tools that software developers rely on, such as B.Containers. A quality SBOM can be a good starting point for companies looking to mitigate all of these risks in the software supply chain.

An effective SBOM is also based on when it was created. For example, if an SBOM was created during the final build of a software product, it does not list critical components during the SDLC’s binary and packaging phases. Instead, it is recommended that SBOMs represent “software as supplied,” which accounts for components found throughout the SDLC.

Finally, a SBOM requires automation to be successful. This means an automated binary analysis of each component, giving a company an insight into the risks associated with the main parts of a software product. Automation is also essential due to the ever-changing threat landscape, which means SBOMs need to be updated in real-time with the latest industry insights on new vulnerabilities and malicious packages.

It’s also worth noting how the minimum elements required for a good SBOM will change in the future as the industry learns more about software supply chain risk. This is reflected in how SBOMs have already evolved over the last few years.

The big SBOM push by the federal government

SBOMs have become better known and used in part due in part to US federal government guidance highlighting their use as helpful in protecting the software supply chain.

The May 2021 Biden administration Executive Order 14028 to improve the nation’s cybersecurity was a key government action, noting the use of SBOMs as an integral part of securing software while acknowledging that the software supply chain is at risk.

Not long after the executive order, the Department of Commerce and NTIA released The Minimum Elements For a Software Bill of Materials (PDF) report, which “defines the scope of how to think about minimum elements, why a SBOM can help reduce risks, and sets out options for future developments.” Subsequently, in February 2022, the National Institute for Standards and Technology (NIST) published its first version of the Secure Software Development Framework, which outlined measures federal agencies must take to secure their software use, such as e.g. B. the use of SBOMs.

Additional federal guidelines have suggested the use of SBOMs, most notably in the Enduring Security Framework Working Group report on “Securing the Software Supply Chain”. The report serves as a practical guide for software development teams looking to secure their development processes.

Taking this a step further, the Office of Management and Budget recently issued a memorandum as a follow-up to Executive Order 14028, requiring all federal agencies to use only third-party software products that can demonstrate an adequate level of security. The memorandum also gives authorities the power to request an SBOM from a third-party software provider to obtain a comprehensive attestation.

But will the software industry be on board?

Although acceptance and awareness of SBOM has increased in recent years, there is still a lot of growth needed in this space. For example, in a study commissioned by ReversingLabs and conducted by Dimensional Research, only 27% of software companies create and review SBOMs. Also, an overwhelming 9 out of 10 software professionals reported that the difficulty of creating and verifying SBOMs is increasing. These professionals cite that software companies lack the expertise and people to create and review high-quality SBOMs.

However, things can change. Thanks to the German government’s statement on software security, the introduction of SBOM could spread further. As a result of Executive Order 14028, private sector SBOM adoption is expected to increase from 5% to 60% by 2025. Knowing that a majority of the industry is expected to adopt SBOMs means that any software organization that hasn’t adopted SBOMs will continue to be in the minority, putting them at a disadvantage.

Whether or not the federal government mandates secure software practices like the use of SBOMs for the private sector, the industry is moving towards making the use of SBOMs commonplace.

keep learning

*** This is a Security Bloggers Network syndicated blog from the ReversingLabs Blog written by ReversingLabs. Read the original post at: https://blog.reversinglabs.com/blog/a-software-bill-of-materials-sbom-what-it-is-and-why-it-matters-for-software-supply- chain security