Offensive Security

Continuous penetration testing: what it means when the testing never stops

Alexandra Charikova

• 10 min read
Continuous penetration testing: what it means when the testing never stops

In late 2025, Anthropic disclosed the first documented cyberattack run largely by AI, a state-linked group that used Claude Code to run 80 to 90 percent of an espionage campaign on its own, at thousands of requests a second.

Offense now moves at machine speed while most defenses stay scheduled once a year, and closing that gap is what continuous penetration testing is supposed to do, even if it has become a phrase a dozen vendors claim, and almost none define with technical precision.

This article defines what continuous penetration testing really means, separates genuine continuous testing from ordinary vulnerability scanning, and lands on the one mechanism that closes the gap, turning a vulnerability you proved once into a test that re-runs on every build.

TL;DR

  • Stale on arrival. You ship hundreds of times a year but pentest once, so the report describes an application that no longer exists.
  • Testing that never stops. Continuous penetration testing keeps the application under active adversarial testing as you ship, so new and reintroduced flaws surface with the code, not at the next audit.
  • Prove once, re-test forever. A proven exploit becomes a regression test that re-runs on every build, which is exactly what Escape's AI Pentesting solution Cascade and Escape DAST do together.

What is continuous penetration testing?

Continuous penetration testing keeps an application under active adversarial testing between formal engagements, so new and reintroduced vulnerabilities surface as you ship code rather than at the next scheduled audit. 

Where a traditional pentest is a point-in-time snapshot, a continuous program runs alongside development and fires on change instead of on the calendar. The deep assessment still happens, but it stops expiring the moment the report is filed. 

Whether you need it at all comes down to one number most teams underestimate: the gap between how often they ship and how often they test.

You ship every day, but you test once a year

Chart your release cadence next to your testing cadence and the gap is hard to miss. One line moves every time an engineer merges a branch, while the other sits still for months at a stretch.

cadence-gap-continious-pentesting
Cadence gap in continuous penetration testing

Orders of magnitude apart

Elite engineering teams deploy on demand, with lead times for changes under a day, according to the Accelerate State of DevOps 2024 report from DORA and Google Cloud. Even one deploy per working day works out to roughly 260 releases a year. Teams shipping several times a day clear a thousand.

SANS Institute puts it plainly, noting that "pen tests are typically conducted once a year, leaving gaps in security posture." Set that against a release track measured in hundreds, and traditional penetration testing, run once a year, sits two to three orders of magnitude behind.

Compliance still expects one test a year

The strictest compliance requirements and industry standards most teams answer to still ask for one test a year. Requirement 11.4 of PCI DSS v4.0.1 calls for internal and external penetration testing at least once every 12 months and after any significant infrastructure or application change.

That significant-change trigger only works when changes are rare enough to schedule around, which stopped being true for most organizations a decade ago. When every sprint carries significant change, an annual floor plus an exception clause covers very little of your year.

The gap is where threat actors live

That untested span between engagements isn't dead time on a calendar. It's where threat actors do their work, and they've gotten dramatically faster at reaching it.

The pace has only gotten faster. In 2025, Google's Big Sleep AI agent caught a live SQLite zero-day (CVE-2025-6965) that was known only to threat actors and about to be exploited, the first time an AI foiled an in-the-wild exploitation effort before attackers pulled the trigger. The same autonomy is available to whoever is paying for it, and no annual testing calendar reserves a slot for the week a zero-day gets weaponized.

In the 2026 Data Breach Investigations Report, Verizon Business found that vulnerability exploitation now starts nearly a third of all breaches, 31 percent, passing stolen credentials as the top entry point for the first time in the report's 19-year history. 

Verizon also reports that attackers are using AI to accelerate exploitation of known vulnerabilities, compressing the window for defense from months to hours. A testing calendar measured in months is being asked to cover a window measured in hours.

What continuous penetration testing requires

Closing that gap takes more than running the same test on a faster calendar. A point-in-time engagement, however rigorous, still describes a single frozen frame of a system that never stops moving, so anything that deserves to be called continuous penetration testing has to clear four requirements.

  • A live model of your organization's attack surface.
  • Testing triggered by change, not by the calendar.
  • Persistence of depth, so findings you already proved stay under test.
  • Auditable coverage, so you know what was assessed and not only what was found.
What continuous testing must deliver
What continuous testing must deliver

Where continuous pen testing claims fall short

A live attack-surface model is the easy requirement, and the tools calling themselves continuous tend to have it. Persistence is where they go quiet. One camp runs scheduled rescans, essentially vulnerability scanning on a timer, and calls the result continuous, without ever explaining how the depth of a real finding carries from one run to the next. 

Another points autonomous agents at the target and re-explores everything from scratch on each run, which is compute-heavy, non-deterministic, and offers no guarantee that the flaw you proved yesterday even gets looked at today.

Hugging Face's July 2026 incident disclosure made the escalation concrete, an intrusion driven end to end by an autonomous agent that reached its internal network, with the company noting that "autonomous, AI-driven offensive tooling is no longer theoretical." The capability ceiling keeps climbing too, and Anthropic held back its Mythos model from a general release after it autonomously found and exploited vulnerabilities with no human help. Persistence has to hold up against offense that now operates at machine speed.

How continuous penetration testing works

Persistence is the requirement that makes everything else continuous, and it goes by an unglamorous name. Regression testing keeps the depth you already paid for running against every future build, so a proven finding can't quietly slip back into production.

The Continuous Coverage Loop

Regression testing is the part everyone skips

A proven vulnerability gets turned into an automated test that re-runs on every build. When a later release brings it back, or introduces new vulnerabilities of the same class on a neighboring endpoint, you hear about it the day it lands instead of at the next audit.

Here's what that looks like in practice. Suppose an assessment proves a broken object-level authorization flaw that lets user A pull up user B's order just by changing the ID in the request. That pattern is not hypothetical. Escape's own research recently disclosed CVE-2026-17059, a broken object-level authorization flaw in Keycloak that handed a restricted admin every user's name and email. Your team ships the fix. What keeps it fixed is a stored check that replays the original attack on every build:

# the access-control fix has to stay fixed, on every build
- request: GET /api/orders/{user_b_order_id}
  as: user_a
  expect: 403   # user A must never read user B's order. A 200 means the bug is back.

Read it the way an attacker would. It logs in as user A, requests an order that belongs to user B, and insists on a 403. The day a refactor, a bad merge, or a careless default flips that response back to a 200, the build fails and names the regression before it ever reaches production. Nobody re-discovers the bug, and nobody hand-writes the test, because the proof from the original assessment is the test.

Depth and breadth are different jobs that call for different tools. Expert-led penetration testing finds the hard flaws that take human expertise and reasoning about how your application actually works, and automated pentesting re-runs that conclusion on every build for as long as the code lives.

How Escape closes all four requirements

Cascade, Escape's multi-agent AI pentesting engine, brings the depth. DAST, its business-logic-aware engine, tests each build in its own right and turns every proven Cascade finding into per-build regression coverage, the two halves of Escape's offensive security platform. Deep assessment once, coverage forever.

That split maps onto the four requirements. Cascade opens with a live model of your attack surface rather than a blank page, because it shares a platform with Escape's attack surface management, and DAST is CI/CD-native, so testing fires on your builds, not on a calendar. That covers the first two: a live attack-surface model and change-triggered testing.

The depth Cascade reaches

Cascade runs the assessment holding several identities at once, each in an isolated session, which lets it ask what a single-identity run cannot, whether user A can read user B's data. That is how BOLA and business logic flaws surface.

It also chains multi-step attack paths no single request reveals, for example completing a checkout while skipping the payment-authorization call, or replaying a mid-workflow state token to reach an admin-only action. A second identity typically surfaces 30 to 50 percent more issues than a single-identity run (Escape's figure).

Getting authenticated is the precondition for all of it. Escape's DAST natively tests applications behind OAuth, MFA, and CAPTCHA, among other authentication presets documented in the auth docs. In the Applied Systems case study, Escape built the custom authentication during the proof of concept and cleared a CAPTCHA blocker in about half a day.

Findings you can act on, not triage

What comes back is proven, not guessed at. Because the testing is business-logic-aware, validating real auth flows and authorization boundaries instead of firing generic payloads, you get real findings, not a queue of maybes to triage.

Each finding ships with the request chain, the user scopes, a working exploit, and a framework-specific fix, the exact query filter or permission class to add rather than a generic "add an authorization check." 

Your security teams read evidence instead of chasing false positives; the fixes route into your existing remediation workflows, and Escape reports an 80 percent reduction in time-to-remediation versus manual and semi-manual processes.

Persistence and auditable coverage

The proof itself is a machine-readable artifact, the ordered request sequence, the sessions and user scopes it used, the payload, and the response that confirmed impact. DAST picks that up and carries it into every future build, with no assertion for anyone to hand-write. The finding you proved once keeps testing itself.

A discovery agent handles attack surface discovery before exploitation begins, mapping the full scope so your results show what was assessed and not only what was found, which lets an auditor sign off on coverage rather than a bare list of hits.

Conclusion

Continuous penetration testing comes down to one shift in what a finding is for. Traditional pentesting lets the depth expire with the PDF, while a continuous model runs the assessment once and keeps that coverage testing itself on every build, so the real question about any pentest report is how much of its depth will still be running six weeks from now.

With Escape, it sticks around, because Cascade proves each finding with a working exploit and DAST turns that proof into a regression test that fires on every release. Book a demo to watch it run against your own application.

FAQs

What is continuous penetration testing?

Continuous penetration testing describes an approach that keeps an application under active adversarial testing, running simulated attacks between formal engagements so new and reintroduced vulnerabilities are found as code changes rather than at the next scheduled audit. It's continuous security testing rather than a once-a-year event, and the practical mechanism is regression testing. A flaw proven once becomes an automated test that re-runs on every build, so the program keeps working to identify vulnerabilities as they reappear.

How is continuous pen testing different from annual penetration testing?

Annual penetration testing is a point-in-time snapshot. It describes your application as it was on test day and says nothing about the hundreds of releases you ship before the next engagement. Continuous pen testing is triggered by change instead of a calendar, and it keeps past findings under test automatically, so coverage tracks the code as it evolves rather than quickly becoming outdated.

How often should you run continuous penetration testing?

Continuous penetration testing has no fixed interval, because the point is to decouple testing from the calendar. It runs as an ongoing program, so every meaningful build or release re-runs the regression suite of previously proven findings, while deeper assessments run when your attack surface shifts. In practice, that means catching issues as they arise rather than once a year.

Is continuous penetration testing the same as PTaaS or DAST?

Continuous pentesting overlaps with PTaaS and DAST without being a synonym for either. PTaaS mostly solved the procurement problem, letting you book and receive a pentest through a platform, but you still get a scheduled window and a report at the end. Continuous pentesting adds the missing half, a deep assessment that proves findings and a DAST engine that combines automated testing with business logic checks to re-test those findings on every build.

Does continuous penetration testing replace manual penetration testers?

It reduces how often you need a full manual engagement, though it doesn't erase the need for human expertise on novel, high-stakes targets. Skilled penetration testers, red team operations, and purple teaming still find the creative attack patterns automation misses. The bigger shift is that AI-driven assessment can now prove each finding with a working exploit and hand that proof to an automated regression test, so expert-led depth persists between engagements instead of expiring with the report.

Is continuous penetration testing cost-effective?

For many organizations, it is more cost-effective than stacking up one-off engagements, because you pay for deep assessment once and the coverage keeps running through automated testing rather than repeat manual work, which also helps you remediate vulnerabilities faster. It lowers the odds of a breach a single annual test would miss, and the reputational damage that follows, which is usually where the real cost sits.

How does continuous penetration testing fit a security strategy?

Continuous penetration testing feeds your security strategy with a live signal instead of a snapshot that ages between audits. It gives security teams evidence they can push straight into risk management and vulnerability management, and because threats keep evolving, continuous testing is how you stay ahead of new vulnerabilities and raise your security maturity. It also stops a clean annual report from creating a false sense of security.

What does continuous penetration testing cover across your attack surface?

A strong program starts with attack surface discovery, mapping your internet-facing assets, APIs, cloud services, and IoT devices so no exposed asset slips through undiscovered. From there, it works through the attack paths a real attacker would take across your IT infrastructure, prioritizing the sensitive data and cybersecurity risks that matter most rather than firing generic checks at everything equally.

Sources