Notifications
Clear all
Topic starter
02/08/2026 11:59 am
TL;DR: Security debt affects 82% of organisations, while critical debt reaches 60% and high-risk vulnerabilities rise 36% year over year, according to Veracode’s 2026 State of Software Security report. The data shows that late scanning and manual remediation are no longer keeping pace with modern development, so prioritisation and evidence-based control become the decisive programme choices.
NHIMG editorial — based on content published by Veracode: 2026 State of Software Security, Risky Debt is Rising, But Your Strategy Starts Here
By the numbers:
- Security debt now affects 82% of organizations.
- Critical security debt impacts 60% of organizations.
- High-risk vulnerabilities are up by 36% year over year.
Questions worth separating out
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: When should organisations prioritise security debt over new feature delivery?
A: Organisations should prioritise security debt whenever unresolved flaws are both severe and highly exploitable, or when they sit in systems that support sensitive data, authentication, or privileged operations.
Q: How can DevSecOps prove that infrastructure as code is reducing risk?
A: They should compare exposure in code-managed environments with exposure outside IaC coverage, then track whether preventable misconfigurations decline after policy and quality gates are added.
Practitioner guidance
- Prioritise the highest-risk application debt first Rank vulnerabilities by exploitability, business criticality, and exposure duration, then assign remediation ownership to the teams that control the affected application or dependency.
- Embed SAST and SCA into the release path Run SAST on first-party code and SCA on third-party dependencies before merge and before build completion, then fail releases that contain critical findings above policy thresholds.
- Automate remediation where the fix is deterministic Use fix suggestions, patch automation, and standardised change patterns for recurring flaws so teams are not forced to manually close the same class of issue repeatedly.
What's in the full report
Veracode's full report covers the operational detail this post intentionally leaves for the source:
- The underlying breakdown of vulnerable code by severity and lifecycle stage, useful if you need to benchmark your own backlog.
- The report's prioritisation logic for deciding which flaws to fix first when remediation capacity is limited.
- The automation and workflow patterns behind scanning, gating, and remediation that this analysis summarises at a higher level.
- The evidence model for proving risk reduction to auditors, executives, and security leadership.
👉 Read Veracode's 2026 State of Software Security report →
Security debt in DevSecOps: what do teams need to change?
Explore further
02/08/2026 1:06 pm
Security debt is a governance failure once known flaws outlive their remediation window. The report frames debt as a compounding business risk, and that framing is correct. A vulnerability that remains open for a year is no longer an isolated engineering issue, because the organisation has already decided, implicitly or explicitly, to tolerate exposure. The practitioner conclusion is that unresolved findings need lifecycle ownership, not just scan visibility.
A question worth separating out:
Q: Who is accountable when critical vulnerability deadlines are missed?
A: Accountability usually spans security operations, infrastructure owners, and risk leadership because missed deadlines are often caused by governance gaps rather than one failed team. Frameworks such as the NIST Cybersecurity Framework and NIST SP 800-53 expect defined responsibility for asset management, response, and access control, so remediation ownership must be explicit.
👉 Read our full editorial: Security debt is rising across software teams in 2026
