Security Research Should Study Security: Collapsing Costs, Failing Metrics, and Rethinking Value in the Age of AI

1. What Is Technical Progress For?

Bug detection has long been one of the defining pursuits of software security research. A new method that finds more real vulnerabilities can often make a convincing technical contribution on that basis alone. The number and quality of its findings—especially confirmed vulnerabilities, CVE assignments, and even proofs of concept (PoCs)—have served as some of the most direct, hard evidence of research achievement. In the age of AI, however, this seemingly self-evident consensus faces a fundamental challenge.

Vulnerability discovery earned its privileged position because it was an expensive, scarce capability. Understanding complex systems, locating deep flaws, and establishing their consequences all demanded substantial expertise and human labor. Attackers lived under the same constraint: a vulnerability being technically exploitable did not mean anyone was willing to invest the time and effort to exploit it. Under those conditions, better vulnerability discovery had an obvious value.

But the conditions that made that judgment obvious are changing dramatically.

AI is rapidly driving down the cost of finding vulnerabilities, understanding complex systems, and even constructing exploits. Work that once consumed enormous amounts of expert time can increasingly be done at scale with compute. We do not yet know where this transformation will settle. Perhaps vulnerability discovery will become almost trivially cheap. Perhaps automated repair and formal verification will advance just as quickly. Or perhaps new technical bottlenecks will emerge where nobody expects them. The collapse of barriers to attack might even make stronger defensive vulnerability discovery more urgent than ever. Whatever happens, the conditions that have underwritten our research priorities and evaluation practices for decades are being rewritten.

At this moment of upheaval, we have to confront a more basic question. It never really went away; the old technical and economic conditions merely made it comfortable to sidestep:

What, exactly, are we protecting? When a technique makes progress on paper, what gives us grounds to call that progress in security?

To answer, we first need to revisit the economics that once made “finding vulnerabilities” seem equivalent to “improving security.”

2. Scarcity, Incentives, and the Economics Beneath Security Research

Between discovering a vulnerability and changing the security of the real world lies an entire web of economic relationships.

For an attacker, a vulnerability’s existence does not automatically make it worth exploiting. Finding the flaw, understanding its context, and building a reliable exploit chain all cost real resources. Even when an attack is technically feasible, a rational attacker will walk away if the expected payoff does not justify the investment. Whether a real system gets attacked therefore depends not just on whether a weakness exists, but on whether someone has the ability and the economic incentive to exploit it. For a long time, the scarcity of expert labor provided a form of protection in its own right: many systems escaped serious attack not because they were impregnable, but simply because they were not worth an attacker’s time and intellectual effort.¹

Defenders face a different set of unforgiving economic constraints. Finding a vulnerability is only the beginning. Confirming it, assessing its actual business impact, designing a fix, checking compatibility, and finally deploying the update all consume scarce engineering resources. Worse, the returns on defense are often invisible. A successful attack produces visible damage; a successful defense leaves behind an event that never happened. The cost of fixing a vulnerability is real and certain. The loss it prevents exists only in a counterfactual. With limited resources and attention, defenders must weigh the probability of exploitation, the potential damage, and the cost of remediation to decide which risks deserve priority.

Attackers and defenders want entirely different things. Yet for decades, they have shared the same upstream technical bottleneck: finding previously unknown vulnerabilities requires extremely expensive expertise and labor.

For attackers, discovering an unknown flaw first means gaining an opening that has not yet been defended. For defenders, finding that same flaw before an attacker does means buying time to patch it or mitigate the risk. Both sides want a clearer picture of a system’s hidden weaknesses, sooner than the other side gets one.

That is precisely why “faster, more accurate bug detectors” have held such an irresistible appeal for both sides. Provided they do not drown their users in false positives, they can translate directly into a first-mover advantage. It became perfectly natural for the community to equate “progress in bug detection” with “progress in software security research.”

But this apparently sound equivalence rests entirely on one central premise: discovering unknown vulnerabilities is expensive, scarce, and the dominant bottleneck. What happens to the structure built on that premise when the premise breaks?

3. AI: The Game Changer

How will people look back on 2026? Perhaps it will be remembered as the year AI truly crossed the threshold and entered the real world in force. From the early chatbots to today’s agents, from the first wave of AI skepticism to recent breakthroughs in AI for mathematics, large models are reshaping technical work at an unprecedented depth. Security researchers cannot keep pretending the train is still running on the same tracks.

One familiar response within the community is that the only way forward must be to train or fine-tune models so the next generation of AI can perform security tasks better. But that is, at its core, AI research rather than security research. Security researchers should ultimately care about security itself. The question we need to keep asking is this: at what fundamental levels is AI rewriting the foundations of our field? There is no final, static answer yet. Nobody can say with confidence what next year’s models will be capable of.

Still, looking at AI’s trajectory since 2022, three structural trends are already clear:

• AI is ending the scarcity of vulnerability discovery.
• AI is sharply reducing the cost of attack.
• AI is also lowering the barriers to heavyweight defensive techniques.

3.1 From Scarcity to a Flood

Scarcity has long been a basic constraint on human activity. But when code generation—and even the analytical intelligence behind it—becomes abundant, perhaps excessive, almost every research paradigm built on the scarcity of intellectual labor starts to wobble. Old bottlenecks disappear. Abundance breeds problems of its own, no less difficult to solve.

AI is rapidly eroding the scarcity of vulnerability discovery. Deep flaws that once took human experts weeks to locate can increasingly be found in batches at negligible compute cost. Heuristics that security experts once had to distill by hand can now be generated dynamically by a large model, tailored to the code in front of it. As models’ ability to understand code continues its steep climb, an uncomfortable conclusion follows: if a so-called bug detector’s central contribution is merely to encode some particular piece of expert experience or a clever heuristic, then even an excellent showing on today’s benchmarks may give it very little lasting academic or engineering value. Under this pressure, vulnerability discovery research may retain its old weight only by opening up genuinely new dimensions of vulnerability—defining an entire class of microarchitectural attacks, as Spectre and Meltdown did (hard to believe Spectre was nine years ago)—or by delivering a step change in soundness guarantees.

Meanwhile, as scarcity gives way to abundance, the flood itself becomes the central problem.

As of October 26, 86,000 CVEs have been disclosed in 2026, compared with just 48,000 in all of last year. This explosion clearly owes much to AI-powered vulnerability discovery. But you found a bug. Now what? Someone still has to fix it. Even if AI writes the patch, a human maintainer ultimately has to review it, merge it, run regression tests, and take responsibility when production falls over. When vulnerabilities arrive far faster than maintainers can fix them, discovery alone turns from an asset into a liability. Automated program repair with AI carries enormous expectations, but its reliability in real, complex systems remains far from satisfactory.

This reversal—from scarcity to a flood—pushes the real bottleneck relentlessly downstream. In a world of never-ending high-severity alerts, how do we make repairs both cheap and dependable? When every vulnerability looks serious, how do we assess actual risk and decide what comes first?

3.2 Cheaper Attacks

OpenAI and Anthropic are investing heavily in safety alignment and trying to reserve advanced cybersecurity capabilities for so-called “verified users.” But it is difficult to see how this can truly keep attackers out. The fundamental problem is the dual-use nature of security tools, combined with task decomposition. An attacker with basic technical competence can break a malicious operation into ordinary technical requests: “Write a fuzzing harness for this interface,” or “Analyze the state-machine logic in this decompiled binary.” A model cannot simply refuse such requests without sacrificing its usefulness for normal programming. Meanwhile, open-source models without strict safety alignment have already crossed the threshold of practical usefulness after targeted fine-tuning.

The anecdotes are beginning to accumulate: the South Korean banking incidents,² iOS reverse engineering,³ and others.⁴ They fit precisely the economic logic discussed earlier: much of the modern digital world’s security rests not on systems being unbreakable, but on attacks being too expensive to be worth a hacker’s time. AI is dismantling that barrier and rewriting the attacker’s utility function. Long-tail targets and complex attack chains that once offered too little return on the effort are becoming profitable.⁵

For a time, what really kept people out of malicious hacking was often not a security mechanism at all, but a thriving ecosystem such as the App Store. When a capable geek could make good money writing software—safely, legally, and respectably—the opportunity cost of becoming an attacker was simply too high. That implicit condition, which helped keep the peace for more than a decade, is now coming apart. On one side, AI lets attackers with modest skills punch far above their weight. On the other, automated agents turn attacks into background jobs with “zero marginal time cost.” Attacking at scale no longer has to consume a top hacker’s precious personal time. We may be heading back toward something resembling the early internet’s Wild West, with sophisticated attacks once again becoming commonplace.

Vulnerabilities and attacks will never disappear. The good news is that our security infrastructure and awareness are nothing like what they were in the early internet. The bad news is that even when both sides use the same AI, attackers retain an inherent asymmetric advantage. Following that logic, we can readily sketch a few familiar directions:

• On offense, the hacker’s hard-earned experience is being turned into a production line. Recovering semantics during reverse engineering, filtering false positives from static analysis, rapidly weaponizing N-days after a patch drops: AI is filling exactly the gaps where automation once depended most heavily on human intuition.
• On defense, the center of gravity shifts from plugging holes to containing risk. Once “nobody will bother attacking me” stops being a workable assumption, defense is bound to move toward more aggressive runtime monitoring, service degradation, and hard isolation at the lower layers of the system.

Yet these extrapolations from familiar frameworks still live partly on paper. What does a truly large-scale attack built around AI actually look like? Its real-world form has not yet settled. The sudden collapse in attack costs must already be incubating new, self-sustaining criminal businesses at scale. But the “Chernobyl moment” that will define cybersecurity in the AI era has yet to arrive.

And if the security industry’s usual way of doing things is any guide, it will probably take that Chernobyl before practitioners finally have an undeniable reason for funding: “Pay up for a rebuild now, or we’re the next.”

3.3 Cheaper Defense

Fortunately, AI’s restructuring of costs does not favor attackers alone. It also opens a door for defenders that was previously out of reach. Soundness, once treated in industry as a pipe dream, has for the first time acquired an economic basis for deployment at scale in the real world.

Software engineering and systems security have always faced the same question: what gives us reason to accept a piece of code and trust it to remain safely in production? We used to sustain that fragile trust with developers’ mental models and manual code review. But as AI coding becomes ubiquitous, the marginal cost of generating code approaches zero, while the volume overwhelms human reviewers’ attention. With vast amounts of code arriving without a human understanding to stand behind it, informed spot checks no longer suffice. A word industry has spent years trying to forget—soundness—has to return to center stage. Against probabilistic code generation, only formal, deterministic methods can provide a sufficiently strong foundation for trust.

In traditional program analysis and verification, soundness—missing no bugs—and precision—keeping false alarms low—form a nearly intractable dilemma. Pursue soundness to its limit, and over-approximation often leaves the analysis drowning in false positives. Keep soundness while improving precision, or construct formal proofs outright, and the bill arrives in expert hours: understanding program semantics, recovering complex context, writing specifications and loop invariants by hand. The price of that labor has confined strong guarantees to a handful of domains where cost is no object, such as the flight-control systems of Apollo and Airbus.

AI is now reshaping that trade-off. A large model may be probabilistic, but finding a proof and checking correctness are entirely different jobs—and AI is extraordinarily good at taking over the drudgery of the former. It can infer contextual constraints, identify and prune false positives from oceans of static-analysis warnings, and even help construct formal proofs through repeated trial and error. Take Anthropic’s recent experiments with formal verification:⁶ while the specifics of their approach are debatable (and may hardly qualify as “verification” as usual), they nonetheless demonstrate the new possibilities AI brings to this classic field.

The defender’s utility function is being rewritten too. As expensive expert annotation and proof construction give way to cheap compute, heavyweight defensive techniques—from symbolic execution and abstract interpretation to formal verification—are crossing the break-even point. Methods that industry once left on the shelf because the returns did not justify the investment are, for the first time, becoming perfectly reasonable economic choices.

4. Security Research Should Study Security

For far too long, most of what the security community has studied has not been security itself, but technical proxies that have taken on lives of their own.

Technical progress changes more than what we can solve. It changes what is worth solving. When finding vulnerabilities was enormously expensive, higher fuzzing coverage, fewer static-analysis false positives, or a few more CVEs could naturally serve as the hard currency of security progress.⁷ But as AI rewrites the cost curves of discovery, exploit development, and formal defense at once, these isolated technical metrics are rapidly losing value. They are even beginning to distort our understanding of real risk.

PHP2Shell (CVE-2026-109618/109619), disclosed in October 2026, is a case in point. Hundreds of purported PoCs flooded GitHub after disclosure, but very few were legitimate exploits.⁸ Some advertised “one-click RCE” depended heavily on particular memory configurations, process layouts, and exact binary offsets. Researchers subsequently achieved RCE across several real deployments, but reliable exploitation across environments and at scale remained a substantial challenge.⁹¹⁰ When LLMs take unverified GitHub PoCs at face value and treat other AI-generated analyses as independent evidence, speculation can grow with every retelling into a self-reinforcing echo chamber. This was certainly a serious vulnerability. It was not the internet-wide universal exploit it was initially made out to be. When producing vulnerabilities and PoCs on paper becomes this cheap, blind faith in the old metrics—remember how much weight a working PoC used to carry—can create an enormous gap between real engineering constraints and laboratory toys.

But the deeper problem is this: even if future AI overcomes every such technical misjudgment and reconstructs the exact real-world exploitation conditions of every vulnerability without error, it still cannot answer “what should we do next?” on our behalf. Deciding what counts as worthwhile security progress, and which risks deserve priority, involves value judgments that no technical advance can dissolve.

Technology can establish what is. It can verify that a bug exists, or that an exploit chain has a 0.1% chance of working under some exacting heap layout. But technical facts alone can never tell us what ought to be. Suppose we understand a vulnerability’s technical boundaries completely: it is real, but extraordinarily difficult to exploit. Should we force an emergency shutdown and patch across every deployment, risking business disruption? With limited engineering resources, should we keep spending compute to find the 1,001st obscure memory error in an existing C/C++ codebase, or accept the enormous pain of moving an ecosystem toward architectural isolation and memory-safe rewrites? How much developer productivity and system performance are we willing to give up for the strong guarantees of soundness?

Faced with trade-offs that cannot be reduced to a common scale, the security community’s supposed “technical neutrality” is itself an unexamined value judgment. When researchers decide that a particular technical subproblem deserves to be solved, when the community chooses CVE counts or benchmark coverage as its measure of success, when an entire industry carries forward the research priorities of the last decade by default, we have already made strong judgments about which kinds of security matter and which costs can be ignored. In periods of “stagnation”, those assumptions were simply packaged as self-evident, objective common sense.

AI strips us of the privilege of continuing to hide behind “technical neutrality.” In the past, the technical difficulty of “how” gave us a respectable excuse to defer “why.” But no matter how much reverse engineering, fuzzing, or theorem proving AI eventually does for us, it can answer factual questions; it cannot relieve us of the responsibility to choose between costs and benefits. As the technical barriers fall, we have more reason than ever to face the value judgment we cannot escape: why is pursuing this particular technical advance better than spending those security resources somewhere else?

5. Rethinking Security Research

At this point, the position of this article should be clear. None of this is a declaration that bug detection is dead, nor an attempt to anoint the next technical centerpiece of security research. We absolutely need new techniques. AI has, if anything, opened up an extraordinary range of technical questions worth exploring. Which particular techniques deserve the most investment will depend on capabilities that are still evolving, threats that keep changing, and the needs of the world we live in.

But the security research community also needs to recognize a new obligation: it will no longer be enough to show that a technique improves an established metric. Justifying why the problem itself deserves to be solved must become part of the research. As the old consensus proxies lose their automatic authority, researchers owe us more than an ingenious design and impressive experimental results. We must explain and defend our premises. Why this research objective? How well do our benchmarks and metrics reflect the constraints of security in the real world? Above all, why should this technical advance translate into real security benefits worth the engineering and social resources required to achieve them?

The territory for technical exploration remains vast, but the question beneath it all has changed. The days of putting our heads down and chasing default metrics are over. Every future security innovation should be a deliberate statement of what we value. We must not only show the world what can be done; we must first convince ourselves that it is worth doing.

References