Notifications
Clear all
Topic starter
02/08/2026 12:12 pm
TL;DR: Half of organisations carry critical security debt and 80.3% of applications contain at least one flaw, according to Veracode. Security debt becomes a governance problem, not just a tooling problem, when teams cannot see, rank, and act on risk fast enough, reinforcing that DevSecOps fails when inventory, policy enforcement, and prioritised remediation are treated as separate workstreams.
NHIMG editorial — based on content published by Veracode: A Practical Guide to Implementing DevSecOps in Your Organization
By the numbers:
- 80.3% of applications contain at least one security flaw.
- Over half of applications have high or critical severity flaws, but only 8.4% are highly exploitable.
Questions worth separating out
Q: How should security teams implement DevSecOps without slowing delivery?
A: Embed controls directly into developer workflows and CI/CD gates so security feedback arrives while code is still being written or built.
Q: Why do application security programmes accumulate security debt?
A: Security debt grows when teams detect more flaws than they can prioritise and fix, especially when ownership is unclear or release pressure delays remediation.
Q: What breaks when pipeline identity is not scoped tightly enough?
A: When identity is too broad, one job can inherit access intended for another job on the same cluster.
Practitioner guidance
- Map every CI/CD identity and permission path Inventory build accounts, deploy tokens, scanning services, and approval roles, then document what each can read, change, or release.
- Embed policy-as-code into release gates Define severity thresholds, dependency rules, and approval conditions in the pipeline so enforcement happens before deployment rather than after code is shipped.
- Separate exploitability from severity in triage Use one queue for all findings and a second path for high-risk issues that are both severe and realistically exploitable, especially in third-party code.
What's in the full article
Veracode's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance for wiring SAST and SCA into developer IDEs and CI/CD stages
- Examples of policy-as-code decisions for different application criticality levels
- Reporting and analytics patterns for tracking flaw density, fix rates, and remediation times
- Practical ways to scale onboarding of new repositories and applications without losing control
👉 Read Veracode's practical guide to implementing DevSecOps in your organisation →
DevSecOps governance gap teams miss: visibility, policy, and debt?
Explore further
02/08/2026 1:15 pm
DevSecOps failure is often a governance failure before it is a tooling failure. The article's framework is useful because it treats security as a pipeline property, not a final gate. The real issue is whether inventories, policy, and remediation ownership exist early enough to influence delivery decisions. For IAM and NHI programmes, the same logic applies to CI/CD identities, build tokens, and automation roles that must be governed as first-class access paths.
A question worth separating out:
Q: Who is accountable when security debt causes a production issue?
A: Accountability should sit with the teams that own the application, the pipeline, and the remediation workflow, not with security alone. Governance works best when each high-risk finding has a named owner, a due date, and escalation rules. That structure turns security debt from an abstract metric into an operational responsibility.
👉 Read our full editorial: DevSecOps maturity depends on visibility, policy, and remediation
