SBOMs and nationally organized VEX initiatives are powerful tools in fighting cybersecurity– if only they would be used.
Tom Alrich, a private Supply Chain Cybersecurity consultant, earned his wings at Honeywell and Deloitte while also co-leading the US Department of Commerce’s National Technology & Information Administration (NTIA) Energy Sector SBOM Proof of Concept. His unique perspective makes it hard to reconcile an unfortunate reality where SBOMs are being created but not used.
Perhaps this would be slightly less concerning to the automotive, medical, and logistics industries if all software components were developed in-house but the reality is that 90% of today’s software components come from third-party vendors. This can mean hired specialists or open source libraries, which contain potentially hazardous software packets with no specific owner.
That’s not to say that third-party components are a bad thing. The practice of using third-party software to develop the foundation of new technology has allowed for companies to focus less on reinventing the wheel and more on developing their specialized IP. “In fact, most software you have today would never, ever get written because it would be so hard without doing without components,” said Alrich.
As new products enter the market, SBOMs are getting left behind, living on supplier hard drives and not traveling together with connected devices. This hurts a critical part of the development loop, where customers in the field can identify concerns and draw manufacturer attention to a potential cybersecurity vulnerability. Since customers aren’t asking these hard questions, suppliers are moving these potential vulnerabilities to a lower priority, risking being forgotten until a potentially catastrophic incident occurs.
The trouble with today’s SBOM and VEX documentation
SBOMs, or a Software Bill of Materials, gives developers greater insight into all the software components that are integrated into a device. This is supplemental to a national VEX, Vulnerability and Exploitability Exchange, database. Together, these machine-readable docs have the potential to run a device’s credentials against a national database where vulnerabilities and solutions are harmoniously exchanged.
Unfortunately, “Probably 90%+ of what’s in the NBD, alongside their CVE name, are not necessarily relevant to your device. If 100 vulnerabilities are returned, you may contact a supplier to discover that 95 of those hundred are not actually exploitable,” Alrich explained. “Essentially, those vulnerabilities are not really there. There are various reasons why that can happen but ultimately, they are not relevant to your device.”
This puts a large strain on organizations who may have hundreds or thousands of customers, all reaching out to see if their device components have been compromised. Increased frustration is added to the mix as many organizations are ramping up their resources allocated towards SBOM and VEX documentation, only to have it ignored by customers.
For example, in Log4j, only one module (Log4Shell), was at risk. Your SBOM may show that it has Log4j but not Log4Shell, so it doesn’t apply to you since this specific component of Log4j wasn’t ever implemented in the product. But, if a customer doesn’t know that, lots of resources and man hours are wasted explaining to customers why the threat is not exploitable and why a patch won’t be developed.
That’s why all SBOMs and VEX docs must be machine readable– so the system can inform you of newly emerged vulnerabilities, not the other way around.
How should product security teams prepare themselves regarding SBOMs and VEXs?
If teams haven’t started developing SBOM and VEX documentation yet, they can expect frustration along the development path. Teams will need to track down all components, their authors, and the possible vulnerabilities they may introduce to an end-user.
Alrich explains, “They need to prepare themselves for frustration because right now, SBOMS are successfully used in the supplier community for their own internal purposes. They’re identifying problems in their own products, leading them to say, you know, these components, they’re just too risky. Everything you read about SBOMs is really about end-users, such as hospitals, electric utilities, insurance companies, banks, and really anyone who uses software. Everybody is faced with the same problems.”
But not all sectors have responded equally. “A few industries, such as healthcare or more, are a little ahead of the curve in terms of actually doing something about it. This is in addition to the European auto industry. While they are only a small number of companies, they have a significant impact as they are big.”
“They’re using SBOMs heavily for license management purposes, not for cybersecurity purposes.” While this situation isn’t ideal, they do have a system in place which allows for them to receive, analyze, and create action items surrounding information found in the SBOMs they receive from suppliers.
How does this approach to SBOMs impact end users?
There are executive orders that push government organizations to request SBOMs. Then…nothing.
The average product has 150 components. That kind of reviewing and updating can’t be done manually and there is currently the adoption of automated systems is too low, so while SBOMs are nice to have, organizations are just sitting on these documents.
“What’s holding them back is the users have no idea what they’re going to do with them [SBOM and VEX documentation], they don’t care, and they’re not asking. On the other hand suppliers are worried about the non exploitability problem. This is all compounded by a continuously delayed VEX schedule,” said Alrich. Our best insights as of now rely on SBOMs, Cyclone DX, and the International Common Security Advisory Framework (CSAF). “Every supplier is going to have to do a bunch of learning in order to create a VEX. Some suppliers will do it very easily, including the big organization. But a lot of others are going to say, ‘Look, I don’t have time for this.’ and won’t put out VEXs.”
Ultimately, the largest issue surrounding SBOMs is that no one is actively reading them or finding a way to organize and manage the security capabilities that come with them
Shifting the mindset across ecosystems
As of now SBOM and VEX creation is far outpacing the demand coming from the field.
If we want to create safer development and deployment ecosystems, organizations and customers are going to have to begin implementing the knowledge gathered by machine-readable SBOM and VEX documentation. Once this harmony is established, we will begin seeing the balance shift, from cybersecurity teams in fixed defensive positions to one of proactivity, ensuring higher safety for drivers, medical device patients, infrastructure managers, and beyond.
