AI-generated code and slow remediation are widening AppSec risk

At a glance

What this is: This research says application security has more visibility than ever, but organisations still filter, delay and deprioritise known risk faster than they can fix it.

Why it matters: It matters because IAM, NHI and broader security programmes now depend on faster, more reliable remediation decisions across software supply chains, AI-assisted development and operational access controls.

By the numbers:

• 49% of production code is now AI-generated.
• 81% of organizations were breached twice or more in the past 12 months.
• Only 9% of organizations fix more than 90% of vulnerabilities within 90 days.

👉 Read Checkmarx's report on AI-generated code, AppSec risk and remediation delay

Context

Application security now has a visibility problem of a different kind. AI-based detection, abundant breach data and mature tooling have not translated into faster remediation, because organisations keep inserting review layers that slow action after a risk has already been found.

That gap matters well beyond AppSec. When AI-generated code, open-source dependency sprawl and delayed fixes become normal, identity and access governance also inherits more uncertainty around software integrity, workload trust and the control points used to approve change.

The article frames this as an industry-wide paradox, not an isolated tooling failure. The starting position is increasingly typical across large organisations that can detect risk but struggle to operationalise it.

Key questions

Q: What breaks when vulnerability findings are not verified after remediation?

A: Without verification, teams assume risk is gone when it may still be present. That creates false closure, duplicate effort, and audit confusion. Effective programmes require automatic rescans and confirmation that the issue is fixed before the finding is closed.

Q: Why do AI-generated code changes increase application security risk?

A: AI-generated code can increase risk because it accelerates output faster than review, testing, and secret hygiene can keep up. The issue is not only flawed logic. It is also the possibility that tokens, credentials, unsafe dependencies, or insecure defaults are reproduced at scale across the delivery pipeline.

Q: How do you know if AppSec remediation is actually working?

A: Look for shrinking time-to-fix, fewer deferred exceptions and fewer vulnerabilities surviving multiple release cycles. If detection volume rises but exposure duration stays flat, the programme is producing more findings without improving risk reduction. Effective remediation changes the age and persistence of known issues, not just the count of alerts.

Q: Should organisations treat developer friction as a security risk signal?

A: Yes. When developers spend large amounts of time on security but still ship vulnerable code, friction is telling you that the process is misaligned. That usually means the feedback is too late, the guidance is too vague or the approval chain is too slow to support secure delivery at scale.

Technical breakdown

Why AI-generated code changes the AppSec control problem

AI-generated code changes the unit of risk. Security teams are no longer reviewing only human-authored logic, they are reviewing blended code where the developer acts more like an editor than an author. That creates more volume, more third-party provenance, and less confidence in the assumptions behind code review. The report’s data suggests vulnerable code rises as AI-generated content increases, which is consistent with a control model that was built for slower, more deterministic development workflows. Practical implication: teams need review and policy gates that scale with machine-generated output, not just more alerts.

Practical implication: align policy and review depth to code provenance, not to developer intent.

Why checkpoint-based remediation leaves risk behind

Checkpoint security assumes risk can wait until the next gate. In practice, modern pipelines move faster than the review layer, so vulnerabilities can persist long after detection. The article shows that organisations detect issues widely, yet only a small minority resolve almost all vulnerabilities within 90 days. That is a control failure, not a visibility failure. The deeper issue is queue design: findings accumulate, triage becomes political, and known risk survives because no one owns the final decision fast enough. Practical implication: shift from periodic review to continuous, policy-backed remediation workflows.

Practical implication: replace periodic checkpoint handling with continuous remediation ownership and enforcement.

How AI changes the developer burden in secure software delivery

The report shows developers are spending substantial time on security while still shipping vulnerable code, which means the burden is not just technical but operational. When feedback is late, low-value, or unclear, developers become the last mile for a broken governance model. That is especially relevant for organisations using AI code generation, because more generated code increases the amount of review work without automatically improving assurance. Practical implication: reduce friction at the point of code creation and make remediation guidance precise enough to act on immediately.

Practical implication: make security feedback actionable at the point of creation, not after release pressure has built.

Threat narrative

Attacker objective: The attacker objective is to exploit the delay between vulnerability discovery and remediation before defenders can close the window.

1. Entry occurs through AI-generated or open-source-heavy code paths where insecure patterns are introduced faster than teams can inspect them.
2. Escalation happens when known vulnerabilities remain open across repeated review cycles, creating a persistent window for abuse.
3. Impact is delivered through breached systems, delayed releases, and a security programme that cannot convert detection into timely containment.

NHI Mgmt Group analysis

Detection without remediation is governance debt: this research shows that visibility has outpaced organisational decision-making. Security teams now know more, but they do not act faster, which means risk is accumulating in the review queue rather than disappearing from the environment. The real problem is not missing data, it is the inability to convert findings into enforced outcomes. Practitioners should treat this as a governance failure with direct control implications.

AI-generated code introduces provenance ambiguity into application security: once production code is materially machine-generated, the old assumption that review effort maps cleanly to developer-authored logic breaks down. That creates a new control problem around source trust, policy enforcement and change accountability. The organisation needs evidence about where code came from and how it was validated, not just whether it was scanned. Practitioners should re-evaluate their trust model for code creation and approval.

Continuous security is now a remediation requirement, not a maturity aspiration: the report’s 18% continuous application rate shows that most teams still depend on checkpoints that are too slow for current delivery speeds. This is exactly where NIST Cybersecurity Framework 2.0 and NIST SP 800-53 style control thinking matter, because the issue is control execution, not awareness. Practitioners should redesign workflows so findings are resolved in-line with delivery.

Developer frustration is a control signal, not just an experience issue: when teams spend half their time on security and still ship vulnerable code, the programme is telling you that policy, tooling and feedback loops are misaligned. That is how organisations end up with advanced-looking posture and weak outcomes. The right response is to measure whether the workflow reduces exposure, not whether it generates more findings. Practitioners should use developer friction as an indicator of control quality.

What this signals

Remediation latency is now a programme-level risk variable: as AI-assisted development accelerates, security leaders need to measure whether their control chain can still close findings before they age into exploitation opportunities. The right benchmark is not how many issues were found, but how quickly the highest-risk ones are removed from production.

Code provenance will become a governance requirement: once AI-generated code makes up a material share of production, teams need to know which changes were machine-assisted, which were manually reviewed and which were exception-based. That creates a bridge to identity and access governance, because trust in software increasingly depends on trust in the systems and accounts that produced it.

The strongest programmes will stop treating detection as the finish line and start measuring decision velocity. That shift will matter just as much for NHI lifecycle control, where standing credentials and delayed revocation create the same pattern of known risk surviving longer than it should.

For practitioners

• Measure remediation latency by control owner Track the time from vulnerability discovery to fixed deployment by application owner, not just by severity. Separate findings that were accepted, deferred or blocked so you can see where the decision chain is breaking down.
• Introduce code provenance checks for AI-generated work Require teams to identify where AI-generated code enters the pipeline and to apply stricter review or approval thresholds to those paths. Pair this with evidence of testing, dependency validation and exception handling for higher-risk repositories.
• Convert checkpoint review into continuous enforcement Move from periodic security gates to inline controls that fail builds, block release paths or trigger mandatory remediation when policy conditions are not met. The goal is to stop known risk from surviving the decision chain.
• Prioritise top-failure workflows before adding more tooling Use the report’s developer burden findings to identify where feedback is late, vague or low value, then fix those workflows before expanding the tool stack. Pair that effort with the NHI Lifecycle Management Guide for release and access-control parallels.

Key takeaways

• The core problem is not a lack of security visibility, but a decision chain that lets known risk survive long enough to matter.
• The scale of the gap is clear in the data: AI-generated code is widespread, breaches remain common and only a small minority of organisations can fix vulnerabilities quickly.
• Teams need continuous enforcement, better provenance control and shorter remediation loops if they want detection to translate into risk reduction.

Key terms

• Application Security: Application security is the practice of protecting software across development, deployment, and runtime. It covers code, dependencies, secrets, infrastructure, and execution behaviour, because any one of those layers can expose data or access if it is not governed as part of the same lifecycle.
• AI-Generated Code Risk: AI-generated code risk is the possibility that model-produced output introduces insecure credential handling, hidden secrets, or repeated patterns that weaken control design. The risk is operational, because the output can be merged quickly and at scale before humans catch the problem.
• Remediation Latency: The time between identifying a security issue and fully removing or reducing the risk. For NHIs and SaaS access, this metric matters because stale credentials, over-shared files, and dormant integrations stay usable until the control finally acts.

What's in the full report

Checkmarx's full report covers the operational detail this post intentionally leaves for the source:

• Regional breakdowns across 14 countries, including how breach rates and remediation differ by geography.
• Complete cross-tabulation of AI code volume against vulnerable code deployment and breach frequency.
• The three-way perception gap between CISOs, AppSec managers and developers, with role-by-role survey splits.
• Six strategic imperatives for closing the gap between detection and action, including the case for agentic security.

👉 The full Checkmarx report covers the regional data, role-by-role perception gaps and the remediation imperatives in detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management and workload identity with practitioner-focused context. It helps security teams connect identity control decisions to broader programme risk.