It started a while back. A software bill of materials (SBOM) was a unique idea put forth as a way to aggregate data about open-source licensing for individual software components of a system. It was designed as a way to track your nested inventory of software so that it could be used programmatically by other people or systems to ensure the provenance of the software that enterprises use overall.
The Growth of SBOM
Over time, the concept of SBOM has morphed. What started as a pillar of the Linux Foundation’s Open Compliance Program has transformed into something much bigger. Add to that the fact that the White House started asking its vendors for SBOMs and the result was an explosion of new types of x-BOM variants.
Just like that, the SBOM demand was unleashed. Our clients, investors, vendors, customers, and more started talking about SBOM. I can even swear I heard my cat meowing something the other day about SBOM.
Shortly after the rise of SBOM, we started hearing about VEX as well. The Vulnerability Exchange (VEX), which lives alongside an SBOM, is a document that indicates whether a product or products are affected by a known vulnerability or group of vulnerabilities. The overall goal of a VEX is to allow a software supplier or other party to assert the status of specific vulnerabilities in a particular product.
When it comes to SBOM and VEX, there are a couple of key points to remember.
- SBOM is a good thing. It is important that a software vendor denotes which software components they’re using in their own supply chain. The transparency of what software developers are using in their supply chain will go a long way to helping us find technological and human ways to secure it.
- The VEX is also a positive thing to accompany and live alongside the SBOM, it’s important to note which vulnerabilities exist for an SBOM. But, it’s important to say that exploitability is subject to many conditions, and even with VEX, exploitability cannot be determined accurately with existing vulnerability formulas. That’s why VEX is not a good enough predictor of how a particular vulnerability might affect a target.
BUT Here Lies The Problem — What About Injected Malicious Code?
I want to share my take on Software Supply Chain attacks. I’m not saying I’m right; I’m only human, and my wife says I’m always wrong, but I’ll try anyway.
SBOM & VEX probably won’t solve your software supply chain security problem. They might help with some scenarios, but they are lacking one important thing. They don’t detect the real problem.
Let’s talk briefly about vulnerabilities (again). Even If a piece of vulnerable code is exploitable, It doesn’t mean you can be attacked. Some combination of conditions must occur for a vulnerability to be truly exploitable. For example, a vulnerability might require that you have to be calling the vulnerable function, specific input has to occur, there can’t be any other mitigating factors, and your system has to be exposed to the internet, or any other kinds of odd combinations of situational exploitation requirements.
On the other hand, when somebody plants malicious code in any of the dependencies you use, or in your own code/binary — That malicious code will run, GUARANTEED. If an attacker wants to compromise a target, they wouldn’t write a piece of code that had a vulnerability that MIGHT get executed. They would embed a piece of malicious code into the dependency tree that WILL get executed and WILL result in a successful compromise. Because of this, malicious code will always be more dangerous than vulnerable code. The issue is that SBOM doesn’t help with the malicious code problem.
Malicious Code VS Vulnerabilities By Example
An example of the difference between malicious code and vulnerable code in dependencies is Log4j. It had been in the wild for years, and nobody knew it was risky, and (as far as we know) wasn’t actively being exploited prior to the disclosure. Most likely, the existence of this vulnerability was not a maliciously inserted piece of code (although it COULD be) instead it’s likely that this was an error by a developer without knowing it existed.
If this had been an intentional attacker who had hacked into Log4j and acquired the ability to modify the package, they would have intentionally deployed active malicious code into the Log4j package and not just opened a vulnerability gap. With active malicious code, the attacker could guarantee that their attack gets executed. With a vulnerability insertion, they have to hope that additional mitigating factors don’t get layered on top of the backdoor causing them to fail at their attack. If malicious code was inserted, it’s a done deal, your organization has now been breached.
When somebody wants to attack your company through your software supply chain, they will likely choose to inject active malicious, not simply “vulnerable”, code to one of the weakest links in your dependency chain. They will find a dependency downstream that they are able to modify, inject the malicious code, and wait for that attack to trickle up to you as the target.
Having an SBOM of a modified package won’t help you until the vulnerability is discovered. SBOM & VEX are effective only for known vulnerabilities, they don’t tell you anything about malicious software or targeted style attacks.
Another crazy example of injected active malicious code was the attack against the javascript module “UA-Parser-JS”. Attackers compromised the NPM account of the author of this extremely popular package used for parsing user agent data from web requests. This particular package is downloaded over 8 million times PER DAY! The attackers injected active malware that executes password exfiltration along with crypto mining. Based on the package’s download rate and the amount of time the compromised package was available it is estimated that over 188,000 unique downloads of the malicious code likely occurred. What’s really scary is that if US-Parser-JS had an SBOM, NOTHING would have changed. SBOM + VEX wouldn’t have changed the fact that active malicious code was made available downstream, tricked upstream, and actively executed. It wasn’t a known vulnerability that SBOM+VEX helps remediate.
There are lots more examples of these types of attacks, but I’ll stop there since by now you get the idea…
At the end of the day, we can patch vulnerabilities all day long, and I’m not saying companies should stop, (some) vulnerabilities need to be patched. But the real power of stopping software supply chain attacks lies in detecting actual active malicious code in your code, dependencies, and binaries before the software reaches your customers.
