On any given day in 2026, a meaningful share of the code entering production started as a suggestion from an AI pair programmer rather than a blank cursor. GitHub has reported Copilot crossing 1.8 million paid subscribers, and Gartner has projected that by 2027 roughly 75% of enterprise software engineers will use AI coding assistants as part of their daily workflow. That velocity is the entire point of the tools — prototypes become pull requests in minutes, backlogs shrink, and junior engineers ship features that once needed a senior's help. But velocity without verification is exactly how vulnerabilities get merged. Veracode's own 2025 GenAI Code Security Report found that AI-generated code introduced a security flaw in 45% of tested completions, with Java failing more than seven times out of ten. Legacy AppSec platforms were built to scan code at human commit cadence, not machine-generation speed. This post looks at what the research actually shows, where scan-and-gate tools fall short against AI-assisted pipelines, and what secure AI-assisted development requires instead.
Why does AI-generated code fail security checks so often?
Because large language models are optimized to produce code that compiles and runs, not code that resists attack — security is a side effect of training data, not an objective function. Models learn from public repositories that are themselves full of insecure patterns: string-concatenated SQL, unvalidated request parameters, hardcoded secrets used in tutorials, MD5 used "for speed." When a developer asks for a login handler or a file upload endpoint, the model reproduces whatever pattern was statistically common in its training corpus, which is frequently the outdated or insecure one. A 2023 Stanford study by Perry et al. found that developers using an AI code assistant wrote measurably less secure code than a control group — and were more confident it was secure, which is the more dangerous half of the finding. Confidence without verification is a recurring theme in AI-assisted development: the code looks finished, reads cleanly, and passes a quick functional test, so it moves to the next stage of the pipeline unreviewed.
What did Veracode's GenAI Code Security Report actually measure?
It measured how more than 100 large language models performed against 80 curated coding tasks spanning Java, Python, C#, and JavaScript, and the headline finding was that scale didn't fix the problem. Newer, larger models produced code that was just as likely to contain a security flaw as older ones — Veracode's researchers noted the introduction rate held around 45% across model generations released between 2023 and 2025, meaning bigger context windows and better benchmark scores on coding-assistant leaderboards did not translate into fewer CWE-class defects. Java completions were the worst performer, failing security checks in more than 70% of samples, largely due to weak cryptographic defaults (CWE-327), missing input sanitization enabling cross-site scripting (CWE-79), and improper access control on generated endpoints. Python and JavaScript fared somewhat better but still failed in roughly a third to just under half of samples, depending on task category. The practical takeaway for engineering leaders: model choice is not a security control, and "we upgraded to the latest model" is not a mitigation you can put in a SOC 2 narrative.
Is the real risk the code itself, or how fast it ships?
Both, but shipping speed is the multiplier that turns a per-suggestion flaw rate into an organization-wide exposure. GitClear's 2024 analysis of over 150 million changed lines of code found that AI-assisted development correlated with a sharp rise in code churn and copy-pasted blocks — duplicated code nearly eight times more common than in 2021 — meaning the same insecure pattern doesn't get introduced once, it gets introduced repeatedly across services by different teams using the same assistant. A single insecure completion reviewed by one engineer is a bug. The same completion accepted forty times across a monorepo by forty different contributors, each unaware the others made the identical choice, is a systemic weakness that no single code review will catch. When AI assistants can generate a working PR in the time it takes to write the prompt, the bottleneck in the SDLC moves entirely to review and verification — and most review processes, human or automated, were never built to run at that cadence.
Can traditional AppSec scanning keep up with AI-assisted commit volume?
Not by itself — tools built around scheduled or pre-release scanning were designed for a world where humans, not models, set the pace of commits. Veracode's own platform, like most mature SAST/DAST offerings, is architected around policy scans and pipeline scans that developers or security teams trigger at defined checkpoints: nightly builds, release candidates, or pull-request gates that can take anywhere from a few minutes to well over an hour depending on codebase size and scan depth. That model works reasonably well when a team merges a few dozen human-authored PRs a week. It strains when AI assistants push commit volume up several-fold and each PR may contain a novel combination of generated snippets that a signature- or pattern-based scanner hasn't seen packaged together before. The result is a familiar failure mode: scans queue up, developers route around slow gates to hit sprint deadlines, and security findings arrive days after the code — sometimes after the release — instead of at the moment the AI suggestion was accepted.
What does secure AI-assisted development actually require?
It requires moving security controls into the generation and acceptance loop itself, not just the CI pipeline that runs afterward. That means three things layered together. First, real-time verification of AI suggestions as they're written, checking for the same CWE classes Veracode's report flagged — injection, broken crypto, missing access control — before the code is even committed, not in a nightly batch. Second, dependency and package provenance checks, because AI assistants don't only write insecure logic, they also recommend packages, and a 2025 supply-chain study found open-source models hallucinating non-existent package names in roughly one out of every five generated samples (commercial models closer to one in twenty) — a gap attackers have already started exploiting by publishing malicious packages under those hallucinated names, a technique researchers now call "slopsquatting." Third, an auditable record of what was AI-generated, what was human-reviewed, and what dependency actually shipped, because SOC 2 and customer security questionnaires increasingly ask directly whether AI-assisted code goes through the same provenance and attestation process as everything else in the SBOM.
How Safeguard Helps
Safeguard is built for the commit velocity AI assistants create, not the release cadence legacy AppSec tools were designed around. Instead of a policy scan that runs once near release, Safeguard verifies dependencies, package provenance, and known vulnerability data continuously as code and its dependencies change — including catching the hallucinated or typosquatted package names that AI assistants introduce and that slopsquatting attacks are built to exploit. Safeguard generates and maintains a live SBOM tied to what's actually deployed, not a point-in-time snapshot generated for an audit, so when a new CVE drops, teams know within minutes whether AI-suggested code pulled in the affected version rather than finding out during the next scheduled scan. For teams that have leaned into Copilot, Cursor, or in-house coding assistants, Safeguard adds the guardrail those tools don't ship with: policy enforcement at the point dependencies are added or code is merged, integrity verification on packages before they reach a build, and an audit trail that maps every artifact back to its source — evidence that holds up whether it's a customer security review or a SOC 2 auditor asking how AI-generated code is governed. The goal isn't to slow down AI-assisted development back to pre-Copilot speed. It's to make sure the speed doesn't outrun the organization's ability to know what actually shipped.