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.
At a glance
What this is: Veracode's 2026 software security report says security debt is now a mainstream condition in development, with rising volumes of unresolved and high-risk flaws.
Why it matters: For IAM and broader security teams, the lesson is that backlog management alone is not governance; control has to shift toward prioritisation, automation, and auditable proof.
By the numbers:
- Security debt now affects 82% of organisations.
- Critical security debt impacts 60% of organisations.
- High-risk vulnerabilities are up by 36% year over year.
Context
Security debt is the accumulation of known flaws that remain unresolved long after discovery. In DevSecOps, the problem is not just technical backlog, but a governance failure when speed, prioritisation, and remediation capacity drift apart.
The article's core concern is operational rather than theoretical: teams are producing software faster than they can verify, fix, and evidence control. That creates a control gap across engineering, application security, and board reporting, even when the primary risk is not identity-centric.
The identity angle is indirect but real because software delivery increasingly depends on privileged tooling, automated pipelines, and machine credentials. When control fails in the delivery chain, downstream access, secrets, and production exposure become harder to govern.
Key questions
Q: What breaks when security is added too late in a DevSecOps pipeline?
A: When security is added after development work is mostly complete, teams usually find secrets exposure, privilege issues, and configuration errors only at release time. That delay turns simple fixes into expensive production problems. The pipeline also accumulates trust debt because credentials, certificates, and dependencies remain active longer than intended.
Q: Why do application vulnerabilities still create major risk even when teams scan regularly?
A: Scanning alone does not reduce risk if teams cannot interpret findings, separate noise from exposure, and verify exploitability. Vulnerabilities often come from insecure code, outdated dependencies, and misconfigurations, then remain open because remediation is not tied to workflow. Effective AVM adds context, ownership, and enforcement so security work is measured by fixes, not by scan counts.
Q: How do security teams know whether AppSec findings are actually working?
A: Look at fix acceptance, false positive rates, time to remediate, and the volume of repeated findings. If engineers ignore alerts or remediation drags on, the programme is generating output without control. Effective AppSec changes behaviour, shortens exposure windows, and improves trust in the signal.
Q: What should organisations do when a web vulnerability cannot be fixed right away?
A: If a vulnerability cannot be remediated immediately, teams should look for compensating controls, reduced exposure, or formal risk acceptance based on business context. That means limiting access, adding monitoring, or changing configuration until a fix is possible. The right choice depends on the asset’s value, the exploit path, and the organisation’s tolerance for residual risk.
Technical breakdown
Why security debt compounds in fast delivery pipelines
Security debt appears when a known vulnerability stays open long enough to become part of normal operations. In modern delivery pipelines, code moves from commit to deployment faster than manual review and triage can keep up, so unresolved flaws accumulate even when teams believe they are moving responsibly. The result is not simply more findings. It is a widening gap between discovery and remediation, where the effective control is no longer detection but prioritisation and throughput management.
Practical implication: Treat backlog growth as a pipeline control problem, not a scanner problem.
How SAST and SCA change the remediation equation
Static Application Security Testing, or SAST, examines first-party code for insecure patterns before release, while Software Composition Analysis, or SCA, checks third-party dependencies for known weaknesses. Used early and continuously, they move security left into the development flow instead of waiting for late-stage gates. The article's point is that these tools only matter when they are paired with workflow integration, otherwise developers will route around them to meet delivery targets.
Practical implication: Embed SAST and SCA into the build path so findings appear where developers already work.
Why build gates matter more than after-the-fact reporting
A build gate stops release when a defined risk threshold is crossed. That matters because reporting alone does not reduce exposure if critical flaws still reach production. The deeper issue is governance: teams need a decision point that makes severity, exploitability, and application criticality operational, not aspirational. In practice, this is where measurable policy replaces subjective judgement, and where software risk becomes auditable rather than anecdotal.
Practical implication: Use release gates for critical flaws so policy is enforced before production exposure.
Threat narrative
Attacker objective: The attacker wants to turn known but unfixed software weaknesses into a practical path to compromise or disruption.
- Entry occurs through unresolved vulnerabilities that remain in production-facing code after discovery.
- Escalation follows when high-risk flaws persist long enough for attackers to weaponize them against exposed applications and services.
- Impact is broader operational and business risk, because critical flaws in live software increase the chance of compromise, disruption, and regulatory scrutiny.
Breaches seen in the wild
- ShinyHunters FBI breach claim 2026: ShinyHunters claims it used a PeopleSoft flaw to breach the FBI and pivot into AWS GovCloud; the FBI has confirmed only an investigation.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Security debt is really risk debt once flaws persist beyond discovery. The article uses a one-year threshold to define unresolved issues, which matters because age changes a vulnerability from an engineering task into a governance problem. Once a flaw is known and still open, the question is no longer whether it exists but why the organisation has accepted the exposure. The practitioner conclusion is that ageing backlog must be treated as a risk register, not a ticket queue.
The real control failure is not detection, but decision latency. Teams often know where the weaknesses are, but they lack a reliable mechanism to decide what gets fixed first and what can safely wait. That makes prioritisation the centre of the programme, especially when high-risk vulnerabilities are rising faster than remediation capacity. The practitioner conclusion is that severity alone is insufficient without application criticality and exploitability context.
Remediation throughput debt: this is the gap between how quickly code is produced and how quickly it can be secured, evidenced, and released. When development velocity outstrips manual review, organisations create a permanent control deficit that no retrospective audit can erase. The practitioner conclusion is to design security as a continuous operational system, not a periodic review function.
DevSecOps maturity now depends on provable control, not just preventive intent. The report's 'Prove' step reflects a wider market shift toward evidence, not assertions, because boards and regulators increasingly want demonstrable control performance. That is especially relevant where software delivery pipelines depend on privileged automation and machine credentials, since those identities can expand risk quickly if left outside governance. The practitioner conclusion is to make evidence production part of the control design.
The article validates a move from backlog management to exposure management. Security teams that keep measuring raw counts of unresolved flaws miss the more important question of which weaknesses can actually hurt the business. That change matters across application security, cloud pipelines, and identity-governed automation, because the same control model should answer what is exposed, who or what can reach it, and whether remediation is actually happening. The practitioner conclusion is to align application security metrics with operational risk outcomes.
What this signals
Remediation latency is the real risk signal: the age of unresolved flaws matters more than the raw count of findings when teams are trying to decide whether the control environment is improving. If critical issues sit open long enough to become normalised, the programme is managing noise rather than exposure.
The practical shift for software leaders is toward exposure-based governance. That means triaging by exploitability, application criticality, and exception age, then using those measures to drive backlog burn-down and board reporting.
Security teams should also expect more scrutiny of pipeline evidence, because preventive intent is no longer enough on its own. The question is whether the organisation can prove that critical issues are blocked, routed, or remediated before production release.
For practitioners
- Prioritise vulnerabilities by exploitability and application criticality Build triage rules that rank findings by business exposure, not by queue order. Focus first on public-facing and revenue-bearing applications, then separate exploitable issues from low-severity noise so the remediation backlog becomes a risk list rather than a generic defect list.
- Integrate SAST and SCA into the delivery pipeline Run static analysis for first-party code and dependency checks for third-party components early in development, then repeat them at build time so defects are found before deployment rather than after release.
- Enforce build gates for critical findings Stop releases when severity and exploitability thresholds are crossed, and require an explicit override path with ownership, rationale, and expiry so exceptions remain visible and time-bound.
- Automate remediation where the fix is deterministic Use fix suggestions or controlled auto-patching for recurring classes of issues so teams reduce time spent on repetitive low-value repair work and reserve engineers for structural flaws.
- Produce auditable evidence of control performance Track remediation age, gate outcomes, and exception expiry so security leaders can show whether risk is falling over time, not just whether scans are being run.
Key takeaways
- Security debt has moved from an engineering nuisance to a business risk because unresolved flaws persist long enough to become accepted exposure.
- The article's signal is less about finding vulnerabilities and more about whether teams can triage and remediate them before production release.
- The most effective response is to prioritise by exploitability and criticality, automate what can be automated, and make control performance auditable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-16 — Application Software Security | The article centres on securing software delivery and reducing unresolved flaws across the application lifecycle. |
| CIS-7 — Continuous Vulnerability Management | Security debt is framed as an accumulation of unresolved vulnerabilities that need prioritised remediation. | |
| Recommendation — Use CIS-16 to embed secure development checks and keep critical vulnerabilities from reaching production. Apply CIS-7 to prioritise, track, and reduce ageing vulnerability backlog before it becomes accepted risk. | ||
| NIST CSF 2.0 | PR.DS-10 — Integrity Verification | The report's scan, gate, and proof themes align with verifying that software changes remain trustworthy. |
| PR.IR-01 — Incident Response Plan is executed during incidents | The report emphasises evidence and control performance, which strengthens response readiness when flaws are found in production. | |
| Recommendation — Use PR.DS-10 to verify code integrity and block risky changes from flowing into release. Tie remediation playbooks to PR.IR-01 so critical defects trigger a repeatable response path. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | The article focuses on reducing application flaws through earlier coding and release controls. |
| Recommendation — Use V15 to enforce secure coding practices that reduce recurring defect patterns in software teams. | ||
Key terms
- Security Debt: Accumulated risk that builds when vulnerabilities, unsafe dependencies, and policy gaps are left unresolved across the software lifecycle. In AI-assisted development, security debt grows quickly because more code is produced, more decisions are made automatically, and remediation often lags behind delivery.
- Build Gate: A build gate is a pipeline control that decides whether a release can continue based on defined security conditions. In practice, it should be explicit, severity-based, and consistent across CI systems so teams do not disable it or treat it as noise. It is a policy checkpoint, not a scanner.
- Static Application Security Testing: Static Application Security Testing is a method for finding security flaws by examining code, binaries, or configuration without executing the application. It is strongest when used early in development, where teams can fix issues before deployment and prevent avoidable defects from reaching production.
- Software Composition Analysis: Software composition analysis is the inspection of dependencies and packages to identify known vulnerabilities in third-party or transitive code. It complements secret scanning by answering a different question: what exploitable software weaknesses are present in the container, regardless of whether credentials are embedded.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity control to broader security delivery and assurance workflows.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org