All kinds of organizations, whether they sell software or only purchase it, can benefit from knowing what their software contains. The number of software supply chain attacks in recent years and the multitude of attack methods cybercriminals are now using to carry them out should be reason enough to make transparency a top priority for securing these supply chains.
And for organizations that have not yet realized this, the U.S. federal government, the European Union (EU), and several other countries have been busy crafting software supply chain security policies that are in favor of software-producing and software-consuming organizations adhering to these best practices.
One of these agreed-upon standards is the use of a software bill of materials (SBOM), which can provide transparency into software packages and show all of their components so that the threats that cybercriminals can exploit are exposed.
Here's why SBOMs are an essential part of software supply chain security — and how your organization can make them actionable for your software security team.
[ See Webinar: SBOMs Are Having a Moment. How to Make Them Actionable | See Special Report: The State of Software Supply Chain Security (SSCS) 2024 | Download: State of SSCS ]
SBOMs: No longer optional
Many incidents in recent memory have made software supply chain security a priority for security leaders. SunBurst, the 2020 software supply chain attack on SolarWinds’ Orion software, is one of the most notable, both for the stealth that the cybercriminals maintained and for the thousands of entities, both public and private, that the attack negatively impacted.
SunBurst and similar attacks helped push the White House to release Executive Order 14028, on "Improving the Nation’s Cybersecurity," in May 2021, which was a show-stopping moment for U.S. cybersecurity policy. In the years since its release, a plethora of guidelines and mandates have been released, many of which cite the necessity of SBOMs. These include releases such as “The Minimum Elements Required for a Software Bill of Materials” (PDF), the Secure Software Development Framework, and M-22-18 (see the PDF), which requires software producers that sell to the federal government to attest to the security of their software.
While EO 14028 was a major step forward for software supply chain security, ReversingLabs chief trust officer Saša Zdjelar emphasized in last week’s ReversingLabs webinar that this policy item is not legislation — and it could be wiped away after this year’s upcoming presidential election. However, despite that possibility, Zdjelar is confident that EO 14028, or at least its impact, won’t be going away anytime soon.
“All that’s come from the federal government surrounding software supply chain security is just the right thing to do — regardless of what happens to EO 14028.”
—Saša Zdjelar
Zdjelar also noted that the United States hasn’t been alone in crafting software supply chain security policy that includes recommendations for SBOM use. For example, the EU has been busy releasing cybersecurity legislation, such as the Digital Operational Resilience Act (DORA) (PDF) and the NIS2 Directive, both of which weave in software supply chain security principles, making it even more likely that SBOM adoption will continue.
Those principles have bled into the private sector over the past few years, with many organizations now awake to the value that SBOMs can bring. Back in 2022, analyst firm Gartner predicted that, by 2025, 60% of organizations procuring mission-critical software solutions would mandate SBOM disclosure in their license and support agreements. More recently, in late 2023, Gartner said the following:
“The inability or unwillingness of a vendor to provide an SBOM should be viewed as a significant risk and potentially disqualifying."
—Gartner
Given the support for SBOM use in the public and private sectors, it’s important that organizations that sell or buy software no longer consider SBOMs optional.
What SBOMs do (and don’t) provide
The value of SBOM use for software supply chain security is immense, being the first step that organizations can take to provide visibility into their software products. However, a first step is just that, and it’s important to assess what value this tool can bring to your organization, in addition to what security gaps it creates.
For those companies that produce and sell software products to other companies, the transparency an SBOM affords has several benefits. For starters, SBOMs serve as a list of ingredients for an entire software package, showing development and security teams what kinds of open-source and commercial components reside within their product. Additionally, when the next vulnerability such as Log4j comes along, these same teams can resort to their SBOM to identify whether they are going to be impacted by a new celebrity vulnerability and thus should be able to remediate it efficiently.
At companies that consume software, teams will be able to use SBOMs to get insight into the software they are using and whether it poses supply chain risks to the organization. SBOMs also makes it easier for software vendors to transfer and share data because they provide a clear overview of the data that is digestible and universal.
But it’s important to remember that SBOMs are not a panacea for securing software supply chains. While SBOMs do shed light on some threats, they can't give a comprehensive view of the entire software supply chain. Threats such as tampering, malware insertion, secrets leaks, and more can't be spotted in an SBOM, leaving organizations in the dark when it comes to these risks.
In the ReversingLabs webinar, Zdjelar reviewed some key questions regarding SBOMs’ shortcomings. He urged software buyers to think critically about whether the SBOM they are given by a third party is truly accurate and whether or not verification is necessary. And he asked software producers how they will know whether they are “sending someone the next SolarWinds,” noting that the SunBurst incident couldn’t have been prevented with an SBOM alone.
Given those shortcomings, many companies are thinking beyond SBOMs, pondering how to mature their software supply chain security to manage all kinds of risks.
Taking that next step
For organizations looking to better understand SBOMs and their place in software supply chain security, the recent webinar with ReversingLabs' Zdjelar and ReversingLabs senior product marketing manager Joe Colletta provides an in-depth overview of why SBOMs are in the spotlight and how your organization can best operationalize them for greater software supply chain security.
Christopher Chan of the cybersecurity firm ExtraHop (a ReversingLabs partner) joins the webinar to discuss how RL Spectra Assure, ReversingLabs’ software supply chain security solution, is being used in real time to aid ExtraHop’s software production using comprehensive SBOMs.
See the webinar replay to get insights into the following:
- Why ExtraHop sees SBOM usage as a requirement
- How Spectra Assure aids the scanning of ExtraHop’s CI/CD pipeline
- ExtraHop’s criteria for ensuring software supply chain security
- How ExtraHop takes extra steps to ensure compliance with government standards
