Notifications
Clear all
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.
NHIMG editorial — based on content published by Veracode: What is the Difference Between DevOps and DevSecOps?
By the numbers:
- 74% of organizations carry security debt, with half showing critical debt.
- 70% of applications contain flaws in third-party code, according to Veracode's 2025 State of Software Security report.
- Only 44% of organizations are currently using a dedicated secrets management system.
Questions worth separating out
Q: How should security teams implement SecDevOps without slowing delivery?
A: Start with advisory controls, not blocking gates.
Q: Why does DevOps create more risk when security is added too late?
A: Because teams optimise for delivery first, then discover flaws after code is already built, tested, and waiting to ship.
Q: What do teams get wrong about security debt in software delivery?
A: They often treat it as a backlog problem instead of a governance signal.
Practitioner guidance
- Implement security gates inside CI/CD Place SAST, DAST, and SCA checks at commit and build stages so insecure artefacts never advance because of release pressure.
- Inventory code dependencies and pipeline identities Map open-source packages, container images, service accounts, API keys, and deployment credentials across every application so security teams can see which identities and dependencies create the highest exposure.
- Track security debt as a board-level metric Report unresolved high-severity findings, exception volume, and mean time to remediation as delivery-risk indicators, not just developer backlog items.
What's in the full article
Veracode's full article covers the operational detail this post intentionally leaves for the source:
- The step-by-step six-stage DevSecOps adoption model for integrating scanning, policy, and reporting into the SDLC.
- The specific mix of SAST, DAST, and SCA controls the article recommends for pipeline enforcement.
- The article's discussion of security debt, third-party code risk, and how to prioritise findings inside an engineering workflow.
- The reporting and analytics approach Veracode describes for tracking remediation progress and compliance over time.
👉 Read Veracode's explanation of DevOps and DevSecOps →
DevSecOps and security debt: what practitioners need to change?
Explore further
02/08/2026 1:14 pm
DevSecOps is really a governance model for speed under constraint. The central change is not technical tooling alone, but who owns security decisions and when they are enforced. When release velocity is high, a late security gate becomes a negotiation rather than a control. Practitioners should treat DevSecOps as a control architecture, not a culture slogan.
A question worth separating out:
Q: How should organisations govern identity and secrets in DevSecOps pipelines?
A: Treat pipeline credentials as first-class production identities. Scope them narrowly, rotate them regularly, monitor their use, and remove standing access where possible. If build and deployment credentials are left broad or persistent, the software pipeline becomes a privileged access path rather than a secure delivery mechanism.
👉 Read our full editorial: DevSecOps shifts security left, but governance still matters
