Security teams tolerated noisy scanners for twenty years. False positive rates that would get a tool thrown out of any other engineering discipline became routine in AppSec, and everyone made peace with it, because a human could always work the queue. Slowly. Painfully. But the queue got worked.

That peace is ending, and I hear it in every conversation with a security leader. Their scanners didn't get worse. The code got faster.

The number of vulnerabilities never mattered

False positive rate is easy to measure, so it became the number vendors compete on. Run a bake-off, count the bad findings, pick a winner.

Except nobody tolerated the rate because it was fine. They tolerated it because a human could still clear the queue. That was the only number that ever mattered: not how many findings a SAST scanner produced, but whether the team could get to the end of them. That worked at 100 PRs a week. Put the same scanner on 300 PRs and the same rate buries the team, while the number on the vendor's slide hasn't changed at all.

To be clear, finding vulnerabilities is good. The problem is what the scanner calls a vulnerability. A SQL injection pattern in a function nobody can reach is not a vulnerability, it's a bug. Software is full of bugs. Any codebase of real size has thousands of them nobody will ever fix, and nobody loses sleep over that. The scanner takes a few hundred of those bugs, labels them critical, and puts them in a queue your team is now accountable for.

Email security went through this already (to be fair, it’s going through this again now). Keyword spam filters flagged "free" and "win," caught plenty of real mail, and nobody cared while inboxes were small. Then volume exploded, the same error rate produced an unrecoverable pile of mistakes, and keyword matching died. Bayesian filtering replaced it. SAST ran the identical arc: untuned tools shipped false positive rates above 90 percent, teams hired humans to triage, and the arrangement held for one reason only. Code volume stayed inside what humans could process.

We have more code now.

Cursor says enterprise customers are pushing 25 percent more PRs and the PRs are twice as big. Microsoft says engineers with coding agents merge 24 percent more per day. I don't need the studies. I sit with product security leaders every week and the number they give me is their own: double, sometimes triple, in under a year, with the same three people on the AppSec team.

So teams are trying to solve it.

The first move is always headcount or another tool. I've watched it a dozen times and I've never seen it close the gap, because you get one more person and the engineering org gets Cursor.

The scanner they bought in 2021 is still running. Accuracy is improving with AI overlays, just not fast enough, so a lot of ProdSec teams default to building something homegrown that "cleans up" or "validates" scanner output. They are now paying twice. Once for the scanner, and again in tokens to make its results usable.

And the results are the same. The scanner still has no idea whether the thing it flagged can be reached. Cleaning the queue faster just gets you to the bottom of the same queue, and the real one you were worried about is still somewhere in it.

So what matters today? Attacks.

Once the queue is the constraint, what's in it matters more than how long it is. The only findings worth an engineer's time are the ones an attacker can actually use.

Knowing that takes context a scanner never has: how the system is designed, where the code runs, what data it touches, which components talk to each other, and whether there's a real path from entry point to payload. A scanner flags a line. It cannot tell you if the line is reachable.

That is what Prime is built to answer. Prime keeps shared context across architecture, code, and infrastructure and reasons to exploitability before anything hits the queue. Findings are attack paths, not flagged lines. Customers see 100 criticals become 3. The 3 get fixed. The other 97 were never going to be, no matter how many people were working the queue.

So what's next for product security leaders?

Stop running bake-offs on false positive rate. The number is real. It is also the wrong number. It tells you how clean the queue is, not whether your team will ever reach the bottom of it, and the bottom is where the problem lives.

Ask a different question. How many of these findings can an attacker actually use, and how does that number move when my engineers ship twice the code next year? If the answer goes up with volume, the tool is counting bugs and calling them vulnerabilities.

Finding them was never the problem. The scanner found every one. It also found the 3,000 bugs sitting on top of them, and your team is going to work that queue top to bottom until the day someone outside the company finds the real one first.

See how Prime uses persistent context to identify real exploit paths and reduce security noise at primesec.ai.

External sources worth linking

• Cursor for EnterpriseSource for the PR volume (+25%) and average PR size (+100%) statistics cited in the 'Code Volume and Change Frequency' section.cursor.com
• Microsoft Study Finds AI Coding Agents Lift Pull Requests by 24%Source for the Microsoft research stat on merged pull requests per engineer per day.techrepublic.com
• SAST False Positives: 91% Are Noise. Here's the FixSource for untuned-vs-tuned SAST false-positive rate ranges cited in the historical section.pixee.ai
• The History of Spam Email: Origins, Evolution, and ImpactSource for the early-2000s spam-as-share-of-email-traffic claim used in the historical parallel.spaceship.com

For most of AppSec's history, developer headcount was the only reliable number available, so it became the number the market priced against. More developers meant more code. More code meant more risk. Seat-based pricing and seat-based TAM models followed, and both held up for over a decade.

They don't anymore. And the TAM is considerably larger than the seat-based spreadsheets suggest.

The market was built on a correlation, not a cause

The old math was clean. As of 2021 there were roughly 28 million developers worldwide, about 60% of them at companies with more than 50 employees. Blend a per-seat price across the usual module set, SAST, SCA, secrets scanning, IaC, ASPM, and you land somewhere around $500 per developer per year. Multiply it out and the AppSec TAM comes to roughly $8.4 billion, projected to climb to around $14 billion by 2030 on the back of 3 to 5% annual headcount growth.

Not bad.

The model made sense because the correlation held. One developer produced roughly one developer's worth of code, so headcount was a fair stand-in for output. The seat was a unit that meant something. Every AppSec pricing page, and most of the TAM decks behind them, still run on that assumption, projecting the market forward by projecting hiring forward.

Five years later, professional developer headcount still grows in the low single digits. Code output left that curve. GitHub processed 986 million commits in 2025, a 25% jump in a single year after a decade of low-teens growth. Platform totals blend many things together, including a record year of new signups, so treat that number as directional.

The per-developer data is where the break shows up. Cursor's usage data shows mean lines added per developer per week climbing from 3.6K to 8.6K in about seventeen months. Lines added per pull request at the 75th percentile are up roughly 2.5x year over year. The growth rate is still accelerating.

Per seat pricing models stopped meaning anything.

Beyond volume, the seat itself stopped functioning as a stable unit. A marketing manager with the right tooling can ship more code in an afternoon than some backend engineers ship in a week. A team of ten, properly equipped, outproduces a team of hundreds running outdated practices. None of it shows up in a headcount projection, because headcount was never measuring output. It was measuring who had a badge and a laptop.

When a badge reliably produced a predictable amount of code, per-seat licensing made sense. Now a single seat can produce zero lines in a week or a thousand in an hour, generated by a swarm of agents running continuously against a codebase. A unit that can represent either reality at any given moment isn't a unit worth pricing against.

Once headcount stops tracking output, pricing products or sizing the market on it stops making sense. Code defines the attack surface, not the developer who happened to be logged in when it was written. Pricing and sizing product security against code produced is a straightforward correction.

The formula changed in five years:
2021: [seats] x [security modules]
2026: [code volume] x [risk]

Run the napkin math and the $14 billion 2030 projection looks conservative. A market growing in the low single digits and a market compounding past 25% a year part company fast. Within a few years they are no longer versions of the same forecast. They are different markets.

Not all code deserves the same scrutiny

The argument comes with an obvious caveat. Raw line counts aren't the whole answer, because all lines aren't created equal. A payment service and an internal dashboard do not deserve the same scan frequency, the same review depth, or the same scrutiny, even if they produce a comparable number of commits in a given week.

The real unit is risk-weighted code: what a change touches, who and what can reach it, how exploitable it is once it ships. Weight the volume by risk and the growth story holds. Risk-weighted volume grows slower than raw lines, since agents generate plenty of scaffolding and tests, but it still compounds an order of magnitude faster than headcount. The caveat narrows the number. It doesn't rescue the seat.

Risk weighting is also why validation matters more than finding count. A scanner that produces more alerts as code volume grows is describing the problem faster, at higher cost. Sizing and pricing against code volume holds up only if the code being counted is weighted by what it can do to the business.

Are we moving to consumption based AppSec?

I can't speak for the market. I can speak for Prime: we priced the product on consumption, because seats no longer count anything. Security context has to follow code and risk, from architecture through code to the running environment. A model priced on seats can't scale with a codebase that no longer scales with people.

If you're a buyer, run the test yourself. Chart your code volume against your headcount for the last eighteen months, then put that chart next to your security invoices. If the invoices track the flat line, you know which market your vendor is pricing. And stop negotiating what counts as an active developer. That fight exists because the unit is fake.

Consumption will cost some buyers more, and that's worth saying out loud. But the spend isn't new. The attack surface grew the moment the code shipped; a seat-based invoice just didn't register it. Risk-weighting keeps the meter honest: scaffolding shouldn't cost what a payment service costs. You pay for the risk you're carrying, which is the only number worth paying against.

Ready to see what it looks like to size and secure your codebase by what it actually produces, not by how many seats are logged in? Learn more at primesec.ai.