Topic starter
02/08/2026 11:51 am
TL;DR: Security debt is piling up as flaw creation outruns remediation capacity, with 82% of organisations affected and a 36% relative increase in high-risk vulnerabilities, according to Veracode. AppSec programmes need to measure whether fixes are shrinking open high-risk debt, not just adding more findings.
Editorial analysis by NHI Mgmt Group, based on content published by Veracode: “Prioritize, Protect, Prove: A Roadmap for Application Security Transformation”.
By the numbers:
- 82% of organisations carry security debt, according to Veracode.
- The 2026 State of Software Security Report shows a 36% relative increase in high-risk vulnerabilities, according to Veracode.
Key questions
Q: Why does remediation capacity matter more than scanner coverage?
A: Scanner coverage only tells you what exists; remediation capacity determines whether known issues are actually reduced before attackers can use them.
Q: What are the signs that a software security programme is lagging behind maturity goals?
A: Common signs include high flaw prevalence, slow fix capacity, long fix times, and a growing backlog of security debt that stays open for more than a year.
Q: What breaks when teams treat every vulnerable package as equally urgent?
A: When every vulnerable package is treated as equally urgent, security teams create noise instead of clarity.
Practitioner guidance
- Prioritise by exploitability and asset criticality Rank vulnerabilities using real-world exploitability, external exposure, and crown-jewel application impact before assigning engineering work.
- Move routine fixes into developer workflows Embed remediation guidance in IDEs and CI/CD pipelines so repetitive flaws are corrected before merge or deployment.
- Block vulnerable dependencies upstream Use package manager firewalls and dependency policy checks to prevent known-bad components from entering the codebase.
Bottom line: Application security teams are dealing with a backlog problem as much as a vulnerability problem, because flaw creation is outrunning remediation capacity.
Glossary terms: Security Debt, Risk Prioritisation, Mean Time To Remediate, Flaw Density
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
02/08/2026 1:00 pm
Security debt is now a governance failure, not a tooling problem. When flaw creation outpaces remediation capacity, the issue is no longer whether scanners are finding enough issues. It is whether the organisation has a defensible decision model for which flaws matter first. That makes prioritisation an operating control, not a reporting feature. Practitioners should treat backlog selection as a risk decision with business consequences.
A few things that frame the scale:
- The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.
A question worth separating out:
Q: How do security teams know if app controls are actually reducing risk?
A: Look for lower failed-login tolerance, fewer successful automated logins, shorter time to revoke suspicious sessions, and fewer privileged requests that bypass normal workflow. Good controls change behaviour in telemetry, not just in policy documents. If incidents still move from initial access to data exposure quickly, the control set is not strong enough.
👉 Read our full editorial: Application security transformation needs risk-based prioritization