Perspectives

Reducing Software Supply Chain Risks with SBOMs

Written by Jarrett Bunnin

Counter major threats with a software bill of materials

In an increasingly interconnected world, supply chain attacks can compromise a wide range of organizations in one swift hit. The SolarWinds attack and the Log4Shell vulnerability showed that such threats can profoundly harm national and economic security. No agency or company is immune. But your organization can proactively mitigate supply chain risks with commonly used tactics and techniques. In this post, we’ll discuss how a concept championed in the Biden administration’s cybersecurity executive order—the software bill of materials (SBOM)—can accelerate your risk mitigation efforts.

Now, SBOM is a relatively new term, and it sounds explosive when it rolls off the tongue. Said in passing in a national-defense setting, it could be mistaken for a new munition. In fact, an SBOM is more like an itemized receipt for software—or, if you are from the accounting world, a general ledger of software liabilities and assets. Now, that might not sound strong like a weapon, but think again. Implementing SBOMs in government and industry is a priority for national security. Understanding what SBOMs are, and why they are so important, can bring your organization one step closer to mitigating supply chain risks.

What Are SBOMs?

To be clear, SBOMs are much more complex than just a receipt, or even an accounting ledger. (And if you have ever done accounting, you know these tribulations.) What’s more, there isn’t yet a formal legal framework for SBOMs. There is, however, a consensus framework that is largely accepted by the cybersecurity community. And that’s a start.

In 2018, this framework emerged from a multistakeholder process led by the National Telecommunications and Information Administration (NTIA). The framework was born from a collaborative, open-source community effort to determine industry agreed-upon standards for conducting SBOM analyses. SBOMs being used by industry and government have come a long way since then. And Executive Order (EO) 14028 is driving further standardization.

Published May 12, 2021, the EO mandated that NTIA generate a list of minimum elements required for an SBOM to be considered viable for an organization to use. NTIA has since established three minimum elements that are considered, “essential pieces that support basic SBOM functionality and will serve as the foundation for an evolving approach to software transparency.”

Minimum Elements
Data Fields	Document baseline information about each component that should be tracked: Supplier Component Name Version of the Component Other Unique Identifiers Dependency Relationship Author of SBOM Data Timestamp
Automation Support	Support automation, including via automatic generation and machine-readability to allow for scaling across the software ecosystem. Data formats used to generate and consume SBOMs include: Software Package Data eXchange (SPDX) CycloneDX (CDX) Software Identification (SWID) tags
Practices and Processes	Define the operations of SBOM requests, generation, and use including: Frequency Depth Known Unknowns Distribution and Delivery Access Control Accommodation of Mistakes

How Can SBOMs Add Value?

Software Lifecycle & Bill of Materials Assembly Line

These minimum elements were designed to comply easily with changes in code, which many organizations experience on a regular basis, and as such would require updates to the SBOM throughout the software lifecycle (see illustration below).

The three identified SBOM formats (SPDX, CDX, and SWID) are commonly accepted by industry as best-practice standards. However, it is important to realize that while these formats may give overarching guidance, it is up to each specific organization using these formats to determine how to adjust them for the “best fit.”

SBOMs are intended to give software producers, buyers, and operators a greater understanding of the supply chain. Armed with this understanding, organizations will be better able to track down known or emerging vulnerabilities and risks, enable security by design, and make informed choices about software supply chain logistics and acquisition issues. And that is increasingly important because sophisticated threat actors now see supply chain attacks as a go-to tool for malicious cyber activity.

National Security Implications

The 2017 NotPetya attack and more recent attacks involving SolarWinds, Microsoft Exchange servers, and the Log4Shell vulnerability have greatly increased attention to software supply chain security. And the U.S. intelligence community’s latest annual worldwide threat assessment warns that increasing connections among countries—including supply chains—have created “new opportunities for transnational interference and conflict.”

While criminal groups have executed relatively less complex software supply chain attacks, it’s advanced persistent threat (APT) actors who generally have the will and skill needed to execute technically complex, long-term campaigns for software supply chain attacks that threaten national security, according to the Cybersecurity and Infrastructure Security Agency. Common attack techniques, which can be used in combination, include hijacking software updates, undermining code signing, and compromising open-source code.

The stakes could not be higher: It’s vital for the federal government to have secure software to perform critical functions, which is why an entire section of EO 14028 is devoted to software supply chain security. In addition, the White House’s March 21 statement on protecting against cyber attacks from Russia includes a call to use SBOMs to bolster national cybersecurity over the long term. The administration also recently issued a report on boosting the resilience and security for U.S. information and communications technology (ICT) supply chains. The report underscores the need for concerted efforts across the public and private sectors.

How Can SBOMs Counter Software Supply Chain Threats?

To envision how SBOMs fit in an integrated effort to counter software supply chain risks, start with a well-known military symbol: the trident. Imagine a spear with three sharp prongs to fend off digital foes. The longest prong in the center is a set of techniques used for hunting advanced persistent threats. And on each side is another prong: SBOM implementation on the left and augmented data risk management on the right.

This Trident Framework depicts the sort of cross-functional effort needed to counter software supply chain threats. It shows how enterprises can build a unified defensive effort involving cybersecurity experts, acquisition professionals, and the chief information security officer. The first step for an organization aiming to create this digital trident is to implement an SBOM framework that meets NTIA’s minimum elements.

Wielding the Trident Framework: 5 Tips

5 Tips for Wielding the Trident Framework

1. Ensure your organizational cyber policies and procedures allow for successful fast-moving implementation of the framework across software that touches all offices and teams of your organization, and consistent recurrence of it. Organizations, particularly in government, often do not have the appropriate operational processes in place before implementing something like NTIA’s minimum elements.

2. Engage your employees consistently and regularly around ways to detect malicious activity through active cyber-awareness programs.

3. Use APT techniques to discern vulnerabilities in tandem with the SBOM analyses as best benefits your organization. Identify vulnerable versions of software and patch immediately. In addition, conduct persistent, frequent, and thorough threat hunt activities on all assets identified as at risk based on the SBOM analysis. The hunt should include all networks, assets, and resources that are adjacent to the high-risk assets to identify lateral movement, reconnaissance, persistence, or exfiltration as there may be actors hiding inside the network.

4. Use data collected from the SBOM collection and analysis process and incorporate it directly into your risk management processes to determine software supply risks and risk tolerance for your organization. This means also tying in mechanisms for applying countermeasures, mitigations, or other risk control activities. In addition, conduct cyber kill-chain post-mortem analysis and incorporate regularly when acquiring new software or planning a new project launch as part of the broader enterprise risk management program.

5. Adopt the SBOM concept in concert with a “zero trust” cybersecurity mindset. Zero trust is driven by three core principles: Assume a breach; never trust, always verify; and allow only least-privileged access based on contextual factors.

Achieving Prevention with Holistic Preparation

Now that you know about SBOMs and how to put them in action, it’s time to get started. Cyber threat actors aren’t hesitating to attack global supply chains. And U.S. organizations can’t afford to delay implementing SBOMs. After all, enterprise strategies in place only go only as far as their agility allows. You can help your organization implement an SBOM framework for widespread use among IT acquisition functions and other offices involved in acquiring, sustaining, and reviewing software materials. Along the way, feel free to share this article with others if you find it helpful.

To sign up for more technical content like this blog post

Fill Out This Form

And to learn more about Booz Allen’s comprehensive approach to effectively mitigating supply chain cyber risk

Download This Report

This blog series is brought to you by Booz Allen DarkLabs. Our DarkLabs is an elite team of security researchers, penetration testers, reverse engineers, network analysts, and data scientists, dedicated to stopping cyber attacks before they occur.

This article is for informational purposes only; its content may be based on employees’ independent research and does not represent the position or opinion of Booz Allen. Furthermore, Booz Allen disclaims all warranties in the article's content, does not recommend/endorse any third-party products referenced therein, and any reliance and use of the article is at the reader’s sole discretion and risk.