Topic starter
02/08/2026 12:10 pm
TL;DR: DevSecOps embeds security testing, policy enforcement, and remediation into the CI/CD pipeline, while Veracode cites IBM data that the average cost of a data breach is $4.4 million and its own 2025 research showing 74% of organisations carry security debt. Security that arrives only at release time no longer matches the pace or complexity of modern software delivery.
Editorial analysis by NHI Mgmt Group, based on content published by Veracode: “What is the Difference Between DevOps and DevSecOps?”.
By the numbers:
- 74% of organisations carry security debt, with half showing critical debt.
- Roughly 70% of applications contain flaws in third-party code.
Key questions
Q: What is the biggest governance gap in DevSecOps programmes?
A: The biggest gap is assuming security can still be handled as a late review.
Q: Why does security debt increase when teams optimise for delivery speed?
A: Security debt grows when teams defer fixes, waive findings, or postpone dependency review to protect release dates.
Q: What do security teams get wrong about scanning code faster?
A: They often assume more scanning will close the gap created by faster development.
Practitioner guidance
- Implement commit-time security gates Run SAST, SCA, and secret checks as code is committed so vulnerabilities are blocked before they spread into release candidates.
- Govern exceptions and waivers Require named owners, expiry dates, and documented risk acceptance for every deferred finding so security debt does not become permanent.
- Inventory third-party and generated code Maintain a complete application inventory that includes open-source dependencies and AI-generated code so risk scoring reflects the real attack surface.
Bottom line: DevSecOps reduces risk only when security decisions happen inside the delivery pipeline rather than at the end of release.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:14 pm
Security debt is the real governance failure in DevSecOps programmes. The central issue is not whether teams scan code, but whether they can prevent unresolved findings from accumulating faster than they can resolve them. When exceptions, waivers, and late-stage reviews become routine, the delivery system starts to normalise risk. Practitioners should treat debt burn-down as a control objective, not a reporting metric.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
A question worth separating out:
Q: Should engineering teams treat AI-generated code differently from human-written code?
A: Yes. AI-generated code should pass the same security and quality standards, but it often needs stricter provenance, deeper review on sensitive paths, and stronger automated controls because volume and ambiguity increase the chance of missed defects. The right response is not special treatment, but stronger governance where risk is highest.
👉 Read our full editorial: DevSecOps shifts security left, but governance still matters