Artificial intelligence has changed almost every aspect of software development and cybersecurity. But perhaps one of the most profound changes is happening in an area that has traditionally received less strategic attention: How organizations manage software vulnerabilities.The basic vulnerability-management model has remained relatively consistent for years. Scan software, identify CVEs, assign severity scores, prioritize the findings, and send them to developers for remediation. That approach was never a perfect representation of risk. In the age of AI, however, its limitations are becoming impossible to ignore.The problem isn’t simply that organizations have more vulnerabilities to address. The amount of software being produced is expanding rapidly, vulnerability discovery is accelerating, and the time required to develop exploits is shrinking. AI-enabled attacks can also combine vulnerabilities in ways that create attack paths that are difficult to anticipate manually.The result is a growing gap between the number of vulnerabilities security teams can identify and the number they can meaningfully investigate and remediate. We need to close that gap by changing the question we ask. Instead of asking, “How many CVEs do we have?”, we should be asking, “Which vulnerabilities create meaningful risk in our environment?”Severity is not the same as riskA CVE tells us that a publicly identified security vulnerability exists. It does not, by itself, tell us how likely that vulnerability is to be exploited against a particular organization. That distinction is fundamental.The Common Vulnerability Scoring System (CVSS), for example, is designed primarily to communicate technical severity and the potential impact if a vulnerability is successfully exploited. But severity does not necessarily tell us whether an exploit exists, whether the vulnerability is being exploited in the wild, whether the vulnerable component is exposed, or whether the vulnerable code path is executed in a particular environment.Two organizations can therefore have exactly the same CVE in their environments and face very different levels of risk. One organization might have the vulnerable component sitting behind multiple layers of protection, with no external exposure and no relevant execution path. The CVE is identical. The risk is not.Another might have it running in an internet-facing production application supporting a critical business process. The CVE is identical. The risk is not.This is why vulnerability programs built around static severity scores can produce a misleading sense of progress. Teams may spend significant effort closing large numbers of findings without necessarily reducing the organization’s most consequential exposure. That creates what I would call “CVE theater”: Measuring activity rather than meaningful risk reduction.AI is changing the economics of exploitationThe urgency of this shift is being amplified by AI. The amount of code being developed is increasing dramatically. Even if vulnerability density per line of code declines, the sheer growth in software volume can result in greater overall exposure. At the same time, a growing proportion of modern software depends on open-source components, expanding the amount of code that organizations must understand and secure.Attackers are also benefiting from automation. Tasks that previously required substantial manual effort can increasingly be accelerated by AI. The combination of more vulnerabilities and a collapsing time-to-exploit window creates a fundamentally different security environment.That means organizations cannot afford vulnerability-management processes that depend on lengthy, sequential manual triage. The security program has to become more contextual, continuous, and automated.Start with less riskOne of the most effective ways to improve vulnerability management is to stop thinking only about remediating vulnerabilities after they appear. We should also ask how to reduce the number of vulnerabilities entering the environment in the first place. That starts with the software foundation.Using hardened or curated base images and language libraries can reduce the vulnerability footprint before deploying applications. First-party code can be addressed through Static Application Security Testing (SAST) and AI-assisted code scanning, while configuration weaknesses can be identified through security configuration frameworks such as Security Technical Implementation Guides, or STIGs. This matters because vulnerabilities are only one dimension of software security. A system can contain relatively few CVEs and still be dangerously configured. Excessive privileges, weak authentication settings, or other configuration issues can give attackers opportunities to gain an initial foothold or move laterally.STIG scanning addresses this second dimension by evaluating configuration against established security requirements. These tools are essentially automated security checklists that can identify and, in some cases, remediate configuration weaknesses. The objective should be to make the software as secure as possible before it becomes someone else’s remediation problem.Scan what is actually runningAnother important shift security leaders should consider: Production is the source of truth.Historically, organizations have often scanned registries or repositories before software reaches production. That provides useful information, but it reflects perceived risk rather than what is actually deployed. Production environments change. Images change. Configurations change. New vulnerabilities are disclosed after deployment. Consequently, organizations need visibility into what is actually running and need to assess it continuously. This is where production scanning, reachability analysis, and environmental context become essential.Network reachability can help determine whether a system is externally accessible. Software-level reachability can provide another layer of insight: Is the vulnerable code path actually being executed? Those questions can dramatically change the remediation priority.Build a risk-based remediation modelOnce we know what is actually running, the next step is to evaluate vulnerabilities based on the context that matters. That means looking beyond CVSS.Threat intelligence can provide important signals. CISA’s Known Exploited Vulnerabilities catalog, or KEV, identifies vulnerabilities known to be exploited. The Exploit Prediction Scoring System (EPSS) estimates the likelihood that a vulnerability will be exploited within a specified timeframe. Those signals can then be combined with production exposure, reachability, configuration, business impact, and how long a vulnerability has remained exposed. The result is a much more useful question for engineering teams: Which vulnerability should we fix first, in this environment, and why?That is a substantially different operating model from handing developers a spreadsheet containing thousands of CVEs sorted by severity.Continuous risk management is the goalThe ultimate objective shouldn’t be a perfectly empty vulnerability dashboard. In a modern software environment, that is neither realistic nor necessarily the right measure of security. The goal should be a continuously improving understanding of actual risk. That requires a layered approach. Start with secure software foundations, scan first-party code, harden configurations, understand what is running in production, determine reachability, incorporate threat intelligence, and prioritize remediation according to real-world exposure and impact. It also requires temporal discipline. Different categories of vulnerabilities may warrant different remediation windows, rather than treating every finding identically.We need to know which doors are open, which ones an attacker can reach, which ones lead somewhere important, and which ones represent the greatest risk right now.AI has made the old model increasingly difficult to sustain. But it also gives us an opportunity to rethink vulnerability management around a more meaningful objective. We don’t need to know only how many doors exist in the software. We need to know which doors are open, which ones an attacker can reach, which ones lead somewhere important, and which ones represent the greatest risk right now.That is the difference between counting vulnerabilities and managing risk. And in the AI era, that difference is becoming essential.The post AI is speeding up exploits. Vulnerability spreadsheets can’t keep up. appeared first on The New Stack.