Safeguard
AI Security

Building trust in AI-assisted software development

AI writes 30-50% of new code at many shops now, and 45% of it ships with security flaws. Here's how to build real trust in that pipeline.

Priya Mehta
DevSecOps Engineer
6 min read

Ninety-seven percent of developers now use AI coding assistants in some form, according to GitHub's 2024 developer survey, and internal tooling data from large enterprises shows AI-generated code accounts for 30-50% of new commits at organizations that have rolled out Copilot, Cursor, or Claude Code broadly. That shift happened in under three years. It also happened faster than most security, compliance, and code-review processes could adapt. A February 2025 Veracode study of 80 coding tasks across 4,000+ LLM-generated samples found that 45% contained at least one OWASP Top 10 security flaw, and models chose the insecure implementation nearly as often on the tenth retry as the first. Meanwhile, a joint academic study ("We Have a Package for You!," 2024) found that 16 popular code-generating models hallucinated non-existent package names in 5.2% to 21.7% of tested prompts — a gap attackers are already exploiting through "slopsquatting." Trust in AI-assisted development isn't a philosophical question anymore. It's an operational one, and it needs an operational answer.

Is AI-generated code actually less secure than code written by humans?

Yes, on average, though the gap is narrower than headlines suggest and depends heavily on task type. Veracode's 2025 GenAI Code Security Report tested large language models across 80 curated coding tasks in Java, Python, C#, and JavaScript and found a 45% security-flaw rate overall, with Java the worst performer at over 70% and Python and JavaScript closer to 35-40%. Cross-site scripting and log injection were the most common defects, and — notably — flaw rates did not improve as models got larger or newer within the study period, suggesting model scale alone doesn't fix the problem. Separately, a Stanford study of GitHub Copilot users (published 2023, still widely cited in 2025 vendor research) found developers using AI assistance were more likely to introduce vulnerabilities while simultaneously rating their own code as more secure — a confidence gap that matters more than the raw defect count. The takeaway for engineering leaders: AI code needs the same static analysis, SCA, and review gates as human code, applied consistently rather than skipped because "it's just a small AI-generated function."

Can attackers manipulate AI coding assistants into recommending malicious dependencies?

Yes, and this is now a named attack category called slopsquatting. When an LLM hallucinates a package name that doesn't exist — something the 2024 "We Have a Package for You!" research measured at up to 21.7% of open-source model outputs — attackers can register that exact package name on PyPI or npm ahead of time, loaded with malware, and wait for developers (or their AI assistants) to pip install or npm install it based on the model's suggestion. Researchers demonstrated this was not theoretical: 43% of hallucinated package names repeated consistently across multiple prompts and models, making them predictable and cheap to squat on. This sits alongside classic typosquatting (the ua-parser-js and event-stream npm compromises are the canonical pre-AI examples) and the 2024 XZ Utils backdoor, where a maintainer identity built over two years was used to slip a SSH backdoor into a core Linux compression library — a reminder that supply chain trust failures don't need AI to be catastrophic, but AI adds a new, faster distribution vector for the same old trick.

Do developers actually review the AI code they ship?

Not consistently, and the gap is measurable. Snyk's 2023 AI Code Security Report — one of the few vendor studies to ask this directly — found that while 96% of developers were using AI coding tools, only about 1 in 4 organizations had a formal policy governing their use, and a meaningful share of developers admitted to bypassing security checks on AI-suggested code specifically because it "felt" already validated by the tool. GitClear's 2024 AI Copilot Code Quality analysis, which examined over 150 million changed lines of code, found that code churn (lines rewritten or deleted within two weeks of being committed) nearly doubled between 2021 and 2024, tracking closely with AI assistant adoption curves — a proxy for code being merged faster than it's being properly reasoned about the first time. The practical implication: "a human clicked approve" is no longer a meaningful trust signal on its own if the human was reviewing AI output at AI-generation speed.

What does provenance actually mean for AI-generated code and its dependencies?

Provenance means being able to answer, for any artifact in production, where it came from, what generated it, and what it depends on — and as of 2024-2025 that increasingly includes whether a human or a model wrote the code and which model version. Executive Order 14028 and the resulting NIST SSDF guidance pushed SBOM (Software Bill of Materials) generation from "nice to have" toward contractual requirement for federal suppliers, and CISA's 2024 SBOM guidance explicitly flags AI-assisted development as a new category needing disclosure. In practice, this means every build should produce a machine-readable SBOM in CycloneDX or SPDX format capturing every direct and transitive dependency, and every dependency should be checked against sources like the npm and PyPI registries' typosquat detection and known-malicious-package feeds — the same feeds that would have caught many of the 2024-2025 slopsquatting packages within hours of registration rather than months.

How do you separate real risk from noise when AI tools flood you with findings?

By tracing whether a flagged vulnerability is actually reachable in your running code, not just present in a manifest file. Traditional SCA tools flag a CVE the moment a vulnerable package version appears anywhere in the dependency tree, which is why security teams routinely see 70-90% of flagged CVEs turn out to be in code paths that are never called at runtime — a ratio consistent across multiple vendor reachability studies published between 2022 and 2024. When AI coding assistants pull in dependencies faster than humans previously did (Copilot users add new third-party packages at a measurably higher rate than non-AI-assisted teams, per multiple 2024 SCA vendor telemetry reports), that noise problem compounds: more packages, more transitive depth, more alerts, same size security team. Reachability analysis — static and dynamic tracing of whether vulnerable functions are actually invoked by application code — is what turns a 10,000-line CVE backlog into the 200-800 findings that genuinely need attention this sprint.

How Safeguard Helps

Safeguard is built for exactly this shift: more code, generated faster, by more non-human authors, with less time for manual review per line. Our reachability analysis engine traces every flagged CVE against actual call paths in your codebase, so teams stop triaging vulnerabilities in dead code and focus only on what's exploitable. Griffin AI, Safeguard's security-focused model, reviews AI-generated and human-written commits alike against the same policy bar, flagging injected secrets, hallucinated or squatted dependencies, and insecure patterns before merge — then opens auto-fix PRs with the corrected code and dependency pins ready for review, closing the gap between detection and remediation. Safeguard also generates CycloneDX/SPDX SBOMs on every build and ingests SBOMs from vendors and internal teams into a single provenance graph, so you can prove — to auditors, customers, or your own security team — exactly what's running in production and where it came from, AI-assisted or not.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.