Notifications
Clear all
Topic starter
02/08/2026 11:53 am
TL;DR: 76% of organisations deploy significant updates weekly or faster, yet only 21% validate security on every release, leaving 85% seeing findings go stale before reports arrive and 51% missing deeper flaws, according to Aikido. The core issue is not test volume but a validation model that cannot keep pace with changing systems, making security decisions against an outdated state.
NHIMG editorial — based on content published by Aikido: Security testing is validating software that no longer exists
By the numbers:
- 76% of organizations deploy significant updates weekly or faster, and 39% deploy daily.
- Only 21% validate security on every release.
- 85% say security findings are outdated by the time reports arrive at least sometimes.
Questions worth separating out
Q: How should teams align security testing with continuous delivery?
A: Teams should tie deeper validation to meaningful change, such as new endpoints, authorization logic, or third-party integrations, rather than relying only on quarterly or annual testing.
Q: Why do periodic pentests miss deeper application flaws?
A: Periodic pentests often miss deeper flaws because logic bugs, broken access controls, and multi-step attack paths require time, context, and exploration against a running system.
Q: What do security teams get wrong about faster testing?
A: They often assume that increasing test frequency automatically closes the gap, when the real issue is whether the validation still matches the live system.
Practitioner guidance
- Map validation to meaningful change events Trigger deeper security validation when releases alter authorization logic, API exposure, dependency chains, or third-party integrations, not just on a fixed schedule.
- Shorten the handoff between test and remediation Set explicit ownership so findings from pentesting or AI-assisted validation move into fix, retest, and sign-off before the application state drifts again.
- Prioritise business logic and access-control paths Focus human-led testing on controls that govern privilege, workflow sequencing, and cross-system trust, because these are the areas most likely to create multi-step attack paths.
What's in the full article
Aikido's full blog guide covers the operational detail this post intentionally leaves for the source:
- How their validation approach maps findings to live application state instead of older release snapshots
- Examples of the kinds of issues their AI pentest workflow can confirm against a running application
- The specific testing workflow they recommend for teams shipping daily or continuously
- Why they argue that speed, not just coverage, is now the decisive constraint in security testing
👉 Read Aikido's analysis of why security testing lags modern software change →
Security testing lagging release speed: where is the governance gap?
Explore further
02/08/2026 1:01 pm
Security testing has become a time-governance problem, not just a quality problem. When validation runs on a slower cadence than delivery, the organisation is no longer evaluating the current system. It is evaluating a prior state and treating that output as decision-grade evidence. For IAM, PAM, and application teams, that weakens trust in controls that depend on current entitlements, routes, and enforcement points. The practical conclusion is that validation must be aligned to change velocity, not release ritual.
A question worth separating out:
Q: When should organisations move from quarterly testing to continuous validation?
A: When applications change faster than assessments can keep up. If microservices, APIs, serverless functions, or mobile releases are landing frequently, quarterly testing leaves long unvalidated windows. Continuous validation becomes necessary once the gap between releases and tests is large enough to make previous results unreliable.
👉 Read our full editorial: Security testing fails when validation lags software change
