How to build a continuous pentesting program

Introduction

An unpatched flaw is now the most common entry point for a breach, at 31%, ahead of stolen credentials at 13%, and the median time to fix one has crept up to 43 days (Verizon's 2026 DBIR). So an annual pentest is always a step behind, and you're two or three people being asked to test continuously with no budget to hire your way there. This is how to build a continuous penetration testing program without hiring more pentesters, by splitting the work so the part that scales runs itself.

TL;DR

• Headcount is the wrong lever. More security hiring, or more bought pentest days, feeds the one stream that can't scale, so coverage barely moves even when the budget clears.
• Two streams, not one. A scalable automated baseline and deep testing mature independently, and each needs its own cadence, scope and owner.
• The program is the plumbing. Cadence, triage ownership and remediation routing decide whether findings get fixed, and a program without them is a report generator.

More pentesters won't close a gap this size

When coverage slips, the first instinct is to ask for another head or a bigger testing budget, and it feels like the responsible thing to do. But a small security team can't out-hire an estate that grows with every deploy, and no single hire or bought-in pentest closes a gap that size. The math below shows why, and where the extra capacity has to come from.

Where an extra hire ends up

A team of two or three is hopelessly outnumbered by the estate it has to cover, and that gap grows with every release. Deep testing only scales with the people doing it, whether you hire them or buy them in, while your estate grows with every engineer and every new service they stand up. 

One more hire, or another block of pentest days, never catches a gap that size. Double the budget, and you might double the deep testing, but the estate keeps growing underneath you, so coverage per release barely moves, and the team still feels stretched thin.

That's true even once the budget clears, which makes this a design problem, not a spending one. And for plenty of teams, the money isn't there anyway. A third of the 16,029 professionals ISC2 surveyed in 2025 said they don't have the resources to properly staff their teams.

Do the math on where your expert hours go

Start with proof the deep work can be scaled at all. Across two real open-source apps, Escape's in-depth benchmark found that wrapping Claude Opus 4.8 in Cascade's harness turned up roughly four times as many real issues as the bare model, with zero false positives across the benchmark's validated findings. 

Now run the same question against your own expert testing. Take a senior tester's quarter, the sixty-odd days you staff or buy, and split it three ways.

• Re-checking findings from previous engagements
• Establishing coverage across the estate
• Genuinely novel testing

Put a percentage on the first two from your own last quarter. If they eat forty of the sixty days, that two-thirds is the capacity a baseline stream reclaims, and the number worth arguing about internally.

Annual penetration testing has the same problem, only sharper, because each engagement re-covers ground already walked in the last one, and it's paid for with your scarcest hours. Getting those hours back means changing how the work is divided, not just working faster.

Split the work into two streams

Teams usually run testing as one thing on a single schedule, and that's exactly why it won't scale; you can't grow one half without starving the other. The fix is to run it as two separate streams, one built for breadth across everything you ship and one built for depth on the things that matter, each moving at its own pace. OWASP Software Assurance Maturity Model (SAMM) already draws this line, so the rest of this section is what each stream is really for.

Stream one, the baseline that runs on every build

The first stream is your automated safety net. It runs on every build, giving you breadth across everything you ship, without anyone having to schedule it. SAMM calls this the Scalable Baseline, and it matures in three stages: from off-the-shelf tools to automation tuned to each app to automation built straight into how you ship.

In practice, it's a fixed set of checks wired into your pipeline:

• DAST on every build, the breadth engine that exercises the running application.
• Software composition analysis, flagging known-vulnerable dependencies.
• Secret scanning, catching leaked credentials before they ship.
• A re-run of every previously proven finding, so nothing quietly regresses back in.

You don't have to take a vendor's word for why this matters. NIST's secure software development framework says that using automated methods "lowers the effort and resources needed to detect vulnerabilities and improves traceability and repeatability".

Here's the simple test for whether it's mature enough, can a release reach production without the baseline running first? If it can, you have a gap. This stream should carry the repeatable, regression-shaped checks, and because it runs on every build, each one has to be cheap enough to survive that pace.

This is the stream that has to hold, and it's the one Escape runs for you, finding what's exploitable and testing every build. See it in action on your own attack surface.

Stream two, what a deep pentest is for

The second stream is the deep work, the part that only makes sense once you know the application and its business logic. That understanding is what you were always paying for in an in-depth engagement. SAMM calls this stream Deep Understanding, and it matures the same way, from hand-testing the riskiest components, to full manual penetration testing, to testing folded into how you build.

SAMM's own logic is simple enough; automation covers a lot of ground cheaply, but really understanding one application's business logic used to take a slow, manual expert.

That was true when a slow human was the only thing that could reach business logic, and that's the part that's changed. Reasoning models have got a lot better at the vulnerabilities that matter, and the benchmark above shows the real gain comes from the engineering around the model, not the model itself.

Escape's Cascade is that engineering. It logs in as several different users at once, so it can exploit broken authorization and business logic flaws that only exist because of how your app was built. And it runs at that depth continuously, rather than once a year, learning more about your application each time it tests.

Wire the program so findings actually get fixed

Two streams on a cadence will produce plenty of findings, but findings aren't fixes, and cranking out more of them than anyone can route just builds a bigger backlog. What turns a finding into a fix is the boring plumbing, who triages it, which team owns the code, and what has to happen before it's really done. That's the part teams skip, and it's what the next few moves are about.

Give each stream its own clock and scope

The two streams run on different clocks, and that's on purpose. The baseline fires on change, and the deep stream runs against a scope you pick, not a date on the calendar.

Here's a starting set of triggers you can tune to your own estate, with the baseline firing on change and the deep stream scoped, not scheduled.

The UK's National Cyber Security Centre frames penetration testing as "a method for gaining assurance in your organisation's vulnerability assessment and management processes, not as a primary method for identifying vulnerabilities".

Your baseline is that everyday process, and the deep engagement is what gives you confidence it's working. So size the deep testing you buy against what you genuinely need to assure, not against the date of your next audit.

Give every finding an owner and a deadline

A testing process that finds well but routes badly is just an expensive report generator. OWASP SAMM's Defect Management practice lays out how tracking matures, from simply recording findings, to consistent severities with an SLA on each, to those SLAs enforced through the tools you already use.

Escape shortcuts that whole path, tagging each finding with the team that owns the code and sending the fix straight to them, so it lands on an actual engineer instead of a shared queue nobody watches.

Put one person in charge of triage. Rotate that job and the backlog falls through the cracks between shifts, with nobody owning what came in last week. Send each finding straight to the team that owns the code, and give every severity a set response time and a destination up front, so nobody has to re-argue it case by case.

The loop only closes when the original test passes again, not when someone marks the ticket done. That retest keeps your coverage active between deep engagements. SAMM's metrics and feedback stream is where you prove the program is improving, and four numbers tell that story:

• Baseline coverage, the share of releases the automated stream ran against.
• Re-test pass rate, proven findings that re-run green and stay green.
• Time to remediate by severity, measured against the windows above.
• Exposure window: the gap between a change becoming exploitable and proof that it exists.

Once those numbers trend the right way, you've stopped running a calendar of tests and started running a system that keeps its own coverage current. That's what lets a team of two or three stay ahead of a thousand engineers, instead of losing a little more ground with every release.

Conclusion

The whole point is that none of this needs more pentesters, just the repeatable work handled automatically, so your experts spend their hours where only experts can. That's what Escape runs in one place, a baseline testing every build for breadth, Cascade going deep on the authorization and business-logic flaws a scanner can't reach, and every proven finding re-run as a DAST test on the next deploy. See it against your own estate, book a demo and we'll run both streams live.

FAQs

How do you build a continuous penetration testing program without hiring more pentesters?

Start by splitting testing into two streams, because hiring only adds to the one that can't scale. Raise an automated baseline that runs on every build to carry all the repeatable coverage, then point the deep stream at the authorization and business-logic paths that only exist because of how you built the application. Everything else in the program is there to make those two streams land, which means deciding when each runs, who owns a finding, and where it goes to get fixed.

Can continuous testing replace annual manual pentests?

It replaces the calendar as the thing that decides when you test, and the depth question has moved on. Business logic still needs deep testing, and a multi-agent harness that holds several identities at once is now where that depth comes from. OWASP SAMM's Deep Understanding stream describes exactly that, and in practice it means keeping a scoped expert engagement while automation carries everything that can be checked the same way twice.

How does a small security team cover a 1,000-engineer organization?

Not by matching headcount, since expert testing scales with people and the estate doesn't. Coverage comes instead from automation that runs on its own, which makes breadth something your pipeline does rather than something your team has to staff, and leaves the team the work automation can't do. That work involves scoping the deep stream, owning triage, and ensuring findings reach the engineers who own the code.

How often should each stream of the program run?

The baseline runs on change, not the calendar, and its floor is that no release reaches production without it. The deep stream answers to scope. Compliance sets a floor for it, not a target, and running both streams at the same cadence makes a program feel slow and shallow at once.

Who should own triage and remediation in a penetration testing program?

Put triage with one named person, because a rotating duty leaves nobody carrying the backlog between shifts. Remediation goes to the team that owns the affected code. Shared queues are where findings stall, and OWASP SAMM's Defect Management practice describes the way out, from recording findings, to severities with SLAs, to SLAs enforced through the tools you already use.

What should you automate and what should stay human?

Automate anything a machine can check the same way every time, which covers regression-shaped checks and breadth across the estate. Deep testing takes the work that depends on knowing the application, the authorization paths and business logic a scanner has no way to reason about. That's also how you size it, since whatever fails the first test is what the deep stream should be scoped to.

How do you know the program is working?

The clearest signal is that a finding's original test re-runs green and stays green, since nothing else keeps coverage alive between deep engagements. Beyond that, track the four numbers above, baseline coverage, re-test pass rate, time to remediate by severity, and the exposure window.

Sources

• Security Testing practice, Scalable Baseline and Deep Understanding streams - OWASP SAMM
• Defect Management practice, defect tracking and metrics streams - OWASP SAMM
• 2025 Cybersecurity Workforce Study - ISC2
• 2026 Data Breach Investigations Report - Verizon
• SP 800-218, Secure Software Development Framework (SSDF) Version 1.1 - NIST
• Penetration testing - National Cyber Security Centre