Four thousand eighty-two. That’s a big number.

What am I counting? The number of cars I saw on my commute this morning? Nope. The number of grains of rice in my Big Bag of Basmati Rice™, under the counter in my kitchen? Also nope, but now I’m hungry. No, I’m counting CVEs so far this year.

Before you say “That’s pretty good, Richard!”, let me clarify. This is a search of CVEs with a CVSS score greater than or equal to 9 and released in 2023, which I carried out on October 31 on Let that sink in a moment. We’re not at year end, and we’ve seen over four thousand 9+ vulnerabilities. That is rather sobering… So, what’s a CISO to do?

Dimensions of Risk

I think the first realization is that this represents risk in a couple of different dimensions. Obviously, these are all really serious and so they’re potential vectors for a breach. More subtle but just as risky, though, is the fact that now these are out there, explaining to the board why you didn’t deal with one will be very hard. Knowingly being insecure is a tough sell, even though it represents the harsh reality of securing a large attack surface which must be monitored 60 minutes an hour, 24 hours a day, and 365 days a year (and no, you don’t get the 1 leap day off as a freebie). If that feels daunting, it should.

Vulnerability Prioritization Is A Losing Game

The challenges defenders face are absolutely brutal, and I firmly believe that the way we’re approaching the problem is broken.

In the face of the onslaught of high-criticality vulnerabilities, we tend to run (not walk) toward vulnerability prioritization; that is, how important is this, really? How likely is an attacker to compromise my network because I have exposed <this vulnerable asset> to the Internet? Frameworks such as EPSS attempt to codify this (see:, and the idea is correct. Given what we know about these critical vulnerabilities, we should be able to estimate the chances that a particular one will become exploited, right?

If you haven’t been following, in the Exploit Prediction Scoring System (EPSS)’s own words,

[EPSS] is a data-driven effort for estimating the likelihood (probability) that a software vulnerability will be exploited in the wild. Our goal is to assist network defenders to better prioritize vulnerability remediation efforts. While other industry standards have been useful for capturing innate characteristics of a vulnerability and provide measures of severity, they are limited in their ability to assess threat. EPSS fills that gap because it uses current threat information from CVE and real-world exploit data. The EPSS model produces a probability score between 0 and 1 (0 and 100%). The higher the score, the greater the probability that a vulnerability will be exploited.

This sounds great, but in my opinion EPSS is still nascent: it’s a useful thrust, but it’s not where it needs to be today.

Moreover, I still think convincing a board that a breach stemming from a known vulnerability was okay because it had a low EPSS score is really unlikely. You can let me know how that works out for you, if you want. Boards are more sophisticated on these matters than we think and do process input in terms of risk, but I think right now EPSS is still too low in the shared consciousness of the community.

Once again, it’s that “knowingly at risk” thing where things go wrong. Even if we can demonstrate from a game theoretic standpoint that risk acceptance makes sense, not everyone will understand that patching for all the incoming threats is becoming increasingly impossible. We have to be choosy or the cost of security becomes too high. You can’t react to everything.

Something Has to Give

I think that’s the unlock right there: react. Getting out of reactive mode is one of the most important things you can do. The current glut of new CVEs only plays into that, as defenders stretch further and further, trying to get in front of a continuous flow of emergencies. We’ve reached the point where it’s not exceptional anymore, it’s just business as usual. That’s got to break.

A better way is to continually work at reducing the attack surface before the vulnerability ships, as opposed to exercising that “fast twitch” muscle fiber to respond to things that come at you. If you knew you didn’t have any impacted assets, that 4082 number up there could just as easily be zero. I think that’s where becoming less reactive (a hard world to live in) and more proactive pays dividends.

Time For A Perspective Shift

Let’s look at one of our team’s most recent 0-day disclosures: a CVSS 9-point-something in f5’s BigIP (see: post) for context. Now, you can view that in two different ways. First, there’s the reactive way. You see the vuln, you get on it fast, and you patch it. Job done, but very reactive. Oh, and you better patch it fast, as we’re already hearing that it’s being exploited in the wild. That’s not good.

Second, you could continually harden your attack surface, so you approach your network the way an attacker would. If you had been following that process you would have previously decided that this panel shouldn’t be exposed to the Internet even though there was no disclosed vulnerability for it. So, in the cold light of day (as opposed to in a blind panic) you would have removed it from the attack surface. Then, when the vulnerability did finally drop, there would have been nothing to do. Ta da! Safer, and fewer weekends spent at the keyboard.

More to the point, with this perspective you’re approaching your risk more strategically, which is a must for getting off the tactics treadmill. It won’t always work this way: vulnerabilities are going to be found in things you had to expose in order to do business, but that is much less common. Furthermore, if you’ve been approaching your network like an attacker would, you will already know exactly where those vulnerable assets are at disclosure time, and so you get to skip the whole discovery step and go straight to fixing things.

Exchange Reactive Tactics for Proactive Strategy

I understand I am woefully simplifying the challenges here: defenders are overloaded with work, and so get trapped in this tactical doom loop for legitimate reasons, always on the back foot. I am arguing, though, that by approaching your network much more like an attacker would, you can buy down quite a bit of reactive work with well-planned proactive thinking. You do this by minimizing the points of attack, reducing the attack surface at the places that an attacker would push on first.

For example, as someone who works on the offensive side of things, I don’t pay a lot of attention to ever-so-slightly weak TLS issues in my attack surface. Even if they’re known vulnerabilities, much of the time an attacker needs to be a nation state to make much headway. Conversely, I see certain other exposures as much more tantalizing (you get a sense for blood in the water when you do this for a living) even if at the time of contact I’m unaware of exactly how to exploit it. I figure that if I need to, I can just dig and find my own vulnerability.

Trading reactive work for proactive is, in my opinion, a must do in order for businesses to flourish in an increasingly fast-paced threat environment. You cannot keep just moving faster, you have to figure out how to move smarter. The answer is in plain sight: approach things like your adversary does and get ahead of the threat.