For much of this year I’ve been advocating for a risk-based vulnerability management approach, rather than the “industry standard” checkbox-based approach. I’ve been talking to customers, both directly and at various events (such as Red Hat Summit in Boston, Red Hat Summit Connect in Dallas, directly with customers in Singapore, and virtually with customers). A few weeks ago I also published on the Red Hat Security blog: Do all vulnerabilities really matter?
The gratifying thing is that I’m not alone! Earlier this week I saw this article: Why CVE Management as a Primary Strategy Doesn’t Work which nicely dovetails with what I’ve been talking about, and a few months ago there was Only 3% of Open Source Software Bugs Are Actually Attackable, Researchers Say.
Given there is such a low exploitation rate, and also given there is such a high vulnerability rate that continues to grow YoY, one has to step back and ask oneself: do all of these matter? Do we need to update all of them? The answer is, generally, “no” yet it’s a little more nuanced. Sometimes it’s hard to know which vulnerabilities will turn into something that we care about. Yet there are some metrics we can look at.
For instance, in the 2021 Red Hat Product Security Risk Report we started reporting on known exploits and the data was enlightening. For example, there was a 10% exploitation rate of Critical-rated vulnerabilities, a 2.5% exploitation rate of Important-rated vulnerabilities, and the numbers kept dropping… 1.7% for Moderate-rated and 0% for Low-rated. Now, as time goes on those may edge a bit higher for Critical and Important vulnerabilities — after all, we know that there are ancient vulnerabilities that are exploited years after they’re made public (which is why patching these things is so critical!). But few are exploited immediately. So if we focus on those most likely to be exploited, and where a successful exploit would have the most damaging impact, focusing on fast fixing (and patching!) of Critical and Important (or High, as some call them) vulnerabilities makes the most sense.
But that’s a really tiny number, overall. Again, using the 2021 Red Hat Product Security Risk Report, there were 293 Critical and Important vulnerabilities, versus 1303 vulnerabilities rated Moderate and Low. Fixing and patching 293 is a lot easier, for both producer and consumer, than fixing all 1596. And these are just vulnerabilities that affect a shipping Red Hat product.
We can do a bit of correlation here with data available from NVD. Unfortunately I wanted to use the allitems.csv from MITRE to import into SQLite but it seems… well, it seems that the CSV file likes to have differing numbers of columns which breaks an easy import. Hopefully future APIs will help, or the JSON format files like NVD does. The APIs available from NVD won’t help get these statistics either so I downloaded each of the JSON files. And then because I don’t get to nerd out and write much python these days, I created nvd-cve on GitHub which will let me play around with some of the data.
The important thing to recognize is that, as per the NVD data, there has been steady growth in CVEs the last few years (big surprise!). 2021 had 10% YoY growth with a total of 20078 CVEs and thus far in 2022 we’re at greater than 8% YoY with a total of 21733 CVEs published on NVD to-date. That’s a lot of CVEs to fix!
Vendors can try to keep up, at considerable expense in terms of time and energy. That’s a lot of patches to produce, and the picture is incomplete. For example, this probably under-represents the number of vulnerabilities in open source because a lot of projects don’t bother with getting CVEs assigned or don’t know they fixed a security issue. We know this vastly under-represents proprietary software because they often don’t bother labeling Low or Moderate (Medium) vulnerabilities as vulnerabilities and will either fix them silently or ignore them. Having talked with a number of proprietary PSIRTs, I know this for fact. And why not? It’s not as though anyone will find out, for the most part. The beautiful transparency of open source allows for everything to be shown — warts and all. We can’t hide it and we don’t want to hide it, which is great news for consumers. If a vendor doesn’t apply a fix, but you know there’s a vulnerability and it concerns you, you have the option to mitigate. As they say, knowledge is power!
Unfortunately with proprietary software, you don’t have this knowledge and so don’t have the power to mitigate on your own. That’s a benefit of open source, even though sometimes it makes things look uglier. You can assess the risk in what you know — it’s not possible to assess the risk in what you don’t.
So where does that leave us? Well, I’ve been working with open source for over 20 years so I’m obviously biased towards it. With open source, you’re not going to get all the fixes. And honestly, you don’t want all the fixes. It’s too expensive to test and patch for every single vulnerability discovered. With that number going up, the cost will go up too. Most people didn’t start using open source to patch all the things… they got into open source because it provided value and increased the speed to delivery of whatever it is they’re building on top of that open source. Yet, even though you won’t get all the fixes, you do get all the information, and can mitigate on your own if you feel so inclined. That’s a benefit you don’t get with proprietary software and one we shouldn’t quickly forget.
Yet at the end of the day, no one wants to deal with CVE lists in the thousands where most of those vulnerabilities don’t matter and honestly, whether you care to admit it or not, a lot of vulnerabilities out there aren’t even on your little (or big!) list. So why not do the sensible thing, set the list aside, and focus on the risk of these vulnerabilities. Critical and Important issues are most likely to be exploited, so concentrate there. If a Moderate issue does get exploited (the risk of which is quite low and the risk of it causing significant damage even lower) then look to the vendor for a fix. Typically they’ll do the right thing and provide the fix without you having to ask. That’s because most vendors truly do want to protect their customers yet, at the end of the day, the software you’re using isn’t being used because it has no known vulnerabilities… it’s being used to create value for you as a customer, and most likely your own customers further downstream.
Now, to be clear, I do work for a software vendor and while the thoughts above are my own, they align with our approach. We focus on the risky software that could potentially pose a threat to our customers. You may also be interested in reading An Open Approach to Vulnerability Management which we updated a month or so ago with more information on exploitable vulnerabilities.
Also I took my first shake at some home-grown photo manipulation for fun. The explosion came from freepnglogos.com and the CVE screenshot is from the NVD site. It’s not really a checklist of CVEs to fix but you should get the drift… I really would enjoy watching those lists burn ;)