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.
Editorial analysis by NHI Mgmt Group, based on content published by Aikido: “Security testing is validating software that no longer exists”.
By the numbers:
- 76% of organisations deploy significant updates weekly or faster.
- 39% of organisations deploy daily.
- 21% validate security on every release.
Key questions
Q: What fails when security testing runs slower than software releases?
A: The control fails because it is validating an earlier version of the system than the one users now depend on.
Q: Why does release speed make security findings go stale so quickly?
A: Fast delivery shortens the time between change and exposure.
Q: What do security teams get wrong about periodic pentesting?
A: They often assume a pentest is a durable snapshot of exposure.
Practitioner guidance
- Link validation to meaningful software change Trigger security testing when code, authorization logic, APIs, dependencies, or agent workflows materially change, not only on a fixed schedule.
- Separate shallow checks from stateful verification Use lightweight checks for breadth, but require deeper validation against the running application for access controls, multi-step flows, and exploit confirmation.
- Measure report freshness against release velocity Track how often findings arrive after the build has changed, and treat stale findings as a governance metric rather than a reporting nuisance.
Bottom line: Security testing loses value when it validates a version of the application that has already been replaced by subsequent releases.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:01 pm
Validation lag is becoming a governance failure, not a tooling gap. When security evidence arrives after the release has changed, control decisions are based on an obsolete state of the system. That means the problem is not simply insufficient test volume, but an assurance model that is structurally late. For IAM and application security teams, stale validation is especially dangerous because access logic can shift quietly between releases, changing the real exposure without changing the last report. The practitioner conclusion is that security assurance must be version-aware, not calendar-aware.
A question worth separating out:
Q: How should teams govern application security when design changes happen quickly?
A: They should trigger policy checks and threat review when material changes affect APIs, data models, authentication flows, or external dependencies. Waiting for a scheduled review means the architecture has already moved on. The better approach is event-driven governance that reacts when the system changes, not after the release train has passed.
👉 Read our full editorial: Security testing fails when validation lags software change