Why do major web application security incidents keep recurring even when organisations already test their applications?

Why This Matters for Security Teams

Recurring web application incidents are rarely a sign that teams are ignoring testing. More often, they reveal that testing is missing the conditions that make weaknesses exploitable in production: exposed secrets, stale access paths, delayed remediation, and incomplete retesting. The problem is not just detection, but whether discovery is connected to fix verification and whether high-risk issues are prioritised fast enough to matter.

That gap is especially visible in secret sprawl and application code risk. NHIMG research in The State of Secrets in AppSec reports that only 44% of developers follow secrets-management best practices, while the average time to remediate a leaked secret is 27 days. When remediation lags, testing becomes a snapshot, not a control.

Security teams also need to assume that attackers chain weaknesses across layers, including code, CI/CD, cloud configuration, and exposed credentials. In practice, many security teams encounter repeat incidents only after a leaked secret or exploitable flaw has already been reused across multiple systems, rather than through intentional control validation.

How It Works in Practice

Effective programs treat testing as one stage in an end-to-end control loop. That means discovering applications continuously, testing them in the right environments, validating findings against business criticality, and confirming that fixes actually removed the exposure. The point is not to produce more findings. The point is to reduce the window in which a known weakness can be used.

A practical workflow usually includes:

• continuous asset discovery so new applications, APIs, and repos are not missed;
• risk-based prioritisation so internet-facing flaws, auth bypasses, and leaked secrets rise first;
• fix verification to ensure a patch, config change, or secret rotation actually resolved the issue;
• retesting after deployment so regressions are caught before attackers do;
• tracking remediation age, not just test coverage, so lingering exposure is visible.

For secret-related incidents, this loop should include immediate rotation, dependency review, and validation that the old credential is no longer accepted. NHIMG’s 52 NHI Breaches Analysis and the JetBrains GitHub plugin token exposure case both show how quickly exposed credentials can turn into repeated compromise when rotation and revocation are not immediate.

Current guidance from OWASP Top 10 and NIST SP 800-53 suggests that verification and remediation should be built into the control, not treated as a separate cleanup task. These controls tend to break down when release velocity is high and ownership is fragmented, because findings age out faster than teams can coordinate fixes.

Common Variations and Edge Cases

Tighter testing often increases operational overhead, requiring organisations to balance deeper coverage against release speed and engineering capacity. That tradeoff becomes sharper in monolith-to-microservice migrations, heavily automated CI/CD pipelines, and environments with many short-lived secrets.

Some incidents recur even with strong testing because the test itself is misaligned with the real failure mode. For example, an application scan may catch a vulnerable library, but it will not prove that a rotated token was invalidated everywhere, or that a service account still has unnecessary standing privilege. In other cases, tests are performed too early in the lifecycle, before deployment drift, misconfigurations, or secret leakage occur.

Best practice is evolving toward continuous validation rather than periodic assurance. Industry research and guidance, including Anthropic’s report on AI-orchestrated cyber espionage, also reinforces that automated attacker workflows can accelerate exploitation once a weakness is known. This is why point-in-time testing alone is no longer enough in fast-moving environments with exposed APIs, third-party integrations, or AI-assisted attack paths.

Current guidance suggests that if remediation verification is absent, organisations should not count a test as closed. The more dynamic the application estate, the more likely recurring incidents reflect broken feedback loops rather than weak test effort.

Related resources from NHI Mgmt Group

• Why do employee data breaches keep happening even when organisations already run security awareness training?
• Why does application sprawl create security and compliance risk even when organisations already have an identity programme?
• How should security teams test for parser differentials in web applications?
• When should organisations add application security testing if they already use IaC scanners?