How an SBOM Helps Assess Third-Party Security Risk

In 2020, a public company based in Tulsa, Oklahoma that sells software for IT, monitoring and networks was hacked. As a software provider to tens of thousands of U.S. government agencies and high-profile customers such as AT&T, MasterCard, and Ford Motor Company, it was the perfect target for a far-reaching software supply chain attack. The hack was later found to have affected over 18,000 systems worldwide through malicious code injected by hackers into their Orion software.

Today attackers continue to successfully target third parties as a way to more easily circumvent an organization’s otherwise robust cybersecurity. These third parties, partners, contractors or suppliers could provide you with cloud web hosting services, HVAC services, legal,  bookkeeping and accounting services. In response to both the proliferation of third parties and the increase in attacks, regulatory bodies have started to take action. A Software Bill of Materials, or (SBOM), is now a requirement for any software company doing business with the U.S. federal government.

Here’s how organizations use the SBOM today and how it may help to better assess third-party security risk in the future.

What is SBOM (Software Bill of Materials)?

An SBOM is an inventory of the details and supply chain relationships of various software components, both commercial and open source, in a product.  

The basic guidelines for the SBOM were established by the National Telecommunications and Information Administration (NTIA). NTIA specifies the minimum elements of an SBOM to include the package name, version, unique identifier, licensing information, dependencies, known security vulnerabilities and software hash. With these details, the US Executive Order ensures greater transparency and visibility into the digital supply chain.

Despite existing for over a decade, SBOMs have returned to the forefront of cybersecurity following a surge in third-party supply chain attacks. In May 2021, an executive order was issued requiring that all organizations delivering software to the federal Government detail the components of that software in an SBOM. In 2022, the UK followed with a similar strategy for defending the public sector against cyber attacks called the Government Cyber Security Strategy: 2022 to 2030.

Although President Biden took the first step with regard to making SBOMs mandatory for any organization selling software to the federal government, this requirement will most likely be universally adopted in the near future. This is the recommendation of the Open Source Software Security Mobilization Plan. Although the complexity of the software supply chain and its many dependencies pretty much guarantee it, it may take some time before SBOMs are widespread across all industries.  

One of the main challenges in SBOMs and their widespread adoption is their inability to transmit data in different formats. Fortunately, various organizations have developed different initiatives to solve this problem. 

What is a Software Package Data Exchange?

The Software Package Data Exchange (SPDX) gives companies and organizations a standard format for developers to share SBOM data and information with customers. Developed by the Linux Foundation, it has widespread appeal both in the global open-source community and commercial organizations, at least in part because it allows developers to generate SBOMs free of charge.

In September 2021, SPDX became an international open standard ISO/IEC 5962:2021. Other standards exist, such as the Software Identification (SWID) developed by NTIA and CycloneDX, developed by OWASP. Although all of the formats can be used for SBOM generation and the sharing of SBOM data, the different formats are used at different points in the software development lifecycle by different types of software users.

Why Should You Identify Your Software Components?

From cell phones and home appliances to hospitals and manufacturing companies, software is an essential part of the day-to-day tasks of businesses and individuals alike. To ensure proper security, the software components of these devices and products must be regularly monitored to identify and patch vulnerabilities. This is particularly true of open-source software.  

Waiting for security patches for open-source software can take several weeks or more. According to Synopsys’ 2023 Open Source Security and Risk Analysis (OSSRA) report, 48% of all code includes high-risk vulnerabilities, and up to 84% of all proprietary code uses open-source components. SBOMs help organizations identify these software components, including open-source components, license and version information and patch statuses so that they can better manage third-party risk.

Another related reason to identify your software components through SBOMs is to identify the dependency relationship between the different components. For example, in the SolarWinds attack, the SUNBURST malware was injected into the Orion software, which was an IT management system used by over 18,000 customers. This software dependency was the source of a global supply chain attack. SBOMs check for software dependencies in your code so that you can better evaluate your software suppliers and third-party security risk to the federal government and organizations doing business with them.

Finally, SBOMs have a business impact. They help manage software licenses, identify compliance requirements, and manage vulnerability mitigations, enable cyber risk quantification and lower operating costs that are a result of unscheduled and unplanned work that must be done in the event of a security incident. 

How do SBOMs Protect the Software Supply Chain?

SBOMs expose elements of your supply chain that you may not have known existed by listing all of the components and their origins in your software. It can also assist you in distinguishing between foundational code components and optional components in your software. Armed with this information, companies can make better decisions about business relationships with their third parties.

For example, if after an SBOM creation, your organization discovers serious vulnerabilities in third-party components, you have a few options available. You could decide to remediate risk with that vendor, wait for a vulnerability patch or find an alternate software vendor. Or you could decide that the vulnerabilities in your software exist in optional code that you can eliminate altogether.

In addition, SBOMs are also valuable for organizations that need to:

• Conduct due diligence before an acquisition or merger. Organizations can use SBOMs to better understand the risk of the new product or service before acquiring it.
• Identify security risks earlier in the development process. These risks are particularly relevant for device manufacturers who incorporate one or more software applications into their hardware system and cannot go back and make changes after production.
• Ensure vendor compliance. SBOMs help organizations provide increased visibility to ensure that their software meets compliance and security standards. This includes but is not limited to highly regulated industries such as healthcare, finance, utilities and energy.

Not All Digital Supply Chain Vulnerabilities are Created Equal

Although the basic SBOM requirements are critical for gaining insight into the potential supply chain risk for vendors, they don’t communicate the vulnerabilities in software components, or the potential resulting damage were any of those to be exploited by hackers.

As a result, NTIA took an additional step in developing the Vulnerability Exploitability eXchange (VEX), a report on the status of vulnerabilities in a product. Since only a small number of vulnerabilities are exploitable, the VEX can drastically reduce the time developers and manufacturers spend exploring the potential risks in a given application.

The Future Adoption of SBOMs

Gartner projects that 60% of organizations will incorporate SBOMs into their security frameworks by 2025. The adoption rate is expected to increase as more organizations recognize the value of SBOMs in securing their software supply chains. 

It is fair to expect to see increased adoption by security teams in the following scenarios:

Speeding up software procurement

SBOMs can assist in shortening the purchasing cycle of third-party software. They can help identify security deal-breakers and provide in-depth software security analysis when in-house resources aren’t sufficient.

Vulnerability management and threat intelligence

The proliferation of connected devices makes it increasingly challenging for organizations to identify which components along the digital supply chain are affected by vulnerabilities. The SBOM and VEX assist in guiding vendors through these complex software relationships.

Valuable incident response data

After a security incident or a data breach in your organization or in one of your third parties, an SBOM can provide documented evidence and a trail of what went wrong, where and how the incident affected other areas, systems, or versions. It can be used with other security workflow documentation for additional verification, functioning as a source for any additional necessary information in the case of discrepancies.

Mapping risk across the digital ecosystem

While SBOMs today are a tool for evaluating third-party security risk management, they have even more potential. They can also provide a comprehensive map of the third-party dependencies in a government organization, the different relationships it has with those software and services and the potential damage of third-party security risk.

How Panorays Can Help

SBOMs are only effective if organizations and their security teams consistently update them with the latest software releases, updates, new third-party services, and bug fixes. Failure to keep up with these changes can put your data and organization at risk. 

Panorays quickly and easily automates this process so your third parties’ security policies align with your company’s internal policies and regulations, saving you time and resources. An organization using Panorays also enjoys the ideal vantage point from which to help track and manage SBOM information. Panorays identifies both your subcontractors and their digital assets, making it much easier to assemble the SBOM for those who don’t yet have it. In fact, one of the best ways to keep track of your SBOM is by adding each entry in the SBOM as a monitored company in Panorays to continuously monitor them.

FAQs