AI-powered application security is changing DevSecOps economics

At a glance

What this is: Veracode argues that AI-powered application security is becoming necessary because AI-assisted coding is outpacing fragmented DevSecOps controls and allowing vulnerabilities to accumulate faster than teams can remove them.

Why it matters: For IAM and security practitioners, the key issue is governance velocity: security testing, remediation, and policy enforcement have to keep pace with AI-influenced delivery without creating new bottlenecks.

By the numbers:

• 76% of developers currently use or plan to use AI tools to write code.
• AI-generated code failed 45% of security tests in Veracode's recent research.
• 74% of organisations still carry critical flaws that persist for months or years, according to the 2025 State of Software Security Report cited by Veracode.
• The article says organisations using AI-assisted remediation see 92% faster mean time to remediation.

Context

AI-powered application security is about shifting security work from isolated point tools to a coordinated operating model that can keep up with modern software delivery. The article's core argument is that development speed is no longer the main problem; the governance gap is between fast code production, especially with AI assistance, and slow, fragmented security response.

For IAM-adjacent teams, the important parallel is lifecycle control. Just as identity governance fails when access decisions are made too late or in too many disconnected systems, application security fails when findings, fixes, and policy decisions are spread across tools that do not converge into one control loop.

The article also reflects a broader DevSecOps reality: when AI is in the coding workflow, security has to move earlier, stay contextual, and produce usable remediation output. That is typical of modern enterprise environments, not an edge case.

Key questions

Q: Why do fragmented security tools create DevSecOps friction?

A: Fragmented tools create duplicate alerts, inconsistent severity scoring, and disconnected ownership, which forces engineers to spend time interpreting findings instead of fixing them. The result is alert fatigue and weaker adoption. Consolidation matters because workflow quality is part of the control, not just the scanner coverage.

Q: Why does AI-assisted coding increase security debt if controls stay manual?

A: Because code volume rises faster than review, testing, and remediation capacity. Manual controls cannot evaluate enough changes quickly enough, so vulnerabilities accumulate even when teams are working hard. The result is a growing backlog of unresolved flaws that becomes expensive to clear later.

Q: What happens when remediation guidance is not built into developer workflows?

A: When remediation guidance is not built into developer workflows, fixes are slower, less consistent, and more likely to stall in the backlog. Developers have to interpret findings manually, which adds friction and increases the chance that issues are deprioritized. Embedding clear fix instructions where work happens makes resolution more practical and reduces security debt over time.

Q: When should organisations prioritise AI-powered application security over adding more point tools?

A: When their current stack creates duplicated findings, slow triage, and inconsistent policy decisions across pipelines. More tools rarely fix a coordination problem. Organisations should prioritise the control layer that connects detection, prioritisation, and remediation before expanding tool count further.

Technical breakdown

AI-assisted code generation changes the vulnerability intake rate

When developers use AI tools to write code, the volume of code increases faster than manual review and test processes can absorb. That does not mean AI-generated code is inherently insecure, but it does mean the rate of candidate vulnerabilities rises unless testing, policy checks, and remediation guidance are automated. The article's 45% failure figure points to a mismatch between generation speed and control capacity. In DevSecOps terms, the problem is not only detection coverage but the time window between code creation and safe release.

Practical implication: security controls have to shift left into the coding loop and produce feedback at developer speed.

Fragmented application security tools create governance drag

The article describes the common enterprise pattern of 10 to 30 point solutions, each producing separate findings. In practice, that fragments ownership, inflates false positives, and forces teams to spend time correlating data instead of remediating risk. This is similar to identity governance problems where too many disconnected systems obscure who can do what, where, and under which policy. The governance issue here is not lack of security data but lack of a single decision layer that turns findings into prioritized action.

Practical implication: teams need a unified control plane for application security findings, not another isolated scanner.

AI-assisted remediation changes the economics of fix ownership

The article's remediation model matters because it moves security from diagnosis to guided action. When a tool can suggest concrete fixes inside an IDE, the control no longer depends only on security specialists interpreting findings after the fact. That reduces the research burden and shortens the path from alert to code change. The deeper architectural point is that the security workflow becomes stateful across design, build, test, and release, rather than being a one-time gate at the end of the pipeline.

Practical implication: remediation guidance should be embedded where code is written, reviewed, and merged.

Threat narrative

Attacker objective: The objective is to exploit unresolved application flaws that were introduced or left unaddressed during accelerated development, leading to compromise, data exposure, or service abuse.

1. Entry occurs through AI-assisted development workflows that generate or modify code faster than conventional review processes can evaluate it.
2. Credentialed or business-logic flaws survive into the pipeline because fragmented testing and high false-positive rates slow remediation.
3. Attackers or defect chains can then exploit the surviving weaknesses in production, where runtime visibility and monitoring must catch what static controls missed.

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.

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

AI-assisted development has turned application security into a throughput problem. The article is right to frame the issue as economics, not just tooling. When code volume rises faster than review and remediation capacity, security debt accumulates regardless of how many scanners are deployed. Practitioners should treat this as a governance scaling issue, not a point-product selection problem.

Fragmented findings create a decision deficit, not just analyst fatigue. Ten to 30 tools can produce more evidence, but they do not produce better control unless findings are normalized into a single remediation path. The same pattern appears in identity programmes when access data lives in silos and no one can confidently action it. Security leaders should collapse duplicate control views before they try to add more detection.

Contextual remediation is now a control requirement. If AI-generated code is being used at scale, then generic severity scoring is too slow and too abstract to support developer decisions. The practical shift is toward fix guidance that understands application criticality, code context, and business impact. Teams that cannot operationalise that move will keep paying a hidden tax in flaw density and rework.

DevSecOps is moving from enforcement at the gate to governance inside the workflow. That matters because the control point is no longer the release checkpoint alone. Security, development, and platform teams need shared decision logic during design, build, and test, otherwise AI simply accelerates the arrival of unresolved risk. The implication is clear: governance has to be embedded earlier or it will always arrive late.

AI-powered application security also reveals an identity lesson. The article's workflow model depends on trustworthy automation, which means every automated action needs clear authority, traceability, and scope. As application security becomes more autonomous, teams should apply the same discipline they use for privileged access and non-human identity governance. The practitioner takeaway is to govern automation as a controlled actor, not a convenience layer.

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

Application security is becoming a control orchestration problem. The article's strongest signal is that speed gains from AI coding are only useful when security decisions can be made inside the same workflow. That pushes practitioners toward a unified operating model where finding, prioritising, and fixing vulnerabilities happen continuously rather than as separate handoffs.

AI-generated code introduces a new governance pressure point. The issue is not simply whether AI can write code, but whether organisations can control the security quality of code that moves faster than their existing review model. Teams should expect stronger demand for integrated policy enforcement, traceable remediation, and evidence that automated fixes are being accepted for the right reasons.

For practitioners

• Implement a unified application security posture view Correlate SAST, DAST, SCA, runtime, and policy findings into one operating view so teams can prioritise by application criticality and release risk.
• Embed AI-assisted remediation into the IDE Provide fix recommendations where developers write code, and track whether suggested changes are accepted, modified, or rejected.
• Reduce false-positive churn before adding more scanners Measure how much analyst time is spent triaging duplicates and low-value alerts, then tune or remove sources that do not improve decision quality.
• Apply policy enforcement to application criticality Use automated policy rules that vary by system sensitivity, data exposure, and deployment context so every team is not forced through the same control path.
• Treat automation authority as a governed asset Define which AI-assisted security actions are advisory, which are approval-gated, and which can execute automatically so workflow automation does not become shadow control.

Key takeaways

• AI-assisted coding is widening the gap between development throughput and security control capacity, so unresolved flaws can accumulate even when teams are highly active.
• Fragmented point tools create more governance overhead than protection unless their outputs are normalised into a single remediation path.
• The practical response is to move security decisions into the developer workflow, where remediation can be contextual, fast, and measurable.

Key terms

• AI-powered offensive security: AI-powered offensive security is the use of artificial intelligence to simulate attacks and test defenses. It applies models to reconnaissance, phishing simulation, exploit chaining, vulnerability prioritization, and adversary emulation, while keeping human oversight on scope, safety, and authorization. The goal is to expose realistic weaknesses before real attackers do.
• 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.
• Identity Security Posture Management: Identity security posture management is the continuous assessment of identity configuration, privilege, and exposure across an environment. It focuses on drift, overprivilege, and control gaps so teams can see where IAM, PAM, and NHI governance are failing before those gaps become incidents.
• AI-assisted remediation: AI-assisted remediation is the use of models or agents to propose, generate, or apply fixes for software failures. In identity terms, it creates a delegated action path that can move from observation to change, so governance must cover both the decision and the execution boundary.

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 security and platform teams connect identity discipline to the broader controls that keep automation governable.