Software Bill of Materials (SBOM) is a way to capture the names and versions of all the components used to build an application. It’s a critical tool for software composition analysis (SCA) because it helps us map known vulnerabilities to the components we rely on. Given that 80 to 90% of software application code comes from third-party components, keeping track of these vulnerabilities and updating to patched versions is a vital part of managing the risks these components introduce.  

If you ask most SCA vendors, they’ll tell you that’s the whole game: Track your components, patch when needed and you’ve got your risk covered. But that’s only part of the story. Composition analysis is necessary, but not sufficient. It won’t tell you about the vulnerabilities lurking in your third-party components that haven’t been reported yet. 

You might argue, “We can’t defend against what we don’t know.” Sure, but that’s the wrong mindset. These aren’t unknown unknowns. We know they’re there; we just haven’t found them yet. In fact, software defect rates are well documented. On average, you can expect about 1,000 defects per 100,000 lines of code (KLOC), and roughly 5% of those are exploitable. Do the math: For every 100KLOC of third-party code in your stack, you’re likely carrying around 50 exploitable vulnerabilities, many of which no one’s publicly reported. 

The point isn’t to calculate the precise number of hidden vulnerabilities; it’s to accept that they’re there. If your dependency footprint exceeds 100KLOC (and for most modern applications, it does), you can safely assume you’re shipping vulnerabilities. Saying, “There aren’t any vulnerabilities in our dependencies,” or even, “We can’t be sure there are any,” is wishful thinking. Composition analysis didn’t solve this problem; it just told us where to start. 

So, with this newly instilled certainty fresh in our minds, let’s turn to the key question. Why should we care about as-yet undiscovered vulnerabilities in our third-party code? And if you will extend me the grace to do so, I will answer your question with another question. Why should we care about as-yet undiscovered vulnerabilities in our own code? From a security operations and incident response perspective, there is no difference between an exploitable vulnerability in code you wrote and an exploitable vulnerability in a dependency. The application is compromised, the data is being sold on the dark web and the servers are encrypted. The reason we should care is that the impact is the same regardless of origin.  

This also helps to answer the other question: How much time and money should be spent looking for and remediating new, unknown vulnerabilities in third-party code? You should be spending the same amount of time and money looking for vulnerabilities in your dependencies as you do on your own code. You should be using the same static and dynamic analysis tools, building test suites, having code reviews of changes – everything you do to make sure “your” code is secure, you should do for your dependencies, because when it comes to managing risk in an application, it’s all just the code.  

Three Big Reasons

In fact, I can go one step further. You’re actually more at risk from your third-party code dependencies. Why is that? Three big reasons.  

1. It’s accessible.  Attackers have easy access to a lot of your third-party code dependencies, since most of it is open source and hosted on GitHub. It’s easier to find vulnerabilities and develop exploits if you have source access, and in a lot of cases attackers don’t have access to your organization’s proprietary code.  
2. It’s high reward. Attackers who find a vulnerability in a popular open-source library can use it to attack all the applications that use that library, not just yours. The Log4j remote code execution vulnerability is a great example of the kind of payoff attackers can get from finding vulnerabilities in a dependency. There were millions of vulnerable applications. 
3. It’s most of your application. When 80-90% of your application is third-party code, most of your exposure is inherited. So, you can see how source access, incentives and risk composition mean that you’re more likely to be hit with an exploit against one of your dependencies than something you wrote yourself. 

There is a longstanding tradition in security product marketing to describe security products as “solutions.” SCA products are often described as a solution to open-source and third-party component risk. Hopefully, I have made it clear that they are just the beginning.  

From an incident responder’s perspective, it makes no difference whether the compromised code was written by your engineers or pulled in from a package manager. If you’re running security tools, doing code reviews, and adding security test cases for your own code then you should do the same for your dependencies. In fact, you should probably do more. 

The less of this work you do, the more security tech debt you accumulate. And you know what happens when someone calls in your security debt? A ransomware payment.