Security debt is becoming a governance issue for CISOs
Application security backlogs keep expanding across large development portfolios. Veracode’s 2026 State of Software Security Report puts numbers behind a familiar operational pattern, fixes lag discovery, and older weaknesses stay open across release cycles.
2026 findings against the 2025 baseline (Source: Veracode)
The analysis spans 1.6 million unique applications that underwent static analysis, dynamic analysis, software composition analysis, and manual penetration testing through Veracode’s platform. The scope covers commercial software suppliers, outsourcers, and open source projects, giving a view across different delivery models and codebases.
Security debt is defined as known vulnerabilities left unresolved for more than a year. The measure describes accumulated exposure that persists across multiple development seasons, even when scanning coverage and detection improves. The definition also separates routine remediation work from backlog items that have already survived several planning cycles, including repeated deferrals during roadmap changes and release freezes.
Security debt becomes a baseline condition
Security debt showed up in 82% of organizations in 2026, up from 74% in 2025. That metric captures the share of organizations with at least one known issue aging past a year, and it points to a broad backlog problem across the industry.
Critical security debt also increased, meaning long lived flaws that carry both high severity and high exploitability. Veracode measured critical security debt at 60% of organizations in 2026, up from 50% in 2025, which signals that aging items often sit in the highest risk tier.
Security debt is a time problem as much as a volume problem. Older items tend to live in code that teams hesitate to change, such as legacy services, shared libraries, or apps tied to revenue workflows. That slows remediation, and it can make risk conversations feel repetitive for engineering leaders. Programs that track debt end up debating ownership, change windows, and acceptable exposure for systems with high business dependency. Governance often comes down to who owns remediation, what gets funded, and which teams can accept risk exceptions.
Chris Wysopal, Chief Security Evangelist at Veracode, told Help Net Security that reducing security debt must move beyond technical backlogs and into executive oversight. “Reducing security debt is not just a technical challenge; it’s a business imperative. Security debt must become a board-level KPI, with CISOs leading the charge to treat it like financial debt: measured, governed, and actively reduced. This requires tracking both total and critical debt, with quarterly reduction targets, and aligning these efforts with business objectives and key results.”
He added that sustained progress requires changes in investment and policy. “By shifting investment toward automation and AI-assisted fixes, prioritising the ‘crown jewel’ applications that matter most to the business, formalising risk acceptance, and enforcing policies like ‘fix high risk before release,’ organisations can maintain safe and resilient systems.”
Wysopal also pointed to measurable governance targets. “For example, over six months, an organisation could reduce critical security debt by 25%, cut the average age of high-risk vulnerabilities in half, and ensure high-risk vulnerabilities in crown-jewel applications remain less than 10%.”
High risk vulnerabilities rise inside a wide flaw landscape
Overall flaw prevalence across applications measured 78% in 2026. Findings remain common across the scanned population, and the metric aligns with the day to day reality that most portfolios carry a mix of legacy and newly introduced weaknesses.
The concentration of vulnerabilities rated as both highly severe and highly exploitable reached 11.3% in 2026, up from 8.3% in 2025. That shift reflects the share of flaws that sit in a category with higher operational risk, especially when combined with externally reachable services and widely deployed dependencies.
Prioritization becomes an operational discipline when remediation capacity stays constrained. Programs need a repeatable way to tie issues to business criticality, reachable attack paths, and runtime exposure, so teams can focus effort on the highest impact weaknesses in the systems that matter most.
Wysopal said organizations need to recalibrate how they rank and measure vulnerability reduction. “Success in reducing security debt is about focus. Direct teams to the small subset of vulnerabilities that are both highly exploitable and capable of causing catastrophic damage to the organisation if left unaddressed. By layering exploitability potential on top of the CVSS, organisations add critical business context and establish a ‘high-risk’ fast lane for vulnerabilities that demand immediate attention.”
He also called for changes in metrics and tooling to support that shift. “CISOs should shift metrics from counting total vulnerabilities to measuring reduction in exploitable risk. To sustain development velocity and make remediation seamless, integrate automated fixes directly into development workflows and leverage Application Security Posture Management tools to unify and prioritise findings. This approach ensures security becomes an enabler, not a bottleneck, for innovation.”
Remediation moves slowly, and supply chain debt persists
Fix speed across all scan types, measured as half life, landed at 243 days in 2026, down from 252 days in 2025. The improvement reduces exposure time on average, and it still leaves a long window for known issues to remain open across multiple release trains.
Third party critical debt measured 66% in 2026, down from 70% in 2025. The metric reflects where the most dangerous long lived issues reside, and it keeps pointing at dependency governance as a central control area for many AppSec and product security programs.
Supply chain remediation often involves more than applying a patch. A dependency update can trigger regression testing, compatibility work, and coordination across services that share the same package set. Controls in this area often revolve around visibility into direct and transitive dependencies, routine update cadence, and guardrails that reduce the entry of vulnerable components into build pipelines.
Ownership and inventory hygiene matter because teams need to know which services ship which packages before remediation can move quickly. Many CISOs also treat dependency controls as a way to reduce repeat alerts, stabilize release planning, and support compliance evidence when auditors ask how vulnerable components are tracked and updated.
Download: Blue Report 2025 uncovers how security controls perform in practice