TL;DR: Financial services security debt remains widespread, with 77% of organisations reporting unresolved application flaws and 30% of flaws still open two years after discovery, according to Veracode’s 2025 State of Software Security findings. The sector’s problem is not just defect discovery but remediation latency that compounds operational and regulatory exposure.
At a glance
What this is: Veracode’s financial services snapshot shows that flaw discovery is no longer the main bottleneck, because unresolved application risk is being held open for too long and security debt remains widespread.
Why it matters: For IAM and appsec teams, the operational lesson is that control strength depends on remediation speed, SDLC integration, and supply chain governance, not scan volume alone.
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.
Context
Financial services application security is not failing only at detection. It is failing at the point where discovered flaws should be removed, and that creates security debt: exposure that persists long enough to compound operational, compliance, and resilience risk. For IAM and appsec teams, the relevant question is not whether scanning exists, but whether the programme can turn findings into closure at the pace software is delivered.
The article frames this as a sector-wide governance problem rather than a single tooling gap. That matters because slow remediation affects customer-facing systems, shared components, and development workflows at the same time. In financial services, the intersection with identity is indirect but real: insecure applications expand the attack surface around authentication, authorisation, and sensitive-data access, so delayed fixes can undermine broader identity controls.
Key questions
Q: What breaks when security debt is not reduced in application security programmes?
A: Security debt turns isolated flaws into persistent exposure. When unresolved defects remain open for months or years, they compound remediation cost, widen attack windows, and increase the chance that a routine coding issue becomes an operational or regulatory problem. In financial services, that also weakens trust because business services keep running on known weaknesses.
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. Unresolved flaws therefore do more than increase technical risk. They can affect customer trust, resilience, and compliance at the same time, especially when the defect sits near authentication, privilege, or data handling logic.
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. ASPM is most useful when it connects findings to ownership, identity, dependency lineage, and response actions. Without those links, it becomes a dashboard that describes risk without changing it.
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.
Technical breakdown
Why security debt persists in financial services application portfolios
Security debt is the residue of discovered flaws that remain unresolved for extended periods, often beyond a year. In application security programmes, the problem is rarely lack of findings. It is the combination of developer delivery pressure, fragmented ownership, and remediation workflows that do not fit release cadence. In financial services, that becomes more acute because systems are complex, regulated, and heavily integrated with customer and identity workflows. The result is a backlog that keeps reopening the same risk surface instead of reducing it.
Practical implication: treat remediation throughput as a control objective, not a reporting metric.
Why open-source dependencies amplify application security debt
Open-source software speeds delivery, but it also imports transitive risk that is harder to track and slower to fix. When critical flaws sit inside shared libraries, the organisation is not only remediating its own code, it is waiting on dependency updates, compatibility testing, and release coordination. That is why open-source debt often outlasts custom-code debt. In practice, this creates a supply-chain governance problem inside application security, because the defect may enter through a package rather than a developer commit.
Practical implication: govern package intake and dependency exposure as part of application risk management.
How application security posture management changes the remediation model
Application Security Posture Management aggregates findings, prioritises them by context, and helps teams focus on exploitable exposure instead of raw volume. The architectural shift is important: the control moves from isolated scan results to decision support across applications, libraries, and pipelines. That does not eliminate remediation work, but it makes the work more targeted and measurable. For financial services, this is the difference between managing a backlog and managing risk reduction as an operating process.
Practical implication: use prioritisation and workflow integration to shorten the time from finding to fix.
Threat narrative
Attacker objective: The attacker objective is to exploit lingering application weaknesses in financial services systems before remediation closes them.
- Entry occurs when third-party or open-source components introduce flaws into financial applications during normal development and integration.
- Escalation happens when those flaws remain unresolved for months, allowing security debt to accumulate across the application portfolio.
- Impact is sustained exposure in production systems, with increased regulatory risk, remediation cost, and attack surface around sensitive workflows.
Breaches seen in the wild
- Zacks breach claim 2025: A hacker leaked 12 million Zacks accounts in 2025, claiming domain admin access in 2024; HIBP verified the data, Zacks has not confirmed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group 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.
Open-source dependency management is part of application security governance. When most critical security debt comes from open-source components, the programme boundary clearly extends beyond custom code. That means ownership, inventory, and intake controls matter as much as scanning. For IAM-adjacent teams, this also affects trust in application pathways that handle authentication, session handling, and sensitive-data access, where latent library flaws can weaken downstream identity controls.
Application Security Posture Management is becoming a coordination layer for risk reduction. The article’s benchmark data suggests that teams need a way to convert large volumes of findings into prioritised remediation work. That is especially true in financial services, where release pressure competes with control demands. The practical conclusion is that programmes should measure whether prioritisation is reducing exposed time, not merely improving visibility.
Financial services security debt exposes the limits of scan-first thinking. Finding a flaw is not equivalent to reducing risk if the flaw remains open through multiple release cycles. The article’s half-life data shows that maturity depends on workflow integration, developer engagement, and dependency governance. Practitioners should therefore evaluate whether appsec is embedded in delivery, or still operating as an external review function.
From our research library:
- 40 percent of financial and software companies have already deployed agentic AI systems, and deployments are expected to double by 2028.
What this signals
Security debt in financial services is a timing problem, not a visibility problem. The sector can know where flaws exist and still fail to reduce exposure if remediation lags behind release velocity. That is the governance gap practitioners should watch: the difference between seeing a weakness and retiring it before it compounds.
Application security programmes now need to measure exposed time, not just flaw counts. If unresolved issues persist across multiple development cycles, the organisation is managing backlog rather than risk. For IAM and appsec leaders, the practical signal of maturity is whether prioritisation, developer workflow integration, and dependency governance shorten the path from discovery to closure.
For practitioners
- Embed remediation SLAs into appsec governance Set target closure windows for discovered flaws and track them as operating metrics, not just team goals. Use age, severity, and internet exposure to decide which issues must move first.
- 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.
- Prioritise exploitable exposure over scan volume Use contextual triage to focus on flaws that affect sensitive workflows, externally reachable services, and identity-dependent transactions.
Key takeaways
- Financial services security debt shows that application risk can remain high even when the number of severe flaws is comparatively low.
- The sector’s main weakness is remediation latency, which lets open vulnerabilities compound across production systems and shared components.
- Programmes that reduce risk fastest are the ones that embed appsec into the SDLC, control open-source intake, and prioritise closure speed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Application flaws can weaken identity-dependent access paths in financial systems. |
| Recommendation — Map application remediation to PR.AA-05 where flaws affect authentication, authorisation, or sensitive transaction access. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The article is fundamentally about reducing application risk through better software security operations. |
| Recommendation — Use CIS-16 to embed application security checks and remediation into delivery workflows. | ||
| NIST SP 800-53 Rev 5 | SA-11 — Developer Testing and Evaluation | Continuous testing and remediation discipline are central to the article's appsec maturity argument. |
| Recommendation — Apply SA-11 to ensure flaws are tested, tracked, and corrected before release and during maintenance. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Application weaknesses can expose authentication and credential handling paths used by adversaries. |
| Recommendation — Map exposed application weaknesses to TA0006 when they affect credential handling or session protection. | ||
Key terms
- Security Debt: Accumulated risk that builds when vulnerabilities, unsafe dependencies, and policy gaps are left unresolved across the software lifecycle. In AI-assisted development, security debt grows quickly because more code is produced, more decisions are made automatically, and remediation often lags behind delivery.
- Remediation Half-Life: The time it takes for half of discovered vulnerabilities to be resolved. It is a better pressure test than a simple average because it shows how long the backlog keeps half of the population open, including the issues that linger far beyond normal SLA expectations.
- Identity Security Posture Management: Identity security posture management is the continuous assessment of identity configuration, privilege, and exposure across an environment. It focuses on drift, overprivilege, and control gaps so teams can see where IAM, PAM, and NHI governance are failing before those gaps become incidents.
- Open-Source Dependency Compromise: Open-source dependency compromise is the unauthorized alteration of a library, package, or upstream component that software relies on. It occurs when attackers inject malicious code, tamper with release artifacts, or hijack maintainer access, causing downstream applications to inherit the compromise through normal build, update, or deployment processes.
Deepen your knowledge
The NHI Foundation Level course covers NHI governance, identity lifecycle, and secrets management in a way that supports broader identity and application risk conversations. It is designed for practitioners who need to connect access control decisions to operational security outcomes.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org