Software changes continuously, security validation doesn’t. This is creating such a gap that in regulated industries such as banking, release cycles often slow down not because engineering can’t move faster but because validation can’t keep up.
Overall, the industry agrees that snapshot testing isn’t enough; our survey of 200 CISOs and 200 engineering leaders found that 79% are concerned that issues go undetected between scheduled penetration tests, while 85% say findings are outdated at least sometimes. But no one (at least up until now) can agree on how continuous pentesting replaces it in practice.
In a recent Reddit thread, someone asked a seemingly straightforward question:
“Is anyone actually doing continuous pentesting instead of yearly audits?”
No one agreed on what “continuous pentesting” actually meant. In one thread alone, continuous pentesting flipped between meaning “glorified automated scanning”, to full manual tests done more regularly. Other definitions included long-winded regulatory engagements, or per-release testing focused on changes. There were also a number of disgruntled commenters who had clearly been burned by companies that had marketed a true continuous product, only to offer something completely different.
Before we get into this, let’s agree on the definition we’ll use for pentesting in this piece. Running vulnerability scans on every release isn’t pentesting. Real offensive testing requires reasoning about application behavior, exploring authenticated workflows, chaining attack paths, and validating exploitability through real attacks. Continuous pentesting only makes sense if the testing itself is meaningful.
The right instinct is that continuous pentesting should follow changes. When something changes, validate it. This is often called “delta testing”.
But the counter to this, as the thread above points out, is that not every change warrants testing, and it can be difficult to decide which changes matter, how to price accordingly, how to best utilize people to be available “on-demand” and how to ensure you’re not just testing noise.
Pentesters or red teams have creativity and judgment that pentesting tools may not, but they’re dealt a rough hand, which is getting rougher. The limiting factor isn’t their quality, it’s that they aren’t able to apply that thinking on a huge scale, and at the speed at which the surface area is changing.
They’re limited by hours, they have to rebuild context around the system every time they test it, and that’s without factoring in the planning, coordination and reporting required for each pentest.
This is the point; such a model built on human coordination alone can’t scale with the current speed of deployment. This is where continuous AI pentesting can help them.
But even with AI, there are nuances. Continuous doesn’t mean testing everything all of the time - that would be an enormous waste of resources. Just because you can, doesn’t mean you should. Continuous AI pentesting can determine whether a change meaningfully affects the attack surface or security posture, and only launch testing when it does.
One of the biggest dilemmas for experienced testers is deciding how much to focus on breadth versus depth. If they try to cover a large surface area quickly, they focus on common vulnerability classes and known attack patterns. They may catch a number of issues, but they’ll get less time to dig deeper into other interactions, where higher severity problems may be lurking. On the flipside, if they go deep instead, focusing on complex attack paths and chaining behaviors across the application, they inevitably cover less of the system overall.
Modern systems compound this issue because they’re larger, more interconnected and updated more frequently.
This is why deeper vulnerabilities such as logic flaws, broken access controls, or multi-step exploit chains are notoriously difficult to catch consistently. In our research, more than half of security and engineering leaders say deeper logic flaws and multi-step vulnerabilities are often missed in traditional pentesting engagements.
That’s not a criticism of pentesters’ skillset; it’s a reflection of the constraints they operate under.
But it also reinforces the same conclusion: continuous validation isn’t just about testing more often. It’s about getting the right coverage while doing so.
Continuous pentesting can take care of surface drift so experienced offensive teams can focus on the crown jewels.
A lot of tools focus on automated pentesting and generating attacks. The real challenge for continuous pentesting is to build a system capable of running offensive testing continuously against a changing application.
First and foremost, the architecture must enable sufficient system context. That means visibility into application architecture, APIs, source code, and infrastructure configuration, so that realistic attack paths can be explored. If a tool only sees exposed endpoints, it will miss attack paths that run through internal service communication.
Second, the system needs to understand when testing should run. That means detecting changes that actually affect the attack surface and triggering testing when they do. Without this, “continuous” testing either runs constantly and wastes resources, or falls back to scheduled scans that miss the changes introducing risk.
Third, modern applications involve thousands of interactions across roles, endpoints, and services. Those paths need to be explored in parallel rather than one at a time. A system that tests sequentially will never finish validating a modern application before the next deployment, so important components will go untested.
Fourth, findings must be validated through real exploitation to ensure results reflect vulnerabilities that are actually reachable and reproducible; teams already have to deal with too many false positives, they don’t need more.
Fifth, the system needs to close the loop. Continuous discovery only matters if vulnerabilities can be fixed and verified just as quickly. That means generating remediation guidance, validating fixes once applied, and retesting the system to ensure the issue is actually resolved.
And finally, the system must enforce strict execution boundaries, ensuring testing remains within scope and cannot impact unrelated systems (see our piece on how we ensure our AI pentesting agents don’t go out of scope).
Without any of the above points, continuous pentesting becomes little more than automated scanning.
The industry isn’t confused about whether pentesting needs to evolve. But it is a tad unclear what the new model is. The hesitation is understandable. Traditional pentesting still works, it just wasn’t built for software that changes constantly.
We know running scanners more frequently doesn’t solve the problem. Scheduling more pentests doesn’t either. Validation has to change as often as software does.
But it needs to test the right things when they change, maintain the depth expected from real offensive work, and ensure the attack surface doesn’t quietly drift between assessments.
When that happens, red teams can focus on the work that requires their expertise: complex attack paths, systemic weaknesses, and the crown jewels.
Continuous pentesting doesn’t replace offensive teams, it gives them the coverage they never had.
Want to see what continuous pentesting looks like in practice?
Aikido Infinite tests every meaningful change to your application, explores real attack paths, validates exploitability, and verifies fixes before code reaches production.
Start pentesting in 5 minutes or book a walkthrough to see how continuous pentesting actually works.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。