45% of AI-Generated Code Has Security Flaws: A CTO's Checklist for Vetting Outsourced AI-Written Code

Introduction

Quick answer: if an outsourcing vendor is writing code with AI assistants, a CTO cannot take that code on faith. Independent research shows that roughly 45% of AI-generated code contains a known security vulnerability. Before signing or renewing a contract, require disclosure of which AI tools are used, mandatory senior-engineer review, SAST/SCA/secrets scanning in the pipeline, an SBOM with every release, and ideally an independent AI code audit.

On paper, the speed looks great: the outsourced team ships pull requests faster than any team you've worked with before, feature branches merge daily, the sprint board empties ahead of schedule. Then a planned or client-initiated due-diligence security audit turns up a long list of critical issues: hardcoded credentials, a SQL query built through string concatenation, a dependency with a known CVE that's been sitting in production for months. Nobody flagged it, because nobody was specifically looking for the patterns AI tools tend to introduce.

This isn't hypothetical. A recent industry report tested over 100 large language models on 80 security-related coding tasks and found that AI-generated code introduced a known vulnerability in roughly 45% of cases. The number held up in a retest on newer flagship models, and independent research on different AI coding assistants found comparably high rates of insecure code.

This doesn't mean 45% of AI-built projects are insecure, or that AI-assisted development should be avoided. It means AI-generated code, on average, deserves the same skepticism you'd apply to code written quickly by a human unfamiliar with your specific system. The rest of this article breaks down what that statistic actually measures, why AI-written code from an outsourcing vendor needs extra governance, the specific risk categories to check for, a practical checklist, the contract clauses worth requiring, what a full AI code audit looks like, and the warning signs that should make any CTO pause before signing.

What "45% of AI Code Has Security Flaws" Actually Means

Before using this number to make decisions, it's worth unpacking it, because it's frequently misquoted.

The methodology behind it gave the same 80 coding tasks to over 100 different LLMs, each task constructed with a known potential for a specific type of vulnerability, then ran the resulting code through standard static analysis tools to check whether the model chose a secure implementation or an insecure one. Across all models and tasks, roughly 45% of generated samples introduced a real, known vulnerability class, most often SQL injection, cross-site scripting, log injection, and weak or outdated cryptography, mapping to established OWASP Top 10 categories. Tellingly, the failure rate didn't correlate cleanly with how recent the model was: newer, more capable models produced syntactically cleaner code over time, but the security failure rate barely moved, suggesting that general capability improvements don't automatically translate into safer defaults.

The number is also unevenly distributed. Java consistently showed the worst results in this research, with a failure rate above 70% in some testing rounds, while Python performed comparatively better, though still far from clean. Researchers attribute part of this gap to the training data itself: older, more widely represented languages carry more legacy, and often outdated, code patterns for a model to draw on.

So what this number does not say: it doesn't say "45% of AI-built products are insecure" or "AI-generated code is unusable." What it says is that when a model has a choice between a secure and insecure way to implement something, it picks the insecure option often enough that no responsible engineering process can treat AI output as pre-vetted. In practice, this shows up as:

• Unsafe or outdated coding patterns pulled from training data that predates current best practices
• Authentication and session logic that looks functional but misses edge cases
• Classic injection vulnerabilities (SQL injection, XSS) reproduced almost verbatim from common, often vulnerable, examples
• Hardcoded secrets left directly in code instead of pulled from a secrets manager
• Recommended dependencies that are outdated, unmaintained, or carry known CVEs
• API calls that technically work but skip authorization checks

None of this is a reason to avoid AI-assisted development. It's a reason to treat AI-generated code the way you'd treat code from an unvetted, junior contributor: the exact lens that needs to be applied when evaluating an outsourcing vendor, and often isn't.

Why AI-Written Code from an Outsourcing Vendor Needs Extra Governance

With an in-house engineering team, a CTO usually has some baseline visibility, even informally: who's using an AI coding assistant, which tools are allowed, what the review culture actually looks like in practice.

With an outsourcing vendor, most of that visibility disappears by default, not because vendors are acting in bad faith, but because nothing in a typical outsourcing agreement asks about it. Specifically, the client usually doesn't know:

• Which AI tools were used, and whether that's consistent across developers
• Whether a documented AI usage policy exists
• Whether code provenance exists: which parts of the codebase were AI-generated
• Whether prompts were controlled, or whether proprietary code or client data ever went into a third-party AI tool as context
• Who's actually accountable if a vulnerability reaches production

These gaps aren't visible in a demo or the first few sprints; they surface during an audit, an incident, or due diligence, by which point discovery is already far more expensive. Fixing a vulnerability during code review is typically a few hours of senior-engineer work; the same vulnerability in production means an emergency fix outside the schedule, possible downtime, and, in the worst case, a derailed deal because due diligence failed. A technical due diligence checklist is a useful starting point for closing exactly this kind of visibility gap before it becomes a production problem.

The Biggest Security Risks Hidden in AI-Generated Code

AI Often Introduces Insecure or Outdated Dependencies

Models recommend libraries based on how common they were in training data, not their current maintenance or security status. A suggestion with a known CVE or years without a patch looks completely normal in a pull request, and becomes part of the product's supply chain, inherited by every feature built on top of it.

Hardcoded Secrets and Credentials Can Reach Production

An AI assistant is asked to write a working example, and it fills in a credential placeholder so the code will run. If that placeholder isn't swapped out before merge, it ships. A hardcoded credential in a repository is often trivial to exploit the moment it's discovered, with no elaborate tooling required.

AI Can Reproduce Common OWASP Vulnerabilities

The public code models train on contains plenty of unsafe patterns alongside safe ones, often because the insecure version shows up in tutorials and community answers more often than the properly secured one. Code with one of these flaws usually passes all functional tests, because functional tests check whether a feature works, not whether it can be exploited.

AI-Generated Code Can Create Licensing and Compliance Risk

Code provenance matters beyond security. AI coding assistants train on code under a wide range of licenses, and the output can end up close enough to licensed code to raise real attribution questions. More enterprise clients are now asking about this directly during due diligence.

Code Nobody Understands Becomes Technical Debt

When AI generates code faster than the team absorbs it, review becomes shallow, debugging takes longer, and the team grows dependent on re-querying the AI tool even for changes that should be trivial. Maintainability needs to be an explicit evaluation criterion from the start; it's hard to retrofit later, a pattern we've also seen play out in codebases carrying unmanaged technical debt more generally.

In short, these five risk categories map to a single check matrix:

Case: How an AI Code Audit Saved an Enterprise Deal

(anonymized at the client's request; product details are generalized)

Product and stack. A B2B SaaS platform for logistics and shipment tracking. Node.js/TypeScript backend, PostgreSQL database, React frontend, integration with a third-party mapping API.

Scale. Roughly 40,000 active users; an outsourced team of six developers, eight months into the engagement, making heavy use of an AI coding assistant with no formal policy on where that was allowed.

Problem. Ahead of signing a new enterprise client, the product team commissioned an independent AI code audit of the codebase. The audit found three critical issues: an API key for the mapping service, hardcoded into a config file the AI assistant generated while scaffolding a new integration; a SQL query in the reporting module built through string concatenation (classic SQL injection); and a JWT library with a publicly known CVE, which the AI assistant had suggested as the "standard" choice when implementing authentication. All three pieces of code passed functional testing without issue. Vulnerability and functionality turned out to be completely independent of each other.

Solution. The team ran a full audit cycle: SAST, SCA, secrets scanning, and manual review of the AI-assisted portions of the codebase against the OWASP Top 10. The exposed key was moved into a secrets manager and rotated; the SQL query was rewritten as parameterized; the JWT library was upgraded to a patched version. In parallel, the team added mandatory secret scanning and SAST as a security gate in CI/CD that blocks merges on critical findings, and introduced a rule: every AI-generated PR gets flagged as such and reviewed by a senior engineer separately from standard QA.

Result. The enterprise client's due diligence went through on schedule; a follow-up audit six weeks later found no critical issues. The key lesson learned: none of the three findings would have been caught by standard QA. Security and functionality turned out to be entirely different dimensions of quality.

CTO Checklist Before Accepting AI-Generated Code from an Outsourcing Vendor

This is the practical core of vendor evaluation. It doesn't need to be exhaustive to be useful; it needs to surface the gaps described above before they become production incidents.

AI Usage

• Are AI coding assistants permitted in this engagement, and specifically which ones?
• Is their use restricted by role, seniority level, or task type?
• Is there a written policy, or is it left to individual developer discretion?

Review Process

• Is every AI-generated change reviewed by a senior engineer, specifically flagged as AI-generated, before merge?
• Is code review mandatory, or can changes merge with a single approval, or none at all?

Security

• Does static security analysis (SAST) run on every change, or only periodically?
• Is dependency scanning automated in the pipeline?
• Is secret scanning enforced, not just available?
• Is any dedicated security testing performed beyond standard QA?

Supply Chain

• Is a Software Bill of Materials (SBOM) generated and maintained for the project?
• Is dependency tracking automated, or manual and inconsistent?
• Is Software Composition Analysis (SCA) run regularly against the current dependency tree?

Pipeline

• Are branches protected from direct pushes to production code?
• Does CI/CD include automated validation gates, not just a successful-build check?
• Are there mandatory security gates that block merges or releases on unresolved critical findings?

Governance

• Is there a documented AI usage policy defining which tools are permitted and how?
• Is there control over what goes into prompts, specifically proprietary code, credentials, or client data?
• Are there explicit limits on sending sensitive data to third-party AI tools?

Documentation

• Is architecture documentation kept current as AI-assisted changes merge?
• Are architectural decisions recorded (e.g., ADRs), or does context live only in someone's head?
• Are code comments and provenance documentation good enough for a new engineer to actually trace the reasoning?

A vendor who answers most of these questions clearly, even if some answers are "we're still building that process," is in a fundamentally different risk category than one who's never considered these questions at all.

Common Mistakes CTOs Make When Evaluating AI-Generated Code from Outsourcing

These are mistakes made by the client company itself, as distinct from the vendor red flags covered further below.

• Judging a vendor by delivery speed alone. An empty sprint board and fast PRs are a productivity signal, not a security or quality one; without separate security metrics, speed easily masks technical debt.
• Not asking about AI tools before signing. The question "do you use AI" typically surfaces during an incident or due diligence, when it's far easier to build into the agreement at the vendor-selection stage.
• Applying the same QA process to AI code as to everything else. Functional tests check whether a feature works, not whether it's secure, which is exactly how three vulnerabilities slipped through unnoticed in the case above.
• Relying on verbal assurances instead of contract terms. Governance that isn't written down is usually the first thing to erode under deadline pressure.
• Postponing dependency review until a CVE is disclosed. Without an SBOM and regular SCA, a company only learns about a vulnerable dependency after it's already been publicly disclosed, when the response is always more expensive.
• Running an audit only once, at the start. The codebase and dependency set change with every sprint; a one-time audit at kickoff doesn't cover risks that accumulate months later.
• Confusing "AI writes code fast" with "AI writes code safely." These are two different dimensions of quality: newer, more capable models produce syntactically cleaner code, but their vulnerability rate isn't lower.

Contract Clauses Every CTO Should Require

Governance that isn't written into the contract usually erodes the moment deadline pressure appears. Clauses worth discussing before work begins:

• AI usage disclosure: a contractual obligation, not a verbal assurance
• Documentation of generated code: AI-assisted portions of the codebase must be identifiable
• Mandatory human review: a senior engineer reviews AI-generated code before merge
• Mandatory security scanning: SAST, SCA, and secrets scanning as a delivery requirement
• SBOM delivery: with every release, not only on request after an incident
• Critical vulnerability remediation before release: an explicit gate that blocks release with open critical findings
• Dependency review: new dependencies checked for maintenance status and known vulnerabilities before adoption
• Sign-off process: clear accountability at every stage on the path to production
• Pre-production security audit: with a defined cadence afterward as well

None of these clauses assume bad faith on the vendor's part; they simply lock in what, without explicit terms, usually gets deprioritized under deadline pressure.

What an AI Code Audit Should Include

Whether the engagement with a vendor is already underway, or a company is deciding whether to continue with an existing partner, an independent AI code audit is the most direct way to get a real answer instead of a vendor's self-assessment. A properly scoped audit typically follows this sequence:

Architecture review → Dependency scan → SAST → Secrets scan → SBOM validation → Code review (with specific attention to AI-generated portions) → OWASP Top 10 verification → Final report

The client should receive a prioritized findings report (critical, high, medium, low) tied to specific files and vulnerability classes, a clear picture of dependency and supply-chain risk, and a practical remediation plan the development team can actually act on. This is the same discipline behind a broader non-functional requirements audit: security is a quality attribute, and it only stays managed when someone measures it on a schedule.

Warning Signs That Should Concern Every CTO

Some answers, on their own, are reason enough to look more closely before signing or renewing a contract.

• "We trust our AI assistant." Trusting a tool isn't a substitute for a review process.
• "AI writes most of our boilerplate." Worth confirming how that boilerplate gets checked, and whether authentication, data-access, or payment logic is quietly included in it.
• "We don't separate AI-written code." Without provenance, there's no way to apply extra scrutiny where it's actually needed.
• "We don't track AI usage." The client has no visibility into which tools touched proprietary code.
• "Security testing only happens before release." This pushes critical-issue discovery to the most expensive possible point.
• "We don't generate an SBOM." Dependency risk effectively isn't tracked at all.
• "Everything passes code review automatically." Automatic approval isn't review; it's a removed barrier with no real accountability behind it.

Any single answer can have a reasonable explanation. Several of these together, from the same vendor, is a pattern worth taking seriously.

Conclusion

Speed from AI-assisted development is a real advantage, but only when it's paired with controlled review, security testing, and clear accountability. If a vendor can't clearly explain how they manage AI-generated code, that's not a minor gap. It means the risk hasn't disappeared; it's simply sitting with the client instead of being actively managed.

The good news is that closing this gap doesn't require slowing down AI-assisted development. It requires treating AI governance as a standard part of vendor evaluation, the same way security review, SLAs, and IP ownership have long been treated, rather than something discovered only during an incident.

If you're not sure whether your current or prospective outsourcing partner's AI practices would hold up under scrutiny, an independent AI code audit is the most direct way to find out before it becomes a production problem. Our audits combine architecture review, dependency and secrets scanning, SAST, SBOM verification, and manual review of AI-assisted code against the OWASP Top 10. Contact us to discuss an AI code audit for your outsourced codebase.