Notifications
Clear all
Topic starter
02/08/2026 11:51 am
TL;DR: Software flaw creation is outpacing remediation capacity, with 82% of organisations carrying security debt and a 36% relative increase in high-risk vulnerabilities, according to Veracode’s 2026 State of Software Security Report. The practical shift is from reactive patching to risk-based prioritisation, automated remediation, and evidence-driven assurance.
NHIMG editorial — based on content published by Veracode: Prioritize, Protect, Prove: A Roadmap for Application Security Transformation
By the numbers:
- 82% of organizations carry security debt.
- the 2026 State of Software Security Report reveals a 36% relative increase in high-risk vulnerabilities
Questions worth separating out
Q: How should security teams prioritise vulnerabilities when remediation capacity is limited?
A: Prioritise by exposure, business criticality, and the identities attached to the affected asset.
Q: Why do security debt and fast release cycles create a larger risk than either one alone?
A: Fast delivery increases the rate at which flaws are introduced, while security debt slows the rate at which they are removed.
Q: What do AppSec teams get wrong about proving software security?
A: They often treat scan volume and ticket counts as evidence of progress.
Practitioner guidance
- Prioritise exploitable flaws first Build triage rules that combine severity, exploitability, and asset criticality so the highest-risk vulnerabilities are always remediated before lower-value backlog items.
- Automate repetitive remediation in developer workflows Push fix suggestions into IDEs and pipeline checks so developers can resolve common flaws before code reaches production.
- Block vulnerable dependencies at the entry point Add package manager controls that stop known-bad components from entering the codebase during CI/CD.
What's in the full article
Veracode's full article covers the operational detail this post intentionally leaves for the source:
- The full roadmap for prioritising vulnerabilities across real engineering backlogs and business-critical applications.
- Practical examples of AI-assisted remediation and how it fits into developer workflows.
- Details on how to measure assurance using time-to-remediate, flaw density, and high-risk debt reduction.
- The compliance and audit evidence model used to turn security activity into demonstrable posture.
👉 Read Veracode’s roadmap for application security transformation →
Security debt and remediation backlog: are your AppSec controls keeping up?
Explore further
02/08/2026 1:00 pm
Security debt is becoming a governance problem, not just an engineering backlog. When 82% of organisations report security debt, the issue is no longer whether teams can find flaws. The issue is whether the delivery model can absorb and retire risk at the same pace it creates it. That shifts AppSec from a tooling conversation to a control-capacity conversation, where the failure mode is accumulated exposure. Practitioners should treat backlog growth as a governance signal, not only an operational inconvenience.
A question worth separating out:
Q: What is the difference between finding vulnerabilities and reducing application risk?
A: Finding vulnerabilities tells you what exists, while reducing risk means removing the flaws that are most exploitable in the most important systems. The first is a detection activity, the second is a governance and remediation outcome. Mature teams use both, but they measure success by risk reduction rather than scan coverage.
👉 Read our full editorial: Application security transformation needs risk-based prioritization
