Op-Ed: Are ‘Common Vulnerabilities and Exposures’ the reality of chronic cyber insecurity?

Common Vulnerabilities and Exposures (CVEs) are exactly that. They’re endemic problems for cybersecurity. Lists of known CVEs are generated in an ongoing litany of risks for systems of all kinds.

This is no minor task. The list of CVEs cited by recordedfuture.com for July lists 85 Very Critical Future Risk Score CVEs. That’s not too inspiring.This specific list includes Microsoft, Huawei, Cisco, Apache Tomcat, Oracle, and other major leaguers. It’s that much of a problem. Remember these are “known” high risks.

From this sort of distribution, you’d think that these things were top priorities, instant action matters. This is in fact routine business for cybersecurity. Notifications are given, and someone has to act on them.  

So, does CVE reporting work or doesn’t it?

The train wreck of cybersecurity breaches in 2026 tells another story. Obviously, there were vulnerabilities and they weren’t fixed, if they were reported.

There’s a trick to this. Reporting may come from a variety of sources. It can come from security experts, publishers, and the happy go lucky IT people who find them as a result of a breach of their own systems.

Nobody’s saying that CVE reporting is infallible. It can’t be. Some things actually are unknown despite efforts to ensure security. It’s not as though people are in any great hurry to promote news about security risks in their software, either.

The commercial fact is that CVEs are like land mines. They blow up when someone triggers them. All reasonable care can be and often is taken, but this is a very fluid environment, particularly when you’ve got things like Claude looking for vulnerabilities as a sort of raison d’etre.

Adding zest to this mess is the fact that risks come in levels. Some risks are basically glitches. Others expose access to entire systems. Any type of CVE reporting is by default a mix of these levels of risk, although prioritized according to relevance and importance.

Generic case study and managing the CVE workload in practice

There’s an interesting and painstakingly clear example of what happens in an organization managing risk by Australian Cybersecurity Magazine. If you’ve ever worked in any organization, this article will ring loud and true. The author, Amit Shingala, CEO of Motadata, spells it out.

CVE disclosure is the beginning. What happens next is a handling issue. You need to read the article, but it’s plain to see that fixes are more labours of love than defining what’s actually done about CVEs.

The scenario is this. The building might burn down. There are known risks, and in the case of CVEs, fire accelerants are all over the place. Someone has the extinguisher, but will it get to the fire if it breaks out? Will the accelerants be removed? Anyone’s guess, and that’s despite all this information going to people who know what they’re doing.

Future risks, automated CVEs, SaaS, and what’s next?

Now add to this idyllic environment the unquantifiable number of risks, operations, systems, types of systems, and heirloom problems from old software vs AI and dangerous bad actors.

Let’s summarize:

You get one shot at fixing a CVE before it hits the fan.

In-house IT and SaaS may or may not be able to manage the threats.

SaaS isn’t a synonym for cybersecurity and may not be contracted to do it anyway.

You can automate CVE reporting and fixes with AI, maybe, but you still have to oversight and make sure that the fixes work.

The obvious process is Read CVEs/List relevance/Fix/Check fixes

Questions arise, and none of them are rhetorical:

How do you assess risk in dollar terms, as in what could be fatal?

If X project is derailed by a risk, what are your contingency options?

Can you handle any projected volume of CVEs?

How do you actually prioritize risk, even if you can do it in your sleep?

How much of the inevitable obsolete stuff is an inherent risk?

What’s the workload for managing CVEs, and can you do that?

What about timeframes, meaning when do you know you’re secure?

You can’t bounce when you hit a bottom line

Earlier this year, the Council on Foreign Relations nailed a critical point. Claude is just the beginning. As AI rewilds itself, there may be many Claudes, and they’ll be feral.

Claude is benign. It has a critical lead in its field. It may be able to predict vulnerabilities as well. It makes sense that new code is made bulletproof, but that’s exactly what Claude’s finding vulnerabilities in previously deemed safe software environments.

The expression “bottom line” refers to the bottom line on a balance sheet. When an organization takes a breach hit, the shock from the hit instantly transfers to the bottom line. It may be a hit to confidence, the stock price, or hard money outlays in compensation.

Bottom lines can’t be ignored. Nor can CVEs.