Vulnerability management in the AI era: Shifting from identification to decisions

This podcast episode is based on the Deloitte Luxembourg article below and includes content generated, assisted, or edited using artificial intelligence technology. It has been reviewed by a human prior to publication. The voices featured are synthetic. This podcast is provided for general information purposes only and does not constitute any kind of professional advice rendered by Deloitte Luxembourg. Deloitte Luxembourg accepts no liability for any loss or damage whatsoever sustained by any person who uses or relies on the content of this podcast. 

Introduction

In the age of artificial intelligence (AI), vulnerability management is shifting from identifying flaws to decision-making responsiveness.

Recent advances from frontier AI models in automated discovery have pushed this issue onto boardroom agendas. While this attention is welcome, it should not trigger panic or lead to the simplistic conclusion that organizations must just “patch faster”.

Security teams already know the ground is shifting: while the total volume of vulnerabilities grows, the window between public disclosure, active discovery, and weaponized exploitation is shrinking.

We are entering a world where semi-autonomous systems can multiply existing capabilities at scale, constrained only by computing power and energy. Yet, this technology is not magic. Early testing by Mozilla, Cloudflare, and curl creator Daniel Stenberg indicates that while frontier AI systems can surface hidden flaws, their outputs remain non-deterministic and require human validation.¹

Ultimately, this acceleration will widen the gap between what automated tools can catch, and an organization’s internal capability to prioritize, decide, mitigate, or accept risk.

Why traditional vulnerability management is no longer enough

Many vulnerability management programs were built for a much slower operational era. A familiar model still dominates:

• Periodic scheduled scans;
• Massive comma-separated values (CSV) exports;
• Raw common vulnerability scoring system (CVSS) prioritization; and
• An implicit handover to IT operations for remediation during the next standard maintenance window.

This legacy approach is structurally misaligned with today’s threat landscape.

When a legacy process is flooded with significantly more automated findings, risk compounds rapidly. Prioritization must be optimized to handle real-world operational constraints like testing cycles, change approvals, deployment windows, and decision rights.

This friction is precisely where exposure accumulates. Compliance postures and true risk exposure radically diverge the moment processes designed for human-speed threats meet machine-speed discovery.

Each year, less than 1% of disclosed common vulnerabilities and exposures (CVEs) are ever actively exploited in the wild. This shows that the real challenge is identifying the select few that pose an actual danger to the business.

In practice, this includes vulnerabilities already known to be actively exploited—such as those listed in the Cybersecurity and Infrastructure Security Agency’s (CISA) Known Exploited Vulnerabilities (KEV) Catalog, which highlights threats confirmed to be actively used by attackers—as well as zero-day CVEs, referring to vulnerabilities that are unknown to the vendor and exploited before a patch or fix is available, leaving organizations with no time to prepare or mitigate the risk.

^{Expand image}

The real shift: From finding vulnerabilities to making decisions

The response must shift from “finding and scoring” to “prioritizing and deciding.” The key question is no longer whether a flaw exists, but whether it matters in the organization’s specific context and what action should follow.

A raw CVSS score cannot determine true criticality. Severity matters, but so do exploitability, active exploitation evidence, network exposure, and potential impact. A critical vulnerability on an internet-facing, crown-jewel system is not equivalent to the same vulnerability on an isolated test server.

Threat intelligence should be integrated into vulnerability management. Sources like the CISA KEV Catalog, and Luxembourg-developed open-source solutions like Vulnerability-Lookup and the Malware Information Sharing Platform (MISP), can help teams separate theoretical from active threats.

This distinction matters because not every finding requires the same response. Many flaws can wait for the standard patching cycle, while others require immediate containment, emergency changes, temporary controls, or explicit business risk acceptance. Consequently, vulnerability management is becoming an operational risk discipline rather than a technical enumeration exercise.

The teams that perform best will not be those that produce the longest lists of findings, but those that can translate technical discovery into action, identifying what needs immediate fixing, what can be contained, what can be accepted temporarily, and who decides.

Building the defensive foundations

To achieve true agility, organizations must establish three operational pillars:

1. Maintain an absolute asset baseline

Organizations cannot protect what they do not know exists. While perfect configuration management databases (CMDBs) are rare, a strict baseline is non-negotiable. Teams must know which assets exist, where they reside, who owns them, which business processes they support, which ones face the internet, and which software components they use.

For critical systems, software bills of materials (SBOM) are no longer optional. Without this visibility, it is impossible to know if a newly disclosed flaw applies, how urgent it is, or who has the authority to act.

2. Redesign workflows for decision velocity

Beyond redefining what constitutes a critical flaw, policies must be redesigned for operational speed. Vulnerability management is distinct from routine patch management.

Organizations must be equipped to move a critical finding from initial detection to verified remediation or explicit risk acceptance within roughly 48 hours. This demands pre-authorized emergency change protocols, clear escalation paths, predefined business-impact risk criteria, and application owners who understand their responsibilities long before a crisis hits.

3. Minimize blast radius and assume breach

Security models must operate under the assumption that some vulnerabilities will inevitably be exploited before they can be patched. Network segmentation, strict access controls, multi-factor authentication (MFA), static credential removal, hardening, monitoring, detection, response, and recovery remain vital. Layered defenses buy the one commodity that organizations need most when automated discovery accelerates: time.

Vulnerability management is now a governance issue

The first and second lines of defense must collaborate. Security and IT operations cannot redesign vulnerability management alone while risk, compliance and internal control remain distant observers. Together, they must define what “critical” means in context, when emergency change windows are triggered, what thresholds justify risk acceptance, and which key performance indicators (KPIs) and key risk indicators (KRIs) should be reported.

Mean time to remediate, asset coverage, and crown-jewel systems exposure should drive an integrated risk discussion. Boards and regulators will increasingly ask direct questions: when did you know, how fast did you act, and who accepted the risk?

AI is both an enabler and a multiplier of risk

AI is a double-edged sword. Defensively, AI utilities help developers identify vulnerabilities early. Conversely, that same technology increases delivery pressure, enables inexperienced teams to deploy insecure code faster, and fuels unapproved shadow AI usage.

AI will not inherently make software secure. Without intentional guardrails, incentives and controls, it will simply increase the volume of issues that security teams must handle over time.

Practical short and long-term responses

Where should organizations begin?

In the short term, organizations should focus on clarity and tightening the basics. This means:

• Defining what a “critical vulnerability” really means in their environment;
• Establishing emergency remediation and escalation procedures;
• Integrating threat intelligence into the prioritization procedures; and
• Reinforcing core cyber hygiene through MFA, hardening, and tighter identity and access management (IAM) controls.

The immediate goal is ensuring the organization can move from detection to remediation, containment, or explicit risk acceptance within a short timeframe.

In the longer term, the priority should shift toward structural resilience, moving from reactive vulnerability management to an intelligence-led, resilient model.

^{Expand image}

Embrace the opportunity to scale your vulnerability management program

The focus on AI-led vulnerability discovery is an opportunity not to instill fear, but to trigger the right conversations between security, IT, business owners, and the second line of defense.  

No organization will eliminate the structural asymmetry between attackers and defenders. However, those that act now by bringing the right stakeholders around the table can materially improve their position.

Invest in visibility, decision velocity, and disciplined execution for a world where adversaries operate continuously and at machine speed. Human decisions, made faster, closer to the business, and with clearer strategic intent, will determine who stays ahead.