Continuous penetration testing works when breadth and depth split

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Escape's blog post: Continuous penetration testing fails when one stream is expected to cover both breadth and deep application logic, and the program works only when those jobs are split.

Why it matters: For IAM and security teams, the lesson is that testing coverage is governed as much by workflow design, ownership and retest discipline as by tooling or headcount.

Context

Continuous penetration testing is a governance model for security validation, not just a testing cadence. It fails when teams expect one scarce expert workflow to cover every build, every regression and every complex authorisation path, because that collapses breadth and depth into a single queue that cannot keep pace with modern release velocity.

The identity angle is real here because the deep-testing stream is often where broken authorisation, session handling and multi-user access paths surface. In practice, this makes continuous testing relevant to IAM, application security and NHI governance wherever machine or human identities can traverse business logic that automation alone will not catch.

Key questions

Q: What breaks when penetration testing stays limited to narrow scopes?

A: Teams miss adjacent systems, federated access paths, and integration points that attackers can chain together after the first compromise. Narrow scope creates false confidence, especially in cloud and SaaS environments where identity relationships often matter more than the initial vulnerability. Continuous scope helps expose that hidden coupling.

Q: Why do broad automated checks need to be separated from deep manual testing?

A: Broad checks are good at finding the same classes of weakness across every release, such as exposed dependencies or leaked secrets. Deep testing is needed where application state, role combinations or business rules determine the risk. If one stream tries to do both, the programme loses scale or loses depth.

Q: What do security teams get wrong about runtime penetration testing?

A: They often focus on what the model can find and ignore what the model is allowed to do. Runtime offensive testing is an execution problem as much as a detection problem, so the real risk sits in permission scope, tool chaining, and whether human review happens before harmful action can proceed.

Q: How do you know if continuous testing is actually working?

A: You should see faster conversion from raw findings to confirmed risk, fewer disputed remediation priorities, and clearer evidence that validation is happening between assessment cycles. If the programme still relies on quarterly snapshots to tell you what is exploitable, it is not continuous in operational terms.

Technical breakdown

Why continuous testing needs separate breadth and depth streams

Continuous penetration testing only works when the program separates repeatable checks from expert reasoning. The breadth stream is built for scale, so it runs on every build or change and focuses on regression-shaped issues, exposed attack surface and obvious misconfigurations. The depth stream is different: it exists to model application state, chained permissions and business logic that only emerge when a tester can move through the system like a real user. Treating those as one activity creates either shallow coverage or an unmanageable backlog. The architecture problem is therefore not just tooling, but allocation of scarce expert attention to the cases where human judgement still matters.

Practical implication: Design separate pipelines for breadth and depth, or the program will drift into low-value repetition.

What the automated baseline actually covers

The baseline stream is the scalable part of the program. It should run on every build and repeatedly check the same things in the same way, including DAST, software composition analysis, secret scanning and reruns of previously validated findings. That makes it a control for breadth, traceability and regression prevention, not a substitute for expert testing. In IAM and NHI-heavy environments, the baseline often catches exposed credentials, weak dependency hygiene and release regressions before they become lasting exposure. Its value depends on being cheap enough and reliable enough to survive the pace of delivery, otherwise teams quietly skip it and lose the only part that scales.

Practical implication: Make the baseline blocking, automated and mandatory before merge or release.

Why deep testing still matters for authorisation and business logic

Deep testing is the stream that handles the parts a scanner cannot reason about. Business logic flaws often require multiple identities, specific role states or unusual request sequences, so they only appear when the tester understands how the application actually works. That is why manual expertise still matters, even as reasoning models and harnesses improve. The article’s point is not that automation replaces human testers, but that the engineering around the model can extend what a tester can cover in a session. For identity practitioners, this is where broken authorisation paths and multi-user abuse cases get exposed, especially in applications where privilege changes over time.

Practical implication: Reserve human-led depth testing for authorisation paths, multi-role workflows and other stateful abuse cases.

Threat narrative

Attacker objective: The objective is to exploit gaps between shallow coverage and deep application logic before the program detects and fixes them.

1. Entry begins when an attacker exploits an unpatched flaw or a release regression that the baseline stream failed to catch.
2. Credential or authorisation abuse follows when the application allows business-logic or multi-user paths that were never tested deeply enough.
3. Impact is realised when those paths let the attacker reach sensitive functionality, data or privileged actions before remediation catches up.

Breaches seen in the wild

• SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.
• Schneider Electric Jira breach 2024: Credentials linked to a Lumma infostealer infection gave Hellcat access to Schneider Electric's Jira; 40GB and 400,000 user rows claimed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Continuous penetration testing is a programme design problem before it is a testing problem. The article is right to frame headcount as the wrong lever, because the limiting factor is not how many people are available but how the work is divided. When breadth and depth live in one queue, the programme degenerates into a report factory. Practitioners should treat cadence, ownership and retesting as core control decisions, not administrative detail.

Breadth and depth are distinct governance functions, and organisations that collapse them lose both. Breadth belongs to repeatable automation that can run on every change, while depth belongs to expert judgement on the cases where authorisation, state or business logic create unique exposure. That split is especially important where human identities and NHIs interact inside applications, because access paths can look routine while hiding non-routine privilege abuse. Practitioners should map each control objective to the right stream.

Continuous testing without retest discipline does not reduce risk, it only increases visibility. A finding is not a control outcome until the original test goes green again, and that means fixes must be routed to the owning team with a deadline that matches severity. This is the part many programmes miss: they discover more but prove less. Practitioners should measure exposure window, not just issue count, to understand whether the programme is actually shrinking risk.

Program plumbing is the named control gap here: weak routing, weak ownership and weak closure discipline. The article shows that the programme fails when findings are not translated into accountable remediation, regardless of how many tests run. That is an operational governance failure, not a testing shortage. Practitioners should build defect routing and closure verification into the testing model from the start.

OWASP SAMM is the right lens because it separates scalable baseline testing from deep understanding and defect management. That structure mirrors how mature security programmes handle modern delivery pipelines. It also creates a clearer control language for teams that need to explain why one stream runs on every change while another is scoped and expert-led. Practitioners should align their internal operating model to those distinct assurance functions.

From our research library:

• 74% of all breaches included the human element, through error, privilege misuse, stolen credentials or social engineering, according to Verizon's 2023 Data Breach Investigations Report.

What this signals

Continuous penetration testing only becomes durable when the operating model changes, not when the tool count increases. Teams that keep one stream for everything will continue to under-cover release volume, because expert time will always be pulled back into repetitive work. The practical shift is to make breadth automated and reserve scarce testers for cases where business logic and authorisation paths need human judgement.

For identity security teams, the deep-testing stream is where application authorisation risk becomes visible. That matters wherever human users, service accounts or delegated access paths intersect inside the same application journey. The control lesson is to test the access path as part of the system, not as a static entitlement review after the fact.

For practitioners

• Split testing into two operating streams Run a scalable baseline on every build for repeatable checks, and keep a separate deep-testing stream for business logic, authorisation and multi-user abuse cases.
• Make the baseline blocking before release Require the automated stream to run before merge or deployment so no release bypasses DAST, dependency review, secret scanning and replay of prior findings.
• Assign one named triage owner Give one person clear responsibility for sorting findings, setting severity and pushing each issue to the team that owns the affected code.
• Route remediation to code owners Send findings directly to the engineering team that can fix the issue, with severity-based deadlines and no shared queue that hides accountability.
• Track retest pass rate and exposure window Measure whether the original finding reruns cleanly after the fix, then watch how long it takes to move from exploitable change to verified closure.

Key takeaways

• Continuous penetration testing fails when organisations ask one workflow to deliver both broad regression coverage and deep application reasoning.
• The article’s central lesson is that cadence, triage ownership and retesting are the controls that determine whether findings become fixes.
• Security teams should split baseline automation from expert-led depth testing, then measure closure and exposure window instead of report volume.

Key terms

• Continuous Penetration Testing as a Service: A delivery model that runs penetration testing as an ongoing process rather than a one-time engagement. It uses change detection, human validation, and remediation loops to keep security findings aligned with the current environment instead of a stale snapshot.
• Scalable Baseline: The repeatable testing layer that runs on every build or change and focuses on breadth, regression detection and low-cost checks. It is designed to catch the same categories of issues consistently, including exposed secrets, vulnerable dependencies and obvious application flaws.
• Deep Understanding: The expert-led testing layer that explores how an application behaves across roles, states and workflows. It is used where automation cannot infer intent or business logic, so the tester can reach authorisation failures and chained abuse conditions that scanners miss.
• Exposure Window: The period in which a credential, session, or privilege grant can be exploited before it is revoked or expires. Shorter windows help, but they do not solve the deeper question of whether the access remains justified for the full time it is active.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity and secrets management for teams that need to connect access control to broader identity risk. It gives practitioners a common governance language for machine and human identity programmes that need to scale safely.