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.
At a glance
What this is: This is a DevSecOps governance article arguing that shifting security left reduces friction only when prevention, policy, and reporting are built into the delivery pipeline from code commit onward.
Why it matters: It matters because IAM, AppSec, and platform teams now have to govern software delivery as a continuous control surface, including third-party dependencies, AI-generated code, and policy enforcement before production.
By the numbers:
- 74% of organisations carry security debt, with half showing critical debt.
- Roughly 70% of applications contain flaws in third-party code.
Context
DevSecOps is the practice of embedding security into software delivery rather than treating it as a final gate. The security governance gap is that speed-centric development models still assume vulnerabilities can be reviewed and fixed late in the lifecycle, even though modern release cycles, shared code dependencies, and AI-assisted development create risk much earlier.
For identity and access governance, the important shift is that software delivery itself now carries security decision points. Build systems, source repositories, dependency intake, and release pipelines all create policy enforcement moments, which means application security, secrets handling, and access control need to be governed as part of the development flow, not after it.
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. DevSecOps only works when pipeline policy can block or route unsafe code before release, with clear ownership for exceptions and remediation. Without that enforcement point, teams get the speed benefits of automation but still accumulate security debt.
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. Each deferral adds unresolved risk to the backlog and makes later remediation more expensive. The more applications and third-party components a team manages, the faster that debt compounds across the portfolio.
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. In practice, scan volume can increase while confidence falls if the programme cannot prioritise exploitable findings, control release gates, and reduce risk before deployment.
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.
Technical breakdown
Why shift-left security changes the control point
Traditional DevOps optimises for speed by automating build and deployment, but it often leaves security as a downstream review step. DevSecOps moves testing, scanning, and policy checks into the pipeline so flaws are caught while code is still changing. That matters because vulnerability discovery is most useful when it happens before an issue spreads across branches, artifacts, and release trains. The mechanism is not just earlier scanning, but earlier governance over what can move forward. In practice, the control point shifts from production approval to commit-time enforcement, where remediation is cheaper and context is still fresh.
Practical implication: move AppSec controls into source and pipeline stages where insecure code can be blocked before release.
How security debt accumulates in modern SDLCs
Security debt is the backlog of unresolved flaws that builds when fixes are deferred to satisfy delivery pressure. In DevSecOps terms, every missed scan, waived policy, or untriaged dependency issue becomes future operational friction. The problem is amplified by third-party libraries and generated code because teams inherit risk they did not author directly. This creates a governance challenge, not just a tooling challenge, because priority decisions, exception handling, and risk acceptance all influence how much debt accumulates. Security debt becomes visible only when it starts slowing releases, increasing rework, or expanding exposure across many applications.
Practical implication: track debt as an operational liability and force clear ownership for every waived or deferred finding.
Why AI-generated code needs the same controls as human code
AI-assisted development increases code volume, but velocity alone does not improve security posture. AI-generated code still enters repositories, dependency graphs, and pipelines, which means it must be assessed against the same policy and scanning rules as hand-written code. The risk is not that the code was produced by a model, but that teams may assume speed gains justify lighter governance. That assumption fails when generated code introduces insecure patterns, weak dependency choices, or overlooked secrets. Security controls therefore need to inspect artefacts, not authorship, and treat all code as equally subject to enforcement.
Practical implication: apply SAST, SCA, and policy gates to AI-generated code without creating a separate trust tier.
Threat narrative
Attacker objective: The attacker objective is to reach production through weakly governed software paths and exploit unresolved application flaws at scale.
- Entry occurs when insecure code, third-party components, or AI-generated code enters the delivery pipeline before adequate security review.
- Escalation happens when unresolved vulnerabilities are promoted through builds and releases because governance is deferred until late-stage approval.
- Impact is broader exposure across production applications, with security debt increasing the chance that defects become exploitable in the field.
Breaches seen in the wild
- CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.
- EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.
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 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.
DevSecOps is now inseparable from software supply chain governance. The article’s emphasis on third-party code shows that modern application risk is inherited as much as it is written. That makes dependency visibility, policy enforcement, and release approval part of the same governance problem. Teams should align supply chain oversight with application security so inherited flaws are not treated as a separate concern.
AI-generated code turns speed into a governance test, not just a productivity gain. When developers use AI tools, the volume of output increases, but the need for security scrutiny does not diminish. The meaningful control is consistent policy application across all code sources. Practitioners should assume that any code path that can enter CI/CD can also carry unmanaged risk.
Pipeline policy enforcement: the decisive control is no longer the scanner itself, but the point at which policy can stop unsafe artefacts from advancing. That is where DevSecOps either becomes a governance model or remains a tooling layer. Security teams should focus on whether the pipeline actually blocks, routes, or waives risk with traceable accountability.
From our research library:
- 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.
- Read next: NHI Lifecycle Management Guide
What this signals
Security debt changes the unit of governance from the release to the pipeline. Once teams accept that unresolved findings accumulate across code, dependencies, and generated artefacts, the priority becomes enforcing policy at the point of entry rather than relying on end-of-cycle review.
AI-generated code makes consistent policy enforcement non-negotiable. If developers are producing more code with automation, the organisation cannot rely on manual review alone to contain risk. The control model has to assume every code source can introduce the same classes of defects and secret exposure.
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.
For practitioners
- 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.
- Enforce policy in CI/CD pipelines Set release policies by application criticality and block promotion when findings exceed the organisation's tolerance for unresolved vulnerabilities.
- Use unified reporting for remediation Track backlog, ownership, and remediation velocity across the portfolio to identify where security debt is growing fastest.
Key takeaways
- DevSecOps reduces risk only when security decisions happen inside the delivery pipeline rather than at the end of release.
- Third-party code and AI-generated code expand the governance burden because teams inherit risk from sources they do not fully author.
- Security debt is not a cosmetic backlog problem, it is a compounding control failure that can turn release velocity into exposure velocity.
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 SAMM set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-16 — Application Software Security | The article centers on embedding security into the software development lifecycle. |
| CIS-15 — Service Provider Management | Third-party code and inherited dependencies are a material part of the risk story. | |
| Recommendation — Apply CIS-16 to build security testing and governance into application development and release workflows. Use CIS-15 to track and govern third-party software and dependency risk across the delivery chain. | ||
| NIST CSF 2.0 | PR.DS-10 — Integrity Verification | CI/CD enforcement and artifact integrity are central to the article's control model. |
| PR.PS-03 — Configuration Management | Policy enforcement in pipelines depends on controlled software and build configuration. | |
| Recommendation — Use PR.DS-10 to verify software integrity before code advances through the pipeline. Apply PR.PS-03 to manage pipeline and release configuration changes with traceable approval. | ||
| OWASP SAMM | Governance — Governance | The article is fundamentally about embedding security into the SDLC as a management practice. |
| Recommendation — Use SAMM governance to measure whether security practices are embedded across the development lifecycle. | ||
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.
- Shift-left security: Shift-left security means moving security checks and remediation earlier in the software delivery lifecycle, especially into development and pull request workflows. The goal is to surface issues when they are cheapest to fix and closest to the code change that introduced them.
- 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.
- CI/CD Pipeline: The automated systems that build, test, and deploy software, often holding privileged credentials for source control, cloud access, and release automation. When these pipelines leak secrets, they can turn a software delivery function into a high-trust compromise path.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and identity lifecycle fundamentals. It is designed for practitioners who need a stronger governance lens across identity, access, and machine credentials.
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