TL;DR: Financial services security debt keeps unresolved application flaws open for too long, with 77% of organisations reporting lingering flaws and 30% still open two years later, according to Veracode. Remediation speed now determines how quickly application risk falls across production systems and shared components.
Editorial analysis by NHI Mgmt Group, based on content published by Veracode: “The State of Application Security in Financial Services: Managing Security Debt”.
By the numbers:
- 77% of financial services organisations report security debt in their application portfolio.
- The flaw half-life in financial services is 276 days.
- Two years after discovery, approximately 30% of flaws in financial applications remain unresolved.
Key questions
Q: Why do unresolved application flaws create extra risk in financial services?
A: Financial services organisations operate under high change velocity, regulatory scrutiny, and tightly coupled application estates.
Q: What do teams get wrong about application security posture management?
A: They often treat ASPM as another scanning layer instead of a governance model.
Q: What breaks when security debt is not reduced in application security programmes?
A: Security debt turns isolated flaws into persistent exposure.
Practitioner guidance
- Embed remediation SLAs into appsec governance Set target closure windows for discovered flaws and track them as operating metrics, not just team goals.
- Control open-source package intake Block or quarantine risky packages before they enter production code paths, and require approval for dependencies that carry unresolved high-severity flaws.
- Integrate appsec into developer workflows Route findings into the tools engineers already use so remediation happens inside the SDLC rather than in a separate queue that delays closure.
Bottom line: Financial services security debt shows that application risk can remain high even when the number of severe flaws is comparatively low.
Glossary terms: Security Debt, Remediation Half-Life, Identity Security Posture Management, Open-Source Dependency Compromise
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Security debt is now a governance failure, not just a remediation backlog. The article shows that financial services can have a relatively low share of high-severity flaws and still carry unacceptable risk if closure lags behind discovery. That shifts the control question from how many issues exist to how quickly the programme can retire them. For practitioners, the right benchmark is time-to-remediate, because unclosed exposure is what compounds.
A few things that frame the scale:
- 40 percent of financial and software companies have already deployed agentic AI systems, and deployments are expected to double by 2028.
A question worth separating out:
Q: How should teams govern open-source risk in application pipelines?
A: They should treat package intake as a control point, not a convenience decision. That means screening dependencies before they are introduced, tracking high-severity issues in shared libraries, and making approval contingent on the organisation’s tolerance for latent exposure. In practice, dependency governance belongs inside the SDLC, not beside it.
👉 Read our full editorial: Financial services security debt is slowing application risk reduction