Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
Is AI-generated code secure?
Updated
AI-generated code is neither inherently secure nor insecure. Risk concentrates in failure modes your controls must catch — injection, secrets, insecure defaults, and hallucinated dependencies. This page is not legal advice.
AI-generated code security, last verified 10 September 2026 against OWASP Top 10 and OWASP Top 10 for LLM Applications, NIST SP 800-218 and SP 800-218A, CWE, CISA secure-by-design guidance, and peer-reviewed Copilot security studies (Pearce et al. 2022; Perry et al. 2023) with methodology stated. It is not legal advice and does not certify YOUR code.
The honest answer — neither blanket secure nor blanket insecure
Audience: a CTO, CISO, engineering leader, or founder deciding guardrails for AI-assisted development. This page is not legal advice. It does not certify YOUR repositories, does not replace your secure-SDLC obligations, and does not answer whether a specific AI coding tool is approved for YOUR organisation.
AI-generated code is neither categorically secure nor categorically insecure. Security depends on what the model suggests, what the developer accepts, what review and automated testing catch, and what your deployment pipeline enforces. Treating all AI output as safe is unsafe. Banning all AI assistance without measuring YOUR risk is also a policy choice this page does not make for YOU.
Empirical work on AI-assisted coding and security exists, but each study has scope limits. Pearce et al. (2022, ACM CCS, Asleep at the Keyboard) tested GitHub Copilot as of August 2021 on 89 scenario prompts derived from CWE weakness classes, generating 1,689 programs across 38 tasks; the authors reported that roughly 40 percent of generated programs contained vulnerabilities matching the scenario weakness. That is a synthetic benchmark on a 2021 model — not a production-repo census and not a forecast for YOUR 2026 stack. Perry et al. (2023, IEEE Symposium on Security and Privacy, Do Users Write More Insecure Code with AI Assistants?) ran a controlled lab study with 47 participants completing security-sensitive programming tasks with and without an AI assistant; participants with the assistant produced less secure solutions on several tasks. That is a human-factors lab study — not longitudinal data from YOUR teams. Do not paste either number onto YOUR organisation without YOUR own measurement. Last verified 10 September 2026. Not legal advice.
- Legal requirement versus regulator guidance versus industry best practice versus SRM recommendation: NIST SP 800-218 (SSDF) and SP 800-218A (GenAI profile) are NIST guidance — adopt through YOUR policy, not automatic law. OWASP Top 10 and OWASP LLM Top 10 are community consensus lists — best-practice framing, not statutes. CWE is a weakness taxonomy from MITRE — a reference, not a compliance test. CISA secure-by-design principles are agency guidance. ShipReady Metrics recommendations below describe product signals — not certifications.
- The measure-ai-generated-code-risk guide on this site is the quantification page. The detect-security-issues-ai-coding-agents guide on this site is the detection-pipeline page. The ai-coding-governance-checklist guide on this site is the controls page. The vulnerability-management glossary on this site defines how SRM prioritises findings.
Where risk concentrates — failure modes
OWASP Top 10 (web application risks) and OWASP Top 10 for LLM Applications (LLM-specific risks such as prompt injection, insecure output handling, and supply-chain issues for models and plugins) describe categories that appear repeatedly when AI tools draft code. NIST SP 800-218A maps GenAI use to SSDF practices such as threat modelling, secure coding, and verification. CWE names concrete weakness types (for example CWE-89 SQL injection, CWE-798 hard-coded credentials, CWE-1104 use of unmaintained third-party components).
The table below is a risk-concentration view: where failures cluster, how often they tend to appear in published empirical work and field reports (qualitative, not YOUR rate), and mitigations aligned to SSDF and OWASP. Likelihood labels are qualitative summaries of cited literature and incident patterns — not YOUR measured frequency. Last verified 10 September 2026. Not legal advice.
| Failure mode | Likelihood (qualitative) | Mitigation |
|---|---|---|
| Insecure defaults — weak crypto, open permissions, debug endpoints left enabled | High in synthetic benchmarks (Pearce et al. 2022 reported vulnerable outputs across many CWE scenarios) and common in rushed merges | Secure defaults in frameworks; IaC and config review; SAST on config files; block merge without review on auth and crypto paths (NIST SSDF PW.7, RV.1) |
| Injection — SQL, command, template, and prompt-to-code injection paths | High where AI drafts queries or shell without parameterisation; OWASP A03 and LLM01–LLM02 classes | Parameterized queries; input validation; SAST/DAST; never trust model output as sanitised (OWASP, CWE-89, SSDF PW.5) |
| Secrets in source — API keys, tokens, passwords committed with generated code | Medium to high in lab studies and secret-scanning vendor reports; Perry et al. 2023 found security-sensitive task failures | Pre-commit and CI secret scanning; vault references only; rotate on exposure; block merge on secret findings (CISA secure-by-design, SSDF PW.6) |
| Hallucinated or typosquatted dependencies — packages that do not exist or mimic popular names | Medium; OWASP LLM03 supply-chain and LLM hallucination risks; field reports of slopsquatting | Allow-list registries; dependency review; software composition analysis; human verification of new package names (SSDF PW.4, CISA SBOM guidance) |
| Missing authorisation and authz bugs — endpoints without checks | High in Pearce et al. scenario set for access-control CWEs | Threat modelling per feature; mandatory security review on auth paths; integration tests for negative cases (OWASP A01, SSDF PO.1) |
| Over-trust of generated tests — tests that assert the buggy behaviour | Medium in practitioner reports; not a single CWE but a process failure | Require human review of test intent; mutation testing where appropriate; do not waive review because tests exist (SSDF RV.1) |
What empirical studies do and do not prove
Pearce et al. (2022): sample — 89 CWE-derived scenarios, 1,689 generated programs, Copilot August 2021. Finding — a large share of outputs were vulnerable under their static analysis. Caveats — synthetic prompts, single tool vintage, static analysis only, no YOUR codebase.
Perry et al. (2023): sample — 47 participants, controlled tasks, AI assistant versus control. Finding — assistant group produced less secure code on several security tasks. Caveats — lab setting, short tasks, participant self-selection, not YOUR team's toolchain or maturity.
Neither study proves YOUR next pull request will be insecure. Both support the policy conclusion that AI assistance shifts burden to review, testing, and supply-chain controls rather than eliminating them. Measure YOUR repos; do not debate from anecdotes alone. The measure-ai-generated-code-risk guide on this site is the next step.
Legal requirement versus guidance versus best practice versus SRM
Last verified 10 September 2026. Not legal advice.
| Source | What it is | What this page does not do |
|---|---|---|
| NIST SP 800-218 (SSDF) and SP 800-218A | NIST guidance on secure software development and GenAI profile practices. | Does not certify that YOU implement SSDF. |
| OWASP Top 10 and OWASP LLM Top 10 | Community consensus risk lists for applications and LLM applications. | Does not replace YOUR threat model. |
| CWE | MITRE weakness taxonomy. | Does not score YOUR code. |
| CISA secure-by-design | Agency guidance urging secure defaults and transparency. | Does not create a private-sector legal duty by itself. |
| ShipReady Metrics AI-authored-code floor and Security findings | Product telemetry and ingest — SRM recommendation. | Does not certify secure code or replace pen testing. |
What you need to do now
Operational preparation for engineering leaders. Not a determination that YOUR policy is sufficient. Not legal advice.
- Assume AI suggestions are untrusted input until review and automated gates pass — SSDF PW and RV practices.
- Map YOUR highest-risk surfaces (auth, crypto, PII, payments, infra) and require human security review on AI-touched changes there.
- Run SAST, secret scanning, and dependency analysis on every merge; prioritise with KEV, EPSS, and CVSS in YOUR vulnerability workflow — see the vulnerability-management glossary on this site.
- Track AI authorship share and finding rates over time — the measure-ai-generated-code-risk guide on this site — instead of debating from single anecdotes.
- Adopt the ai-coding-governance-checklist guide on this site for tool approval, provenance, and review gates.
- Do not treat a green AI tool demo as proof YOUR repository is secure.
Checklist
Question list for YOUR programme. Not a certification. Walk with security and engineering leadership.
- Have you listed approved AI coding tools and data-handling rules?
- Do merge gates include SAST, secret scan, and dependency analysis on AI-touched paths?
- Are auth, crypto, and injection-prone changes tiered for mandatory human review?
- Do you measure finding rates on AI-attributed commits separately from human-only commits?
- Is there a process to verify new package names before install?
- Have you read Pearce et al. 2022 and Perry et al. 2023 with their sample-size caveats before setting policy?
- Does counsel own regulatory duties if AI touches regulated data — this page does not run that test.
Where this shows up in ShipReady Metrics
Signed-in AI Code Readiness reporting includes an AI-authored-code floor: a count of git-marked or attributed AI commits — a provenance signal, not proof every line was AI-written and not a security score.
Signed-in Security → Findings ingests SAST, DAST, Dependabot, code scanning, and secret-scanning sources with deduplication. Findings can be prioritised with KEV, EPSS, and CVSS per the methodology on the what-we-measure page. That is how YOU observe whether AI-assisted repos introduce more issues — not a vendor claim that AI code is secure.
The engineering risk score is a composite vendor methodology with coverage-as-confidence honesty — not an industry standard or audit opinion.
This product does not certify code as secure, does not replace penetration testing, and does not determine legal compliance for YOUR AI tools.
Primary sources (last verified 10 September 2026)
Every security claim on this page traces to one of these or the cited studies above.
OWASP Top 10 (2021) and OWASP Top 10 for Large Language Model Applications are community publications. NIST SP 800-218 (February 2022) and NIST SP 800-218A (GenAI profile, 2024) are NIST guidance. CWE is maintained by MITRE. CISA secure-by-design is agency guidance at cisa.gov. Pearce et al., Asleep at the Keyboard, ACM CCS 2022. Perry et al., Do Users Write More Insecure Code with AI Assistants?, IEEE S&P 2023. Not legal advice.
Frequently asked questions
Is AI-generated code secure?
Neither categorically. Security depends on YOUR controls: review, SAST/DAST, secret and dependency scanning, and secure defaults. Published studies on Copilot-era tools found vulnerable outputs in controlled settings, with stated sample and methodology limits. Measure YOUR repositories rather than trusting or banning AI outright.
Should we ban AI coding tools?
That is a risk decision for YOUR leadership. This page does not mandate ban or adoption. Evidence shows risk concentrates in specific failure modes mitigated by SSDF-aligned controls. Many organisations adopt AI assistance with stricter gates on high-risk paths.
Does ShipReady Metrics certify our AI-generated code as secure?
No. The product surfaces authorship telemetry and security findings from connected sources. It does not certify code, issue penetration-test opinions, or replace YOUR secure-SDLC obligations.
Which study should I read first?
Pearce et al. 2022 (CCS) for synthetic vulnerability rates in Copilot suggestions with 89 scenarios and 1,689 programs. Perry et al. 2023 (IEEE S&P) for human factors with 47 participants. Read the methodology sections before quoting any number.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.