Streamlining Software Security: Harnessing the Power of SBOM with Supply Chain Visibility

September 6, 2023

Article

Software supply chains are a big blind spot for many organizations. An enterprise may use hundreds of thousands of software components in the technology products that it buys and in the applications that it develops internally or outsources. Each software capability – including devices that contain software — contains layers of third-party code, including open-source and/or proprietary third-party components.

A good starting point is a detailed list of components in each piece of software — known as a Software Bill of Materials, or SBOM — which is becoming a standard building block for cyber supply chain risk management (C-SCRM).

This article will explore what SBOMs are, why they’re becoming table stakes for compliance, and how they help build software supply chain security.

What Is a Software Bill of Materials?

A Software Bill of Materials (SBOM) is an organized list that offers an in-depth description of the open-source and proprietary components, like modules, libraries and other software artifacts, within a software package. The SBOM, often created in machine-readable formats like SPDX (Software Package Data Exchange) and CycloneDX, includes key metadata such as component version, source, license, timestamp and more.

Within the context of software supply chain security, the SBOM is instrumental in mitigating security risks and managing known vulnerabilities in a software codebase. Software vendors can leverage SBOM data to identify vulnerabilities within their applications rapidly. For instance, in the lifecycle of open-source components, a discovered vulnerability can be tracked across all applications using that component. This ties into Software Composition Analysis (SCA), a method of automatically tracking open-source usage and identifying potential risks. It also ensures license compliance.

While vendors of developer-focused developer tools and vulnerability management tools focus on known vulnerabilities in open source, it is important to understand tools designed only to identify known vulnerabilities in open source components are blind to risks that aren’t known vulnerabilities, or supply chain risks in proprietary software that’s bundled into applications or devices.

SBOMs can identify several types of software risks:

Vulnerability: How many, the severity and the type
Dependency: Potential compatibility and security issues that appear within components and subcomponents when no longer maintained or supported.
License: Can this product be used commercially, or are modifications required to be publicly released?
Integrity: Is it officially supported software, or has it been tampered with?
Supply Chain Fragility: Are components end-of-life, out of date, or likely to break when security updates are attempted?
Malware: The presence of known destructive programs
Adversarial control: Ownership or contributions from high-risk entities that have been sanctioned by the U.S. government.

SBOMs play a pivotal role in the nation’s cybersecurity. The Biden administration issued guidance like Executive Order 14028 and underscored the necessity of adopting SBOM standards within the federal government.

Cyber Supply Chain Risks Create a Need for SBOM

Cyber supply chain risk spans borders and businesses. Software risk is the missing piece for unified visibility of vendor and product risk in a supply chain, especially one reliant on technology.

Most software depends on third-party components (libraries, executables or source code), but often there is limited visibility into this collection. It’s common for software to contain numerous third-party components that have not been sufficiently identified or recorded.

Some software vulnerabilities are the byproduct of the human process of developing software. If suppliers or customers don’t know what components are in their software, then they don’t know when they need to patch. They also have no way to know if their software is potentially vulnerable to an exploit due to an included component — or even know if their software contains a component that comes directly from a malicious actor.

The reality is this: When a new risk is discovered, very few organizations can quickly and easily answer simple, critical questions such as: “Are we potentially affected?” and “Where is this piece of software used?”

This lack of systemic transparency into the composition of software across the entire digital economy adds to cybersecurity risks as well as the costs of development, procurement and maintenance.

Where Government Regulations Are Requiring SBOMs

The government is acting on cyber supply chain issues — and it’s more than just a national security issue.

The Biden administration issued a National Cybersecurity Strategy, which highlighted issues related to supply chains.
The Cybersecurity and Infrastructure Security Agency (CISA) established an office to assist the government and industry in managing supply chain risks.
The UK’s National Cyber Security Centre issued new guidance for procurement specialists, risk managers and cybersecurity professionals regarding the mapping of supply chain dependencies.
Executive Order 14028 directs the National Institute of Standards and Technology (NIST) to develop guidelines for creating and publishing Software Bills of Materials (SBOMs) as part of federal procurement processes.
NIST Special Publication (SP) 800-218 provides guidelines for using SBOMs for secure software development.
The U.S. National Telecommunications and Information Administration has defined a minimum set of elements to be included in an SBOM.
The Office of Management and Budget memorandum M-22-18, issued on September 14, 2022, requires agency Chief Information Officers (CIOs) and Chief Acquisition Officers (CAOs) to obtain a self-attestation from software producers before using their software products.
U.S. agencies are mandated to obtain a self-attestation from the software producer.
U.S. agencies will be required to procure from their software producers SBOMs and documented processes to verify code integrity.

Industry Challenges & Attacks Make SBOMs Crucial

Many industries are striving to balance government regulations and geopolitical realities. This includes managing the increasing cyber risk to critical infrastructure due to geopolitical instability, such as the Russian invasion noted by the World Economic Forum, and de-risking supply chains based in China, as reported by the Financial Times.

In a relatively short span from December 2020 to July 2021, there were multiple widespread third-party and supply chain incidents. These included the SolarWinds attack in December 2020, the Accellion breach in the same month, and the Kaseya incident in July 2021.

These events showed that the attack surface for third-party and supply chain threats is far broader than previously anticipated, extending to IT management and file-sharing — fundamental and ubiquitous technological functions. These attacks exploited software vulnerabilities, compromised networks and implanted malicious code.

SBOMs Give Visibility into Software Components

Any software can introduce risks into a supply chain. As a system becomes more complex, it’s essential to have checks and best practices in place to manage software supply chain risk. Without solid foundations and a strategic plan for system growth and migration away from riskier software components and towards higher-quality software from diligent suppliers, it becomes difficult to concentrate efforts against future hacks, breaches, or compromises.

Software applications consist of a compilation of components. Increasingly, these components are open-source, which typically implies the following:

The components are free but still entail legal obligations.
Component quality varies widely, ranging from best-in-class to worst-in-class.
They are just as susceptible to cyber vulnerabilities as their commercial counterparts.
In the event of an incident, the author(s) — who could be unknown entities or linked to hostile nation-states — have no obligation to maintain the component or address flaws promptly.

Although open source gets a lot of attention for security issues, the security issues in open-source components are overwhelmingly from suppliers’ use of outdated versions of those components. The most recent version of an open-source library may be robust and well-supported. But if a supplier is using a version of that library that’s six major versions behind and riddled with vulnerabilities, that’s not a problem with open source per se. It’s a lack of investment by the supplier in software maintenance, which is a business issue. But that risk can be quantified by analyzing an SBOM – it can be measured, and therefore it can be managed.

SBOMs make it possible to manage these risks. They also enhance the visibility, transparency, security and integrity of both proprietary and open-source code in software supply chains. By 2025, Gartner projects that 60 percent of organizations developing or procuring critical infrastructure software will mandate and standardize SBOMs in their software engineering practices. This represents a significant increase from less than 20 percent in 2022.

SBOMs Need Frequent Analysis and Monitoring to Boost Security

There are tools available that can scan a Software Bill of Materials (SBOM) and generate a comprehensive list of software risks, including lagging indicators or risks (known vulnerabilities) and leading indicators of risk in advance of known vulnerabilities. Ideally, a risk remediation process helps to analyze for the usage or presence of specific components. This information is then cross-referenced with a database of vulnerable, unmaintained or otherwise risky component versions, prompting a notification to apply a patch.

However, this workflow can unravel if the risk database is outdated or issues arise during the component resolution process. It becomes exceedingly difficult, if not impossible, for organizations to confidently assert that their risk management processes cover all software, including those from third-party providers. The rapid evolution of the tech industry, marked by mergers, acquisitions and rebranding, adds another layer of complexity. This complicates the task of accurately associating risks with the corresponding software products.

Given the increasingly complex data landscape that engineering and operations teams must navigate to maintain software security, automating the generation, publishing, ingestion and monitoring of SBOMs can streamline the process with a tool like Exiger’s cyber risk management platform.

Remediation of the associated risks can then be integrated into current application security, operations, and vendor management programs without the need to adopt entirely new workflows.

Automate Software Supply Chain Assurance with Exiger

Exiger’s C-SCRM platform continuously ingests software supply chain data: changes to open-source components, maintenance and compliance history for software dependencies and commercial products, leading indicators of risk in the absence of known vulnerabilities, and supplier risks that software scanners don’t detect, such as end-of-life components and change-of-control in underlying dependencies. As software is delivered by vendors, contractors, or in-house developers, Exiger uses AI to help ingest or build SBOMs, analyzes all transitive dependencies, maps supplier risk metrics, and automates pass/fail security rules.

After the software is accepted, Exiger’s technology maintains continuous monitoring of all components and SBOMs and provides scheduled and event-driven updates in assurance data to trigger actions in customers’ contractual and security workflows. As suppliers raise their security posture and responsiveness, more robust governance can be applied to raise the bar for security.

Exiger’s SBOM analyses are both automated and continuous, and time-to-remediation can be measured and tracked in a completely auditable way. So if your terms and conditions say critical vulnerabilities in a product need to be remediated within a certain number of days, you have an automated audit on the supplier’s time to remediation. Updated SBOMs can be easily added to the platform to restart the compliance clock.

Additional resources

Expert Tips on C-SCRM and Building a Trusted Software Supply Chain

Video excerpt: Experts discuss how SBOMs can make a supplier more trustworthy. See more in the full on-demand webinar: Building a Trusted Software Supply Chain.