The Storm before the Boom. A meta-analysis of the shift in Security Research

For years, the story of security research was a story of single bugs. A researcher found a flaw, wrote an exploit, took the stage, and the room clapped for the clever part. The unit of progress was the vulnerability, and the unit of prestige was the proof of concept.

That unit is changing. Look at the conference programs, the bounty leaderboards, and the advisories, and you'll see that researchers are no longer rewarded only for finding a bug. They're rewarded for showing a chain, a pattern, or a whole class of failure. The shift has been gradual enough that most of us have adapted without noticing, but gradual shifts are exactly the kind that end in a sudden break. This article is about the pressure building underneath, why I think we are living in the storm before the boom, and what researchers and defenders should do before the boom arrives.

I'm not suggesting the sky is falling. Security research is healthier, more professional, and more productive than it has ever been. The point is that the conditions that made it so are the same conditions that are about to change the game, and that several comforting signals we rely on, from record payouts to a quiet advisory feed, are measuring activity rather than safety. Let's begin by looking at where the field has been.

The Era of the Single Bug

The early conference circuit rewarded novelty at the level of the individual flaw. A new memory corruption technique, a clever parser bug, or an unexpected trust boundary was enough to fill a room. Disclosure was a negotiation, and sometimes a fight. Vendors were suspicious, researchers were frustrated, and the legal risk of poking at someone else's product was real.

Three things followed from this environment. First, research was artisanal. A small number of skilled people spent weeks or months on a single target, and the expertise lived in their heads. Second, the output was lumpy. A great bug might come once a year, and the ecosystem organized itself around these rare events. Third, disclosure was adversarial as the audience was other researchers. Talks were written for people who already understood the target, and the applause was peer approval.

This was a fine system for its time, but it carried a hidden assumption: that finding bugs was the hard part. Everything else, including disclosure, patching, and adoption, was treated as an afterthought. That assumption is the one now under strain.

The Professionalization Wave

Then the economics changed. Bug bounty platforms turned discovery into a marketplace. Making it the expected norm rather than the exception. Governments and large vendors started treating researchers as part of the supply chain instead of a nuisance. The numbers show how large the marketplace has become. HackerOne's ninth annual report put payouts on its platform at roughly 80+ million for the year ending June 2025, up 13% on the year before, with the top ten payouts $21.6 million of that. Individual researchers now regularly clear six figures a year, something that would have sounded absurd to the lone hobbyists who built the field.

The volume of disclosed flaws has grown in step. By the most widely cited count, about 48,000 CVEs were published in 2025, a record and roughly a 20% jump over 2024, bringing the all-time total past 300,000. Some of that growth reflects changes in who is allowed to issue CVE's within software quality, and different trackers disagree by a few thousand depending on the cutoff date. Even with those caveats, the direction is clear: the pipeline is filling faster every year.

This brought real benefits. Researchers could earn a living, vendors patched faster, and the legal fog lifted in many jurisdictions. But the professionalization wave also reshaped what researchers chose to look at. When payment is tied to scope and severity, effort flows toward the platform that ranks you by volume, you optimize for volume. A field that rewards what is measurable will drift toward what is measurable. Reproducible web bugs on large programs became the staple, while deep, strange, unmeasurable research on hardware, firmware, protocols, and obscure industrial systems became the expensive hobby of people with spare time or a sponsor.

From Bugs to Chains

At the same time, the best work on the conference stage was changing shape. The standout years rarely turn on one clever flaw. They show a chain: a small foothold, a trust assumption, a pivot, and a payoff that only makes sense when you see the whole thing.

This reflects how real attackers work, and it reflects how modern systems are built. A phone, a payment terminal, a game console, and a car are all assemblies of firmware, cloud services, update channels, third-party libraries, and radio interfaces. A weakness in any one piece is rarely catastrophic, but a weakness that connects two of them often is. Attackers are not looking for one dramatic hole. They are looking for the seam between two things that each seemed fine on their own.

Chains also change what we mean by severity. A bug that scores low on its own can be devastating in a chain. Systems built around the individual vulnerability struggle with this, and so do the incentives built on top of them. A researcher who reports each link separately may collect small rewards, while the defender who sees only a low-severity ticket may never understand what it enables. I am not suggesting that individual bugs no longer matter, because they do but the question is shifting from "is there a flaw here?" to "what can be built from the flaws we already have?" The Quiet Shift Underneath

Alongside the move to chains, a few slower currents have been reshaping the field, and current calm feels unstable.

The first is that the attack surface moved down the stack. As web and application layers mature, the attack surface has moved to the layers beneath them, such as firmware, boot loaders, secure enclaves, update mechanisms, and hardware debug interfaces. These layers are harder to patch and slower to fix, and they are often shared across many products, so one flaw in a common component can quietly affect dozens of brands. The same Verizon report noted that a large share of exploited flaws sat in VPNs and similar gear making up roughly a fifth of the total. The boundary of the network has become a pile of embedded software that few organizations can inspect.

The second is that memory safety became a policy topic (Ironic I know). Entire categories of bugs that sustained a generation of exploit research are being designed out of new code, and governments now publicly encourage memory safe languages and this is good news for defenders, but old code does not disappear. It persists in devices that stay deployed for ten or fifteen years, which means the old bug classes stay relevant long after the new code is clean.

The third is that regulation arrived. Product security is increasingly a legal obligation rather than a voluntary virtue. Under the EU's Cyber Resilience Act, manufacturers have had to report actively exploited vulnerabilities and severe incidents since 11 September 2026, with an early warning within 24 hours and a fuller notification within 72 hours, and a final report once a fix is available. Most of the Act's remaining obligations apply from 11 December 2027, and fines can reach €15 million or 2.5% of worldwide turnover. When manufacturers are required to handle vulnerabilities, report them, and support products for a set period, the demand for credible research rises sharply, forcing researchers to behave predictably.

The Boom... Automation Meets Discovery

Fuzzing and static analysis have been around for decades, so automated bug finding is trivial for systems that can read code, form hypotheses about it, test them, and iterate, at a cost and speed no individual researcher can match.

The early evidence arrived in pieces. In late 2024, Google's Project Zero and DeepMind reported that their Big Sleep agent had found a previously unknown, exploitable stack buffer underflow in SQLite, which the maintainers fixed the same day. In 2025, Google said the same agent found another SQLite flaw, CVE-2025-6965, that was known only to threat actors and at risk of being exploited.

Now think about what that does to the economics I described earlier. If the hard part and finding bugs becomes cheap, then the hard part moves. It moves to validation, to triage, to understanding impact, to building the chain, and to getting fixes deployed. Those are the human heavy steps that the field has historically under invested in.

The first symptoms of the shift are already visible, and they are not the glamorous ones. In January 2026, the curl project, one of the most widely deployed pieces of software on earth, ended its bug bounty program. Its maintainer cited a flood of low-quality, often AI-generated report submissions in sixteen hours, none of which identified a real vulnerability. The goal was to remove the financial incentive for low effort submissions, and it is worth saying clearly that the maintainer has also praised researchers who used AI well. The lesson is not that AI-assisted research is bad. It is that when generating a plausible report costs almost nothing, the burden falls on someone else.

The attacker's side of the clock is moving too. Reporting on Mandiant's M-Trends 2026 at negative seven days, meaning that on average exploitation begins before a fix is made public. Earlier Mandiant analysis put it at 32 days for 2021 and 2022 and about five days for 2023. I could only verify the latest figure through secondary coverage, so check the primary report before quoting it, but the trend line across all of these sources is the same: the window in which defenders can patch before exploitation is closing.

There is a reasonable chance that the next few years bring a large surge in discovered vulnerabilities, far more than vendors, maintainers, and defenders can currently absorb. That is the boom, and the reason I call the present moment the storm before it is that the pressure is building while the surface still looks calm. Bounty programs are paying out, conference programs are full, and advisories are published on schedule. Meanwhile, the capacity to find issues is about to outrun the capacity to fix them.

The Illusion of Defense

If the research side is changing this fast, you might expect the defensive side to be keeping pace, but it isn't and the reason is rarely a lack of skill. It is a lack of people who still have the energy to do the work.

Consider the layer of the ecosystem that most researchers barely notice until they need it: the national CERTs. Organizations like JPCERT/CC in Japan and SingCERT in Singapore sit between researchers, vendors, and the public. They receive reports, coordinate with vendors who may not respond to incidents. When a disclosure goes well, this layer is invisible, and that invisibility is part of the problem (at least for me... Long story). A working coordination layer looks like nothing happening.

Perfect example, last week at SINCON, I spoke with former coordinators from a national CERT about a vulnerability I had reported in a critical national ID system. Their response was chillingly resigned: the volume of false reports and the bureaucratic friction of routing issues to unresponsive vendors had burned them out. Their attitude had shifted from proactive defense to a fatalistic 'if it gets pwned, oh well, at least you reported it.' This horrified me. It revealed that the illusion of defense is built on the fragile energy of a few exhausted people

What I came away with is that many of the people holding this layer up are burned out. That should worry anyone who sees that the illusion of defense is built on something fragile. We assume that if a report is filed, someone will triage it, someone will chase the vendor, and someone will warn the public. That assumption is only as strong as the people doing those jobs.

Burnout in this work has a clear cause. The workload grows while headcount and budget stay roughly flat, because the work is cost center work with no revenue line to justify hiring. The hours are unpredictable, since incidents don't respect a schedule. The job also puts you in the middle: researchers who want fast action, vendors who want delay, and the public who want an answer. Now add the surge I described earlier. More discovered flaws, more AI-generated reports of uneven quality, and shorter reporting clocks all land first on the people whose job is them. The curl maintainer ended his bounty program for exactly this reason: the cost of reviewing a flood of plausible reports lands on a small team. A national CERT faces the same economics at a larger scale and with fewer ways to say no.

This is what I mean by an illusion. A dashboard can show healthy disclosure numbers, growing CVE counts, and an advisory feed that publishes on schedule. None of it tells you whether the person behind the feed has the capacity to handle ten times as many reports. Output is the easiest thing to measure, but it isn't what matters. Burnout is the lagging indicator that tells you the system has already been over capacity for a while. It also creates a quiet failure mode. Tired teams fall back on assumptions and familiar patterns, which is the same confirmation bias and alert fatigue we see in a SOC, now applied to the coordination of an entire country's response.

I am not suggesting these organizations are failing. Many of them do remarkable work, but researchers and vendors treat them as infrastructure, and infrastructure needs maintenance. If the field wants disclosure to survive the coming boom, it has to treat the people in the middle as a scarce resource and not as a free service.

Thinking at the Level of Goals

This brings me to the part of the shift that I think matters most, and the part that gets the least attention. As AI makes finding individual bugs cheap, the value moves up a level. The scarce skill is no longer locating the flaw. It is deciding which flaws matter, and that is a question of context and business logic

Consider how an experienced operator actually thinks. They do not start from the vuln, the objective: what would an attacker want from this organization, what would that cost them, and which path is cheapest? A flaw only becomes interesting when it lies on a path to a goal. That is a higher form of reasoning than bug finding, and it is also a higher form than what current AI systems are good at. AI is excellent at the tactical question of whether a specific code path is vulnerable. It is far weaker at keeping the overall context of goals and strategic questions of what is worth attacking, what a defender would actually miss, and what the real world consequence would be.

The practical tool for working at that level is distillation. A mature program takes the flood of raw data, whether scanner output, reports, logs, advisories, or a decade of findings, and reduces it into a small matrix of goals against assets and paths. Rows are the things an adversary wants: payment flows, code signing keys, or the ability to disrupt operations. Columns are the routes to them, such as credentials, third-party access, exposed edge devices, update channels, or physical access. Each cell records the cheapest known path, the controls in the way, and the

evidence that those controls work. Suddenly a pile of ten thousand findings becomes a map where the findings that matter are obvious. This is the same logic that made attacker-technique matrices so useful to defenders: they turned an overwhelming list of techniques into a map that humans can reason about.

A goal matrix does something else that raw AI output cannot. It makes the invisible visible, including the gaps. A cell with no evidence is a different thing from a cell marked safe, and that distinction is exactly what a healthy-looking dashboard hides. It also provides an alternate. Let machines fill the cells with candidate paths and exploit attempts at a scale no human team could manage, and let people decide which cells deserve attention, which goals are real, and which results are noise. That division of labor also protects the exhausted people in the middle, because a coordinator who receives one validated, goal linked finding does far less work than triaging unverified crashes.

For researchers, the same principle changes how to choose a topic and how to frame a curiosity. A bug placed in a matrix, with a clear statement of the attacker's goal, the path it opens, and the defensive evidence it invalidates, is a finding that a decision maker can act on. The best conference talks of the next few years will probably look less like "here is a clever crash" and more like "here is a goal, here is the shortest path, and here is what turns out not to be true."

What Researchers Should Do Now

I am not suggesting that researchers should panic or abandon the craft. The opposite is true: what remains hard is the work most worth doing. The first step is to move up from the bug to the system, and then from the system to the goal. Learn to describe impact in terms of what an attacker is trying to achieve and how a chain gets them there, since a finding that comes with a clear story of what an attacker gains is far more useful than a raw crash.

The second step is to invest in the unautomatable. Hardware, physical access, radio, protocols between components and the messy boundaries between components resist tooling because they require access, equipment, and intuition, and they're also where defenders have the least visibility. The third is to treat validation as a first class skill. In a world of abundant candidate bugs, the person who can quickly and reliably say "this is real, this is exploitable, and this is the fix" becomes the valuable person in the room.

Lastly kinda a hot take but anyone submitting AI assisted reports owes the recipient that validation, because the cost of an unverified report is paid by an overworked maintainer or coordinator. A clean, validated report is also an act of care for the person who has to read it. ^-^

Finally, publish for defenders, not just peers. The best talks will leave the audience with detection ideas, mitigations, and tools they can use on Monday morning, and with a way to tell whether their own dashboard means what they hope it means.

What Defenders and Vendors Should Do Now

For organizations on the receiving end, the preparation looks different. If your handling process works only at current volume, it's already fragile, so plan for triage, deduplication, and prioritization at several times today's load. With reporting clocks now measured in hours under the new European rules, a slow internal process is no longer just an inconvenience but a compliance risk.

Then make the secure path the easy path. The same principle that applies to password manager applies to patching: if shipping a fix is painful, fixes will lag, so invest in update mechanisms and automated testing before you need them. Build your own goal matrix, and test it. Write down what an adversary wants from you, trace the cheapest paths, and require evidence for every control you claim, so that a claim is the start of the conversation rather than the end.

Fund the maintainers, too. Much of the software supply chain depends on small teams as funding them is not charity but risk management. The curl episode is a warning about what happens when the people holding up the stack are asked to absorb an unbounded flood. Support your national CERT and your coordination partners with clear, validated reports, and don't treat them as an unlimited inbox. Lastly, bring in outside perspective. Independent testers challenge assumptions to counter the confirmation bias that creeps into any team that has lived with its own systems for too long.

Calm Is Not Safety

Ultimately, the shift in security research is not a story of decline or of triumph. It's a story of a field outgrowing its own assumptions. We moved from bugs to chains, from hobbyists to professionals, from the application to the foundations, and now from human-paced discovery to machinery, we built signals of safety, from bounty totals to a steady advisory feed, that are easier to read than the reality they stand in for, and we leaned on a coordination layer made of people who are running out of energy.

The calm we feel now is real, but it's not proof of stability. It only means the consequences haven't yet materialized. The researchers, vendors, and defenders who use this window to rethink their processes and to look after the people in the middle, and reason at the level of goals will be ready when the boom arrives. The rest will be reading advisories faster than they can act on them. The storm is not a reason to fear the future. It is a reason to prepare for it.

---

Published by Exploit Security in The Exploit Society. Jack Sessions on the storm before the boom: why the unit of security research is moving from the single bug to the chain, and why the calm in the advisory feed is not proof of safety.

What is The Exploit Society? The guest series on the Exploit Security blog.

"Writers do not work here. The topics are theirs."

Is the field in decline? No. He argues it is healthier and more professional than it has ever been, and that the same conditions are about to change the game. Discovery is becoming cheap. The hard part is moving to validation, triage, impact, and getting fixes deployed. What should researchers and defenders do before the boom? Move up from the bug to the goal. Invest in the work that resists automation: hardware, radio, protocols, the messy boundaries. Treat validation as a first-class skill. Build a goal matrix so a pile of findings becomes a map. And treat the people in the middle, the coordinators and the CERTs, as a scarce resource rather than a free service.

Who published this? Exploit Security, a CREST-approved offensive security practice in Sydney offering penetration testing services and offensive security consultancy. The author is Jack Sessions.

---