Notifications
Clear all
Topic starter
14/09/2026 10:09 am
TL;DR: Annual penetration testing is too slow for modern release cycles, and Escape argues that teams need two separate streams: an automated baseline for breadth and deep testing for business logic and authorization paths, with OWASP SAMM and NIST SSDF used as the operating frame. The real control problem is no longer test volume but program plumbing, because triage ownership, remediation routing, and retesting determine whether findings become fixes.
NHIMG editorial — based on content published by Escape: continuous penetration testing without hiring more pentesters
By the numbers:
- An unpatched flaw is now the most common entry point for a breach at 31%, ahead of stolen credentials at 13%.
- The median time to fix an unpatched flaw has crept up to 43 days.
Questions worth separating out
Q: How should security teams split automated and manual penetration testing?
A: Use automation for repeatable checks that can run on every build, then reserve human or agent-assisted depth for business logic, authorization chains, and multi-step abuse paths.
Q: Why do annual pentests fail to catch modern application risk?
A: Annual pentests assume the attack surface stays stable long enough for a point-in-time review to remain valid.
Q: How do you know if a penetration testing programme is working?
A: Look for repeated evidence that the same control failures are disappearing over time.
Practitioner guidance
- Separate baseline and deep test cadences Run an automated baseline on every build or pull request, and reserve deep testing for scoped releases, high-risk auth changes, and business logic paths that need reasoning rather than pattern matching.
- Gate production on baseline coverage Block release if the repeatable checks have not completed first, especially for internet-facing changes, new services, and any workflow that touches identity or authorisation.
- Route findings to code owners Assign each issue to the team that owns the affected code, set a severity-based deadline, and avoid shared queues that delay closure and blur accountability.
What's in the full article
Escape's full article covers the operational detail this post intentionally leaves for the source:
- The exact baseline and deep-test operating model used to split continuous pentesting across different cadences.
- The benchmark and harnessing details behind the claim that agent-assisted testing found more issues than the bare model.
- The sample routing and severity windows for getting findings from test output to code owners quickly.
- The practical comparison of how the program behaves when deep work is scoped to risk instead of scheduled on a calendar.
👉 Read Escape's full analysis of continuous penetration testing at scale →
Continuous penetration testing at scale: where the program breaks?
Explore further
14/09/2026 10:10 am
Continuous testing fails when programmes treat coverage and depth as the same problem. The article is right to separate baseline automation from expert testing, because breadth is a pipeline problem while depth is a reasoning problem. In identity-heavy applications, that distinction matters even more, since authorization and session abuse often sit behind apparently healthy surface checks. Practitioners should design two control planes, not one test calendar.
A question worth separating out:
Q: Who should prioritise continuous pentesting over periodic testing?
A: Organisations that deploy frequently, run complex cloud and application estates, or have attack surfaces that change with every release should prioritise continuous pentesting. It is most valuable when security cannot keep up through periodic reviews alone. The right signal is not volume of tests, but whether exploitable risk is being reduced as software changes.
👉 Read our full editorial: Continuous penetration testing works when breadth and depth split
