Software Bills of Materials (SBOMs) have become a key tool for mitigating threats to the software supply chain, by revealing a sort for nutrition label for your software. And it's important to note that SBOMs are also not the end game for software security assurance, but an essential first step nonetheless.
But, first, you need to understand what exactly comprises an SBOM — and how they are helpful to securing your software supply chain. Here's what you need to know.
[ Get a free SBOM and supply chain risk analysis report ]
Supply chain risk's rise coincides with modern software practices
Risks to the software supply chain have never been greater. The consequences of software supply chain attacks were made well-known thanks to the SolarWinds compromise of December 2020. Since the SolarWinds attack, countless other attacks and proof-of-concepts have arisen stemming from several 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 made fully aware of the components within their software products. This is why adding visibility of open source, third-party, and internally developed software components — all on the rise given the fast paced nature of modern software development practices, as well as the methods of developing software using a pipeline of tools — is essential in combating such risks.
Any organization that either produces or consumes software needs to make, use, and continually update software bills of materials (SBOMs) for any software product.
What's in an SBOM: Let’s break it down
Simply put, an SBOM is “a formal record containing the details and supply chain relationships of various components used in building software,” according to the National Telecommunications and Information Administration (NTIA). 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 include these key elements: component name, publisher name, component version, file name, software license, and dependencies.
SBOMs are often compared to the infamous black and white nutrition label most Americans are used to, in which all of the food items’ ingredients and daily value percentages are listed. SBOMs serve a similar purpose in that they list a software product’s key “ingredients,” such as third-party software, open source software, statically linked packages, and internally developed software. Also similar to a nutrition label, an SBOM will flag the severity of a software product’s components, as well as the origin and authenticity of the components.
However, it is important to highlight that not all SBOMs are created equal. There are ways in which an organization can modernize SBOMs to make them the most effective in minimizing software bloat and in defending against software supply chain risks, including attacks on software repositories.
The consequences of open source software reliance are already evident to the software industry. In ReversingLabs recent analysis of the National Vulnerability Database (NVD), it was found that attacks on open source repositories, specifically PyPI and npm, have skyrocketed by 289% in the past 4 years.
This is why a good SBOM needs to give a clear view of every layer and dependency in the software development lifecycle (SDLC). An SBOM that does not expose every layer will “leave you with a risk that could have been avoided."
In addition to the risks associated with open source software use, threat actors are pursuing other malicious actions such as injecting malware into code, exposing secrets, and tampering with software packages. Attackers can also target the tools that software developers rely on, such as containers. A high quality SBOM can be a great starting point for organizations hoping to mitigate all of these software supply chain risks.
An effective SBOM is also based on when it was built. For example, if an SBOM was created during the final build of a software product, it will not list crucial components during the binary and packaging stages of the SDLC. Instead, it’s recommended that SBOMs represent “software as delivered,” which takes into account components found throughout the SDLC.
Finally, an SBOM requires automation to be successful. This means having automated binary analysis of every component, which gives an organization insight into the risks associated with a software product’s key ingredients. Automation is also essential due to the constantly changing threat landscape, which means SBOMs need to be updated in real-time with the industry’s latest knowledge on new vulnerabilities and malicious packages.
It's also worth noting how the minimum elements required for making a good SBOM will change in the future as the industry learns more about software supply chain risk. This is evident in how SBOMs have already evolved within the past few years.
The federal government's big SBOM push
SBOMs have become more widely known and used, in part due to the U.S. federal government sharing guidance that highlights their use as helpful in defending the software supply chain.
The Biden Administration’s May 2021 Executive Order 14028 on Improving the Nation’s Cybersecurity was a key government action that mentioned the use of SBOMs as being integral to securing software, while also acknowledging the software supply chain is at risk.
Not long after the Executive Order, the Department of Commerce and the NTIA released “The Minimum Elements For a Software Bill of Materials” report (PDF), which “defines the scope of how to think about minimum elements, why an SBOM can help lower risks, and lays out options for future evolution.” Subsequently, the National Institute for Standards and Technology (NIST) published their first version of the Secure Software Development Framework in February 2022, which lists action steps federal agencies need to take to secure their software use, such as using SBOMs.
Additional federal guidance has suggested the use of SBOMs, specifically in the Enduring Security Framework working panel's report on "Securing the Software Supply Chain." The report acts as a practical guide for software developer teams looking to secure their development processes.
Taking it a step further, the Office of Management and Budget recently shared a memorandum, as a follow-up to Executive Order 14028, that mandates all federal agencies to only use third-party software products that can attest to having an adequate level of security. The memorandum also gives agencies the authority to request an SBOM from a third-party software supplier in order to achieve comprehensive attestation.
But will the software industry get on board?
While SBOM adoption and awareness has increased within the past few years, there is still a lot of growth needed in this area. For example, in a ReversingLabs commissioned study, conducted by Dimensional Research, only 27% of software organizations generate and review SBOMs. Also, an overwhelming 9 in 10 software professionals reported that the difficulty to create and review SBOMs is increasing. These professionals cite that software organizations lack the expertise and the staff to generate and review high-quality SBOMs.
Things may change, however. Thanks to the federal government taking a stand on software security, SBOM adoption may become more widespread. As a result of Executive Order 14028, it is expected that SBOM adoption will increase from 5% to 60% in the private sector by 2025. Knowing that a majority of the industry is expected to use SBOMs, means that any software organization that has not adopted SBOMs will continue to be in the minority, putting them at a disadvantage.
Regardless of whether or not the federal government mandates secure software practices like the use of SBOMs for the private sector, the industry is heading towards making SBOM use commonplace.
