Topic starter
02/08/2026 11:57 am
TL;DR: Security debt reached 82% of organisations in 2026, while critical security debt climbed to 60% and nearly half of applications now carry unresolved flaws, according to Veracode's 2026 State of Software Security Report. The evidence points to a capacity and prioritisation problem, not a simple tooling gap, and that same logic applies when identity and access debt accumulates across application and NHI programmes.
Editorial analysis by NHI Mgmt Group, based on content published by Veracode: “The Security Debt Crisis: Why 82% of Organizations Are Struggling”.
By the numbers:
- Security debt reached 82% of organisations in 2026, according to Veracode's 2026 State of Software Security Report.
- Critical security debt rose to 60% of organisations in 2026, according to Veracode's 2026 State of Software Security Report.
- Nearly half, 49%, of all applications now carry security debt, according to Veracode's 2026 State of Software Security Report.
Key questions
Q: What breaks when security debt is left unresolved in software pipelines?
A: Unresolved security debt turns a vulnerability backlog into persistent business exposure.
Q: Why do static severity scores create poor prioritisation for modern application security teams?
A: Static severity scores create poor prioritisation because they ignore application context, environment, and actual execution paths.
Q: What are the signs that remediation capacity is falling behind discovery?
A: The clearest signals are a growing backlog, more deferred findings, and year-old vulnerabilities persisting in production applications.
Practitioner guidance
- Define exploitability-based triage rules Classify findings by exposure, business criticality, and attack path so teams fix the issues that can be reached and chained, not just the loudest alerts.
- Set age thresholds for unresolved flaws Escalate vulnerabilities that remain open beyond a defined period, especially when they affect internet-facing applications or shared dependencies.
- Gate high-risk merges in CI/CD Use fix-before-close policies for severe findings so new code cannot advance until the most dangerous issues are resolved or formally risk-accepted.
Bottom line: Security debt is a backlog problem only on the surface. At programme level, it is evidence that release speed, dependency complexity, and remediation capacity are out of balance.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:04 pm
Security debt is now a governance problem, not just a vulnerability backlog. The article shows that organisations are not struggling because they lack scans, but because the rate of discovery and the rate of code change exceed remediation throughput. That shifts the issue from engineering hygiene to security governance across application portfolios, release planning, and exception handling. The practical conclusion is that leaders must manage security debt as a measurable control failure, not as a temporary queue.
A question worth separating out:
Q: Should organisations use fix-before-close policies or manual exception handling for high-risk flaws?
A: Fix-before-close should be the default for severe or internet-facing issues because manual exception handling quickly becomes a normalised escape hatch. Exceptions still have a place, but only when risk ownership is explicit, time-bound, and backed by a documented business decision rather than convenience.
👉 Read our full editorial: Security debt is outpacing remediation in modern software development