AI Accelerates Exploits: Your CVE Spreadsheet Is No Longer Enough

For years, vulnerability management has followed an almost liturgical script: scan, identify CVEs, assign a severity score, prioritize, and send to the development team for patching. It was an imperfect model, but it worked as an approximation. With the emergence of AI, its seams have become too visible. The problem is not only that there are more vulnerabilities, but that they are discovered earlier, exploited faster, and the volume of software grows unchecked.

The consequence is a growing gap between what a security team can identify and what it can actually investigate and remediate. According to The New Stack, the right question is no longer "how many CVEs do we have?" but "which vulnerabilities generate real risk in our environment?" It is a shift in focus that, in an SME, makes the difference between spending hours on appearance tasks and protecting what truly sustains the business.

Severity is not the same as risk

A CVE indicates that a known vulnerability exists. It does not say if there is a public exploit, if it is being actively exploited, if the affected component is exposed, or if the vulnerable code path runs in your infrastructure. The CVSS system communicates technical severity and potential impact, but not contextual risk. Two organizations can have the same CVE and live opposite realities: one has it behind several layers of protection, with no external exposure; the other, in a production application accessible from the internet that supports a critical process.

When a vulnerability program is built only on static scores, there is a risk of falling into what the article calls "CVE theater": measuring activity instead of risk reduction. Closing hundreds of findings can give a sense of progress without having touched the most dangerous exposure.

AI changes the economics of exploitation

AI accelerates code production and, with it, the total volume of software. Even if vulnerability density per line decreased, the growth in volume can increase overall exposure. Added to this is the growing dependence on open source components, which expands the surface that must be understood and secured. And, at the same time, attackers benefit from automation: tasks that previously required manual effort are now accelerated, and the window between the disclosure of a flaw and its exploitation is compressed.

For an SME, this means that vulnerability management processes based on manual and sequential triage fall short. It is not about hiring an army, but about making the program more contextual, continuous, and automated.

Less risk from the start

One of the most effective levers is to stop thinking only about remediating afterward. We must also reduce the number of vulnerabilities that enter the environment. The article proposes several ways:

• Curated or hardened base images and libraries, which reduce the vulnerability footprint before deployment.
• SAST and AI-assisted scanning on proprietary code, to detect flaws in early phases.
• Secure configuration frameworks such as STIG, which evaluate and, in some cases, correct configuration weaknesses.

This matters because a system can have few CVEs and be dangerously configured. Excessive privileges, weak authentication, or insecure settings can give an attacker the initial foothold or the ability to move laterally. Configuration is a dimension of risk that is often ignored in reviews focused only on CVEs.

Scan what actually runs

Another mindset shift: production is the source of truth. Scanning registries or repositories before deployment gives useful information, but it reflects perceived risk, not what is deployed. Images change, configurations change, and new vulnerabilities are disclosed after deployment. That is why continuous visibility of what is running, reachability analysis, and environmental context are needed.

Network reachability helps determine if a system is accessible and if a vulnerable path can be executed. Without that context, prioritizing is guessing. At ForgeNEX we see that many SMEs do not need more tools, but rather to connect the ones they already have with a real risk logic: which asset is critical, what is exposed, and what is truly exploited.

What we recommend from ForgeNEX

For a small or medium-sized IT team, the transition can begin with concrete steps:

1. Living inventory of assets and dependencies. Without knowing what runs and where, any prioritization is worthless.
2. Exposure context. Mark which services are on the internet, what data they touch, and what processes sustain the business.
3. Automate triage. Integrate the scanner with the incident manager and enrich each finding with known exploitability and real exposure.
4. Harden the base. Minimal images, controlled libraries, and secure configurations reduce noise from the source.
5. Measure reduced risk, not closed tickets. The goal is not to close CVEs, but to lower the probability of a material incident.

This approach connects with what we already advocate in AI Security: the defensive mindset is no longer enough: passive defense falls short when the attacker automates. It also fits with the idea of Graph RAG: when relationships are the evidence, because risk lives in the connections between assets, not in a flat list of CVEs.

The good news is that you do not need a large budget to start. You need to change the question and stop treating severity as if it were risk. In an environment where AI accelerates exploits, vulnerability management must be continuous, contextual, and automated. The opposite is to keep filling out spreadsheets while the exploitation window closes.

Source: The New Stack. Analysis and adaptation: ForgeNEX.