Project Glasswing and the Coming Inversion of Vulnerability Management

At Black Hat, I had the opportunity to join Jim Reavis (CEO, Cloud Security Alliance), Shailesh Athalye (Chief Product Solutions Architect, Qualys), and Bryan Willett (Field CISO, Rubrik) for the Cloud Security Alliance’s Weathering the Storm: Cybersecurity in the AI Era event. Our panel, “Project Glasswing: From Frontier Discovery to Enterprise Resilience,” explored what Project Glasswing and rapidly improving AI capabilities mean for enterprise cybersecurity. Glasswing gave us a useful starting point because it put numbers behind something many security leaders have sensed for a while: the economics of vulnerability discovery are changing fast and the operating to handle those needs to evolve rapidly as well.

That distinction matters. For most of the history of vulnerability management, discovering previously unknown weaknesses was expensive work. Researchers had to understand unfamiliar codebases, trace complex execution paths, identify unusual state transitions, build proof-of-concepts, and distinguish genuine vulnerabilities from interesting but nonexploitable behavior. Enterprises therefore built security programs around a reasonable assumption: vulnerability discovery would remain relatively scarce, while the organization's job was to collect those findings, rank them, and methodically work through the remediation queue.

Project Glasswing challenges that assumption rather dramatically. In its initial phase, approximately 50 participating organizations using a frontier AI model reportedly identified more than 10,000 high- or critical-severity vulnerabilities. The important lesson was not simply the volume. It was the realization that as AI accelerates discovery, the constraint moves downstream toward validation, disclosure, prioritization, remediation, and deployment.

I think that will ultimately be remembered as Glasswing's most important contribution. It demonstrated that AI could find vulnerabilities. But more importantly, it exposed a systemic problem: what happens to security when discovery approaches machine speed, but risk reduction still moves at human speed?

Five numbers that show why the model is changing

The statistics below measure different parts of the problem, so they should not be treated as directly comparable. Taken together, however, they illustrate the scale of the transition now underway.

There is a common thread running through all five numbers. Both attackers and defenders are acquiring the ability to perform security reasoning repeatedly and at machine scale, but most enterprise security processes were built for a world in which humans remained somewhere inside almost every important decision loop.

That assumption is beginning to break.

We are about to produce security findings faster than organizations can consume them

There is a useful way to think about vulnerability management as a pipeline. A potential weakness is discovered, validated, assigned some measure of technical severity, mapped to affected assets, prioritized in the context of the enterprise, assigned to an owner, remediated, deployed, and finally verified. Each stage has its own throughput, and the effectiveness of the overall system is constrained by the slowest stages rather than the fastest one.

Historically, discovery consumed a meaningful portion of that pipeline's scarce capacity. AI changes that. Once highly capable models can repeatedly inspect large codebases, reason across functions, formulate hypotheses, construct tests, interpret results, alter their approach, and continue searching without human fatigue, the marginal cost of producing another candidate vulnerability falls dramatically.

But increasing discovery throughput does not automatically increase remediation throughput. The security team still needs to establish whether the finding is real, whether the affected software exists in the environment, whether the vulnerable code is reachable, what privileges surround it, what controls already mitigate it, and what happens to the business if it is exploited. The application team may still need to test a patch, while the enterprise may still have a maintenance window several weeks away.

This creates an uncomfortable possibility. AI can make a vulnerability program dramatically better at finding problems without making the organization proportionally better at reducing risk. A 10x improvement in discovery coupled with no improvement in validation, prioritization, and remediation is not a 10x improvement in security. It may simply be a 10x improvement in our ability to manufacture unresolved work.

A vulnerability only matters in the context of what it can reach

This is where I think the vulnerability-management conversation needs to evolve. We have traditionally treated the vulnerability as the primary unit of analysis, but attackers do not experience an enterprise as a list of CVEs. They experience it as a collection of paths.

A vulnerability exists on a workload. That workload runs with an identity. The identity has permissions. Those permissions provide access to applications, services, APIs, and data. Each successful step changes what the attacker can do next.

Consider two workloads running exactly the same vulnerable software. One has no meaningful access to sensitive information, tightly constrained privileges, limited connectivity, and strong compensating controls. The other runs with an identity capable of querying a production database containing customer information. The CVE is identical, but the business risk clearly is not.

The difference is the path behind the vulnerability. One useful way to model that path is Vulnerability → Workload → Identity → Data → Business Impact. For AI systems, an increasingly important variation is AI Agent → Identity → Tool/Application → Data.

This is why data context belongs inside exposure management rather than beside it. If I know a system is vulnerable but cannot determine what sensitive information that system, its identities, or its applications can ultimately reach, I am missing one of the most important variables in the risk calculation.

Zscaler Data Security Posture Management (DSPM) takes this data-centric approach by continuously discovering and classifying sensitive information across hybrid and multicloud environments, understanding access and entitlements, identifying public exposure and misconfigurations, and correlating these conditions to surface higher-risk combinations. The objective is not simply to identify where sensitive data exists, but to understand the conditions under which that data can become exposed.

That becomes especially important when vulnerability discovery is cheap. If AI gives me 100,000 findings, the valuable question is no longer which ones have the highest technical severity. It is which ones create a credible path to something the organization cannot afford to lose.

The metric that matters is time-to-risk-reduction

Security teams have traditionally measured vulnerability operations using vulnerability counts, mean vulnerability age, SLA compliance, and mean time to remediation. Those measurements remain useful, but the AI era requires a more consequential metric: time-to-risk-reduction, or TTRR.

TTRR asks how much time passes between identifying meaningful exposure and materially reducing either the probability or potential impact of exploitation. Importantly, patch deployment is only one possible endpoint. If I can immediately remove external reachability, revoke an unnecessary privilege, isolate a workload, restrict application access, or prevent a compromised identity from reaching sensitive data, I may have reduced substantial risk before the software owner produces a permanent fix.

Operationally, that means examining six delays:

• Discover: How long can a meaningful exposure exist before we know about it?
• Validate: How quickly can we distinguish a genuine weakness from noise?
• Contextualize: What asset, identity, application, and sensitive data sit behind the exposure?
• Prioritize: Which exposure creates the most credible path to material business impact?
• Enforce: What control can break that path fastest?
• Verify: Did we actually reduce exposure, or did we simply close a ticket?

The last two steps matter more than they might appear. An attacker does not care about the administrative status of a remediation workflow. The attacker cares whether the path still works.

Then the other side of the equation accelerated

Our CSA discussion became even more interesting when we moved from AI-assisted vulnerability discovery to AI-assisted attack. There is a tempting interpretation of autonomous cyberattacks that says nothing fundamental has changed because the underlying techniques remain familiar.

There is some truth to that. Recent AI-driven intrusion research has involved techniques security practitioners know well: exploitation, privilege escalation, credential harvesting, reconnaissance, and lateral movement. What changes is not necessarily the individual technique. It is the control system sequencing the techniques together.

An autonomous agent can observe an environment, formulate a hypothesis, choose an action, evaluate the result, update its understanding, and choose the next action. It can perform this loop repeatedly without requiring a human operator to make each intermediate decision. Conceptually, the attacker starts operating a continuous loop: Observe → Reason → Act → Evaluate → Adapt → Repeat.

The important variable is therefore not simply how many commands the attacker can execute per second. It is how quickly the attacker can reduce uncertainty about the environment.

Autonomous attack is fundamentally a search problem

Imagine the enterprise as a graph. The nodes are users, workloads, identities, applications, APIs, AI agents, credentials, and data stores. The edges represent what each entity can reach, invoke, authenticate to, modify, or retrieve.

A human attacker entering that graph faces a search problem. Which credential should I test? Which system can this identity reach? Which privilege enables escalation? Where is valuable information stored? Which sequence of actions connects my current position to that data?

Skilled attackers are good at solving this problem, but human cognition, time, and attention naturally limit the number of paths they can investigate. Autonomous systems alter those economics. They can enumerate alternatives, test branches, discard dead ends, combine newly acquired information with earlier observations, and continuously optimize for progress toward an objective.

This is what I mean by attack-loop compression. The time between observation, decision, action, and feedback declines, while the number of hypotheses the adversary can evaluate increases.

Once that happens, the defender has two options. We can try to make every defensive decision as quickly as the attacker makes offensive decisions, or we can make the attacker's search problem dramatically harder. The strongest architecture does both.

Zero Trust shrinks the graph. Data security tells us which paths matter.

This is where Zero Trust and data security come together in a particularly useful way. If a compromised identity can reach 500 systems, an autonomous attacker has hundreds of possible branches to explore. If Zero Trust policy reduces effective reachability to the three applications required for that identity's legitimate task, most of those branches disappear before the attacker ever gets to test them.

That is the first defensive advantage: shrink the attacker's search space.

But not every remaining branch has the same consequence. One application may contain public information, while another may provide access to intellectual property, regulated customer records, credentials, proprietary models, or training data. Understanding that difference requires visibility into the data itself, who and what can access it, and the posture of the systems surrounding it.

That is the second defensive advantage: identify which remaining paths lead to something valuable.

Zscaler's data security capabilities provide that additional context by discovering and classifying sensitive data, identifying who and what has access to it, detecting overly permissive access and misconfigurations, and correlating those conditions to uncover hidden attack paths. DSPM can also support remediation toward least-privileged access, directly reducing the number of useful paths available to compromised users and non-human identities.

This gives us a relatively simple model for AI-era exposure management. Zero Trust reduces the attack surface that an adversary can traverse, while data security identifies the paths whose traversal would create meaningful business impact.

That is much more useful than simply producing another list of critical findings.

Patching faster is necessary, but breaking the path is the objective

If AI finds vulnerabilities faster than organizations can patch them, the industry cannot solve the problem exclusively by demanding that every enterprise patch everything immediately. That is operationally unrealistic.

Enterprises operate systems requiring extensive testing before upgrades. They rely on third-party software, legacy platforms, embedded dependencies, operational technology, and business processes that cannot simply be restarted whenever a new critical finding appears. Even in exceptionally well-run environments, there will always be some interval between vulnerability discovery and permanent remediation.

The more useful question is what can happen during that interval. If I cannot immediately eliminate the vulnerability, can I remove external exposure? Can I restrict which identities can communicate with the workload? Can I reduce its privileges? Can I isolate it from critical applications? Can I remove unnecessary access to sensitive data?

That is the difference between managing vulnerabilities and managing exposure. The patch eliminates the defect. The security architecture prevents the defect from becoming a path to material impact.

This is also where data security posture becomes operational rather than observational. Discovering sensitive data is only the beginning. The more consequential questions are which identities and applications can access it, whether those permissions are necessary, what security conditions surround that access, and which combinations of vulnerability, privilege, connectivity, and data create an exploitable path.

If a critical vulnerability exists on a workload with access to highly sensitive data, reducing that access may be one of the fastest ways to reduce immediate risk while permanent remediation proceeds.

The next vulnerability-management system looks more like a control loop

If we extend the lessons from Glasswing to their logical conclusion, the future vulnerability-management architecture begins to look very different from today's scanner-to-ticket workflow. Discovery becomes only one sensor inside a continuously operating risk-reduction system.

An AI system may discover a potential weakness and generate evidence supporting the finding. The enterprise can validate whether the behavior is reproducible and establish whether the affected software actually exists. Asset and identity context can determine reachability and privilege. Data security context can establish what sensitive information sits behind that path and who or what can access it.

At that point, prioritization becomes much more meaningful because we are no longer asking whether the vulnerability is severe in isolation. We are asking whether the vulnerability completes a credible path to business impact.

The system can then identify the intervention most likely to reduce risk. Sometimes that will be a patch. In other cases, it may be an access-policy change, removal of a data entitlement, credential rotation, workload isolation, configuration adjustment, or another compensating control.

Most importantly, the process cannot stop when someone marks a ticket resolved. The system needs to verify that the path has actually been broken and feed that observation back into its understanding of enterprise risk.

The resulting loop is relatively simple: Discover → Validate → Understand the Path → Prioritize → Break the Path → Verify.

I like this model because it avoids turning AI-era security into a collection of new product categories. Vulnerability management, Zero Trust, identity, data security, and AI security are different control domains, but from the attacker's perspective they are parts of the same graph. The attacker is trying to find a path through that graph, and our job is to continuously remove the paths that matter.

What I would change next week

During this panel, we were asked what one change CISOs should make based on what we have learned from Glasswing. My answer is that security leaders should stop treating vulnerability management primarily as a process for finding and closing vulnerabilities and begin managing it as a race to break the attack paths that can produce material business impact.

Start with your most sensitive data. Understand where it exists, which applications use it, which human and non-human identities can access it, and which workloads and AI systems sit on paths toward it. Then overlay vulnerabilities, exposures, permissions, and connectivity. That exercise will almost certainly produce a very different priority list from one based on CVSS scores alone.

Next, measure how quickly your organization can break those paths. If a patch requires three weeks, can access be restricted in three minutes? If an identity is overprivileged, can the unnecessary entitlement be removed? If an application should never communicate with a sensitive workload, can that relationship be eliminated altogether?

Finally, examine the human queues. If an autonomous attacker can execute thousands of decisions while your organization waits for an analyst to correlate context, an application team to establish ownership, or a change process to approve containment, those delays are no longer merely operational inefficiencies. They become part of your effective exposure.

Project Glasswing gives us an important preview of what happens next. As vulnerability discovery approaches machine scale, finding the weakness becomes less scarce. Validation, context, prioritization, remediation capacity, and time become more scarce.

At the same moment, autonomous attackers are getting better at searching enterprise environments for the combinations of vulnerabilities, identities, permissions, applications, and data that produce useful attack paths. That is why I believe the defining security problem of the AI era will not be finding every vulnerability before the attacker does. That is an increasingly unrealistic race.

The more defensible objective is to build an environment in which finding a vulnerability does not automatically give the attacker somewhere valuable to go. Zero Trust limits where the attacker can move, data security tells us what we cannot afford to lose, and AI can help defenders continuously reason across both. Together, those capabilities give us something much more useful than another vulnerability score: the ability to understand which paths matter and break them before an adversary can turn exposure into impact.

That, to me, is the enduring lesson of Project Glasswing. When finding the vulnerability is no longer the hard part, breaking the path becomes the security problem that matters most.

Explore with us how Zscaler can bring Zero Trust, vulnerability management, DSPM, and AI Security together to reduce exposure around sensitive data.