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?
Why should risk management for products be limited to hardware?
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 industry have no standard risk mitigation plan in place to address these kinds of incidents, 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.
Let’s take an example of a brand specializing in writing software for infotainment units.
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. Either they can open a ticket with a vendor and wait, fix it themselves, or replace the software component altogether.
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, then deploying it to only the devices that have 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.
Replacing the flour, but not the cake
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:
- 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.
- 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.
- 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.
Strengthening software resilience and forecasting risk
Rather than concentrate on identifying individual vulnerabilities, product security professionals can now take the view of seeing these vulnerabilities throughout the software supply chain. By 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 own 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.
This article is part of a series by Ronen Lago, Cybellum Advisor. Read Part 1: Making the most of SBOMs: A Product Security Perspective
