SBOM Security: Keeping Your Software Supply Chain Accountable

The dynamic nature of software development exposes the software supply chain to countless sources of both known and unknown vulnerabilities. These can take multiple forms, from insecure open-source software to zero-day exploits.

The connected product software revolution’s growing reliance on open-source software increases the risk and potential impact of supply chain attacks through methods, such as malicious injections. Finally, firmware presents a large and ever-expanding attack surface as the number of electronic devices grows nearly as quickly as the chain’s complexity.

To ensure product integrity throughout, automotive and medical device manufacturers are doubling their product security efforts. The search for a standardized process gave rise to the SBOM framework, which is gradually becoming ubiquitous in all product security industries.

However, generating SBOMs is only the first step.

To reap the full benefits of this framework, we need to first understand how it benefits the entire organization, and how it can be used throughout the full product security workflow– not just at the beginning. A few case studies that have been published recently, show the many ways to use and leverage an SBOM, that solve more problems than manufacturers previously thought.

What will your team do if a software component or a supplier’s entire software suite becomes untrustworthy overnight? Do you have a backup plan in place?

It’s a scenario that every OEM fears, but many will confront– with most admitting they have no idea what they would do. That’s because current threat intelligence, CVEs, and other risk management focus on vulnerabilities, leaving out a critical part of the product security puzzle.

As terrifying as it might be to deal with an out-of-order component, what’s worse is not knowing who you can trust in these moments of crisis. What if we used SBOMs as a way of gauging the reliability of our vendors across products? How would that shape who we work with and what message would it send to software suppliers about their own software supply chain practices?

When it comes to hardware, supply-chain risk management already exists. In fact, a manufacturer may already know who their backup supplier will be and exactly how long they need before delivering this missing component.

Yet, when a software supplier is unavailable or can’t be trusted, Chief Product Security Officers (CPSOs) are caught off-guard. Not only does the industry have no standard risk mitigation plan in place to address these kinds of incidents, but companies are expected to open a ticket and simply wait as their deployed connected products remain at risk.

Whether compromised, under a ransomware attack, DDoS attack or just went out of business, there are scenarios where manufacturers find that their supplier can no longer deliver trusted support.

A threat intelligence source informs the manufacturer of malicious code within software delivered by a third-party vendor. From there, the manufacturer is faced with three options. They can either open a ticket with a vendor and wait, fix it themselves, or replace the software component.

A ticket means long wait times – a risk that must be analyzed on a case-by-case basis. Replacing software requires immediately identifying a suitable fit and then deploying it to only the devices with this specific software component installed. Fixing it themselves requires better visibility into their software suppliers, components, and dependencies.

Without a way of identifying where this software is deployed and what would be a fitting replacement, the manufacturer’s systems remain compromised, and they don’t have a backup plan in place.

The first option of opening a ticket leads to painful questions: Will they get a patch? How long will it take? Are more product security blindspots waiting for them? With a proper SBOM, OEMs can prepare a more proactive defense in the event of a cyberattack on one of their software suppliers.

Relying on up-to-date SBOMs means product security teams can:

• Pinpoint exactly which component is compromised
• Quickly find a new vendor
• Patch the issue themselves
• Send out an update based on the information found in the SBOM

Without an SBOM, an OEM can wait weeks while their trust in the supplier quickly erodes. On the other hand, with the SBOM, they get visibility in just one click.

Since the SBOM can be compared to a list of software ingredients that deliver better visibility into software suppliers, their components, and dependencies, the OEM can use it to manage software risk effectively.

Here are a few scenarios:

1. A manufacturer receives threat intelligence that a vendor’s software component has been affected by malware, presenting a vulnerability in their products. The manufacturer hurries to identify which specific devices contain potentially malicious software. After carefully reviewing the SBOM, the vendor quickly discovers which products have this supplier’s software components and swaps out that software with alternative software.
2. A vendor’s code scanner detects malicious content within the software. What other software packets exist within devices from this supplier? A quick scan of device SBOMs can help quickly answer these questions.
3. A supplier is under attack and unable to provide support or patches. Is all of the latest code from this supplier malicious as well? The SBOM helps the vendor decide whether it can patch the issue itself or send out an update based on the information found in the SBOM.

When you have a rich pool of data to pull from, it becomes easier to gain a fuller picture of what’s going on beyond your organization. It’s also easier to put a backup plan in place.

A few frameworks exist today for implementing SBOM processes throughout the development lifecycle.

One of the most promising ones is what’s called “Dynamic SBOMs”. Dynamic SBOMs represent a new approach to continuous security which is integrated, automated, streamlined, and enforced at predefined stages within the development workflow.  This way, developers don’t waste time and product security teams reduce friction to speed up time-to-market. It’s a win-win for both product security and developers.

Another interesting approach is implementing SecDevOps into the process. According to a recent report by the NCSC and Capgemini titled Using the Software Bill of Materials for Enhancing Cybersecurity, “SecDevOps essentially combines the perspectives on production and operations. DEVops, where it’s all about developing the software, is linked to the Producing Perspective. Where the devOPS is linked to the Operation, because it is about bringing the (new) software into the operation through release, deployment, operation, and monitoring”.

They further explained, “During development, the SBOM can describe specific libraries (or identify the libraries to exclude), character sets, etc. An SBOM would be made available for any released version of a software product, as part of product documentation. Parts of the SBOM information must be tested every sprint as well. During operations, the SBOM should be monitored and updated on the findings discovered. These could be based on feedback from the field, but they can also be discovered through monitoring.”

During the past few years, a greater number of standards and regulations have begun to embrace SBOMs. For example, the US government mandates that all current and future government contractors must have produced product SBOMs to avoid potential compliance issues.

SBOMs are also a way to meet prominent industry standards, such as the ones from NIST. Looking at some of the main categories in NIST’s guidelines, we see many standards can be met using SBOMs:

SBOMs are also a way to meet prominent industry standards, such as the ones from NIST. Looking at some of the main categories in NIST’s guidelines, we see many standards can be met using SBOMs:

However, there are many security standards and frameworks– each with its own flavor of SBOM requirements.

The FDA Cyber SBOM (SBOM) for example differs from the requirements of the ISO. Not only that, but all of these compliance standards are also changing over time and across geographies, requiring manufacturers to continuously update their requirement validation process to stay in business. A lot can be learned from these standards, and how SBOMs can be used to improve both the security and the development processes.

Here are some standards and their mention of SBOMs:

BSA Framework for Secure Software

This industry-drafted framework offers guidance on secure development of software, the security capabilities of the software, and a secure lifecycle, citing standards and other authoritative guidance. It makes repeated references to the importance of cataloging third-party code, including advising “to the maximum feasible through the use of manual and automated technologies, subcomponents integrated into third party components are documented, and their lineage and dependencies traced.”

Building Security in Maturity Model

BSIMM (Building Security in Maturity Model) is a large group of software developers in academia, government, and industry that benchmark best software development practices.

They create guidelines for organizations to benchmark themselves against and assess where they are relative to their peers in their industry or overall. Version 9 of the BSIMM contains several SBOM-related requirements.

CISQ Trustworthy System Manifesto

The Council on IT Software Quality (CISQ) has published the “CISQ Trustworthy System Manifesto” on holding senior executives accountable for cybersecurity. Section III is “Traceable Properties of System Components” which includes requirement #2: “Evidence of provenance and trustworthiness should be carried forward with components and shared across the supply chain”.

This requirement also contains the following description: “When developers incorporate open source components, external APIs, or microservices, they should document their source and related data for inclusion in a System Bill of Materials (SBOM).”

FDA Premarket Guidance

The US Food and Drug Administration (FDA) has published a Pre-Market Guidance draft for medical device manufacturers seeking FDA certification. This guidance maintains that: “the device design should provide a CBOM in a machine-readable, electronic format to be consumed automatically” where Cybersecurity Bill of Materials (CBOM) is defined as “a list that includes but is not limited to commercial, open source, and off-the-shelf software and hardware components that are or could become susceptible to vulnerabilities.

FS-ISAC Third Party Governance

The Financial Section Information Sharing and Analysis Center (FS-ISAC) published “Appropriate Software Security Control Types for Third Party Service and Product Providers” in 2015. It includes Control Type 3B, “A Bill of Materials (BOM) for Commercial Software to Identify Open Source Libraries Used”.

ISO

ISO/IEC 27002:2005 and 27002:2013 have relevant sections that highlight the importance of best practices to ensure adherence to information security control objectives for an organization.

The perspectives identified in this document can be aligned with this international standard to show its relevance to a broad number of industries that use/produce information systems.

Linux Foundation OpenChain

The Linux Foundation OpenChain project mentions on the use of open source, stating: “A process exists for creating and managing a FOSS component bill of materials which includes each component (and its Identified Licenses) from which the Supplied Software is comprised.”

Manufacturers Disclosure Statement for Medical Device Security

The Manufacturer Disclosure Statement for Medical Device Security (MDS) was originally developed by the Healthcare Information and Management Systems Society (HIMSS) and the American College of Clinical Engineering (ACCE), then standardized through a joint effort between HIMSS and the National Electrical Manufacturers Association (NEMA). The MDS Form provides medical device manufacturers with a means for disclosing to healthcare providers the security-related features of the medical devices they manufacture.

MITRE Deliver Uncompromised

MITRE, in its report on the national security supply chain, “Deliver Uncompromised” recommends SBOMs as part of supply chain integrity. It notes, “If done properly, an SBOM can estimate the overall risk of the ensemble of software elements based on the risk of the individual elements.”

NIST’s Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software

Development Framework (SSDF)

A 2019 draft white paper recommends a core set of high-level secure software development practices. Among these, it recommends that organizations seeking to protect their software “Create and maintain a software bill of materials (SBOM) for each piece of software stored in the repository.”

OWASP Component Analysis Project

This industry expert group’s guidance on component analysis recommends “SBOMs from vendors and embed their acquisition in the procurement process” and a list of best practices using the SBOM to improve security.

Looking ahead, organizations that proactively examine and assess code that enters their ecosystem via a robust SBOM management program will be better prepared for impending government regulations on software supply chains, while keeping their IT infrastructure and customers safer. Strong SBOM programs allow organizations to build secure code in a cost-effective and efficient manner in the face of increasing cyber threats.

There’s still a way to go before SBOM becomes an integral part of the entire product development lifecycle. But new frameworks, regulations, and best practices show how beneficial SBOM integration is to the business. Implementing an SBOM management process, such as the one facilitated by Cybellum’s Product Security Platform will lead to enormous benefits and allow manufacturers to stay compliant and secure in the long run.

Rather than concentrating on identifying individual vulnerabilities, product security professionals can now take the view of seeing these vulnerabilities throughout the software supply chain. An SBOM supply chain document has been carefully tracking and constantly updating SBOM data, using an automated SBOM management solution, CPSOs should proactively ask suppliers about their security posture while also preparing alternative components – should the worst occur.

As OEMs, manufacturers are in a precarious position. On one hand, they are vendors responsible for the entire supply chain and must start to view their organization through the eyes of their customers. On the other hand, as manufacturers, they should also have to answer the same security questions that other manufacturers are asking their vendors.

This knowledge is now an untapped source of strength that can be used to help product security teams evaluate the trustworthiness of suppliers so that they can weather any impending storm as they see fit.