There is no separate security standard for AI-generated code. Code from an AI coding assistant, agent or AI app builder meets the same standards as code a developer writes, so AI-generated code security comes down to two decisions: which standard you hold the code to, and how you show the result to a customer, auditor or investor.
The gap between feeling secure and being secure is documented. In a Stanford user study published at ACM CCS 2023, participants with an AI code assistant wrote significantly less secure code than a control group and were more likely to believe their code was secure (Perry et al., 47 participants).
This guide covers how the OWASP Top 10:2025 maps to AI-built code, which standards apply, which ISO 27001 controls matter, and where to start with the evidence to keep. For the full route from prototype to launch, see ai-generated code in production.
TL;DR
AI-generated code security means keeping code written by AI coding tools free of known weakness classes and being able to prove it. No standard is written only for AI-generated code: OWASP and ISO/IEC 27001 apply to it exactly as they apply to code a developer writes.
- The OWASP Top 10:2025 gives AI-built code a shared list of ten risk categories; A01 Broken Access Control, A02 Security Misconfiguration and A03 Software Supply Chain Failures are the three to check first in an AI-built product.
- Three standards answer most customer questions: OWASP ASVS 5.0 as the testable secure coding standard, the OWASP Top 10:2025 as the shared vocabulary, and ISO/IEC 27001:2022 Annex A for management-level evidence.
- ISO/IEC 27001:2022 Annex A 8.28 “Secure coding” applies to AI-written code, and controls 8.30 (outsourced development) and 8.4 (access to source code) cover how AI coding tools are directed and what is shared with them.
- A product with real users’ personal data should start at ASVS Level 1, use Level 2 for login, access control and data handling, and keep a six-record starting evidence pack.
What AI-generated code security means
AI-generated code security is the practice of keeping code produced by AI coding tools — assistants, agents and AI app builders — free of known weakness classes, and being able to show that it is. The standards are the same ones that apply to any web application. Three things change when an AI tool writes the code.
- Volume. AI coding tools can increase the volume of changes, which makes risk-based review and automated checks more important.
- Context. The tool does not know your data model, user roles or threat model unless someone states them, so rules that depend on your business — who may see which record — are left to the tool’s guess.
- Evidence. The reasoning behind AI-generated security decisions may not be documented or understood by the team, so the record has to come from tests and reviews instead of a developer’s memory.
The weaknesses themselves are well documented; vibe coding security risks covers the seven that matter most in AI-built apps. A named standard such as ISO/IEC 27001:2022 Annex A 8.28 adds a reference a customer or auditor can check the code against.
OWASP Top 10:2025 applied to AI-generated code
The OWASP Top 10:2025 applies to AI-generated code without changes: the ten categories describe what goes wrong in web applications, whoever wrote the code. OWASP itself calls the list “a standard awareness document for developers and web application security”, which makes it a shared vocabulary, not a test you pass (OWASP Top 10:2025).
Table 1 maps each 2025 category to the way it typically appears in an AI-built product and to one question a non-technical owner can ask the developer.
| Category (OWASP Top 10:2025) | How it typically shows up in AI-built code | Question to ask your developer |
|---|---|---|
| A01 Broken Access Control | Pages and API routes check that a user is logged in, not that the record belongs to that user | Can user A open user B’s record by changing an ID in the URL? |
| A02 Security Misconfiguration | Debug mode, open database rules or permissive cross-origin settings carried over from the prototype | Which settings changed between the prototype and production? |
| A03 Software Supply Chain Failures | Packages added without review, including package names the AI tool suggested that may not exist | Who approved each dependency, and is every dependency scanned? |
| A04 Cryptographic Failures | Tokens or keys stored in frontend code or in plain text | Where are API keys, passwords and tokens stored? |
| A05 Injection | User input passed into database queries, shell commands or model prompts without validation | Is every input validated on the server, not only in the browser? |
| A06 Insecure Design | Business rules such as refunds, roles and limits exist only in prompts and were never written down | Where is the rule for who may do what? |
| A07 Authentication Failures | Login, session and password-reset flows generated in one pass and never tested for abuse | Is login rate-limited, and are sessions revoked on logout? |
| A08 Software or Data Integrity Failures | Webhooks accepted without verification; a build pipeline anyone on the team can change | Are webhooks verified, and who can change the pipeline? |
| A09 Security Logging and Alerting Failures | No record of who accessed which data | Would anyone notice if all customer data was downloaded last night? |
| A10 Mishandling of Exceptional Conditions | Errors that show stack traces or let a request through when a service fails | What does the app do when the database or payment provider times out? |
Two rows need their own fix guide. Keys in frontend code (A02 and A04) are covered step by step in leaked API keys. Invented package names (A03) are explained in Sunbytes’ guide to AI code review.
We’d recommend checking A01, A02 and A03 first in any AI-built product that stores real users’ data. A01 is first in the 2025 ranking, Security Misconfiguration moved from fifth place in 2021 to second, and Software Supply Chain Failures is a new 2025 category built on the former “Vulnerable and Outdated Components” (OWASP Top 10:2025).
Which security standards apply to AI-generated code?
Six documents cover the security questions an AI-built product will meet: three from OWASP for the application, one from OWASP for AI features, ISO/IEC 27001:2022 for the organisation and the NIST Secure Software Development Framework for US-style questionnaires. None of them is specific to AI-written code, and none is a law. Table 2 shows what each one gives an AI-built product and when you need it.
| Standard | What it is | What it gives an AI-built product | When you need it |
|---|---|---|---|
| OWASP Top 10:2025 | Awareness document with ten web application risk categories | A shared vocabulary for briefs, prompts and security questionnaires | From the first prototype |
| OWASP ASVS 5.0.0 | Verification standard with numbered requirements at three levels; released 30 May 2025 | Requirements a reviewer can mark pass or fail, and a pass mark you can name | When real users or customers depend on the product |
| OWASP Developer Guide | Developer guidance and checklists, including the former Secure Coding Practices checklist | A checklist for whoever writes or prompts the code | When a developer joins or takes over |
| OWASP Top 10 for LLM Applications 2025 | Ten risks for applications that call a language model | Names for prompt injection, data leakage and runaway model costs | Only if the product calls a model at runtime |
| ISO/IEC 27001:2022 Annex A 8.25–8.29 | Controls of an information security management system (ISMS) | Management-level evidence that secure development is defined, applied and tested | When a customer, tender or your own certification plan asks for it |
| NIST SP 800-218 (SSDF 1.1) and SP 800-218A | US Secure Software Development Framework (Feb 2022); 800-218A adds generative-AI practices (Jul 2024) | A practice list that many enterprise questionnaires reference | When US or enterprise customers cite SSDF |
We’d recommend the OWASP Top 10:2025 as the shared vocabulary and ASVS Level 1 as the pass mark for any AI-built product with real users. Add ISO/IEC 27001:2022 Annex A when a customer or a certification plan asks for evidence about the organisation, and add the LLM Top 10 only when the product sends user input to a model.
OWASP secure coding standards: ASVS and the Developer Guide
The OWASP document that works as a secure coding standard is the Application Security Verification Standard (ASVS). The Top 10 summarises risks; ASVS lists requirements a reviewer can mark pass or fail. ASVS 5.0.0, released on 30 May 2025, numbers every requirement as chapter.section.requirement, so a finding can point to an exact line of the standard (OWASP ASVS).
ASVS has three levels. Level 1 is the baseline every application should meet, Level 2 suits applications that handle personal or business-sensitive data, and Level 3 is for high-assurance systems. We’d recommend Level 2 for login, access control and personal-data handling once real users arrive, because one missed rule there exposes other people’s data.
How to use ASVS with AI coding tools
- Put requirement IDs into the task. Add the relevant ASVS requirement numbers to the prompt or ticket as acceptance criteria.
- Review against the IDs. Ask the reviewer to record pass, fail or not applicable per requirement ID instead of a general “looks fine”.
- Keep the result. Store the review record with its release; that record is the evidence a customer asks for.
OWASP secure coding checklist for developers
The OWASP Secure Coding Practices Quick Reference Guide, long used as a secure coding checklist, is now archived. OWASP states that its “checklists have also been migrated to the Developer Guide”, so new projects should use the OWASP Developer Guide checklists (OWASP Secure Coding Practices project page). The Developer Guide tells the person writing or prompting the code what to do; ASVS tells the reviewer what to check.
A customer asked which standard your code follows?
An AI-built product review checks the parts of your product that security questionnaires ask about — access to data, login, secrets and dependencies — and returns findings with the evidence behind each one. The review is independent from any fix work, and the results come in plain English with a prioritised action plan you can attach to your answer.
ISO 27001 secure coding: what Annex A 8.28 asks when AI writes the code
ISO/IEC 27001:2022 Annex A 8.28 “Secure coding” requires secure coding principles to be applied to software development. The control does not list code-level rules, so the organisation chooses and documents a set; a named OWASP standard such as ASVS is a common choice. Annex A 8.28 applies to AI-written code in the same way as to human-written code: the tool is not exempt, and neither is the person who accepts its output.
Two further controls decide how AI coding tools fit into an ISMS. Annex A 8.30 “Outsourced development” asks the organisation to direct, monitor and review development done outside its own team; a practical reading is to treat an AI coding tool like an outside developer whose work is specified, reviewed and approved before release. Annex A 8.4 “Access to source code” covers which code, keys and data may be pasted into an AI tool, and under which account settings.
| Annex A control | What changes when an AI tool writes the code | Evidence to keep |
|---|---|---|
| 8.25 Secure development life cycle | The development procedure names the AI tools in use and who reviews their output | Written development procedure |
| 8.26 Application security requirements | Security requirements go into prompts and tickets, for example as ASVS IDs | Tickets with requirement IDs |
| 8.27 Secure system architecture and engineering principles | Architecture choices the tool made are written down after the fact | Short architecture notes |
| 8.28 Secure coding | A named standard (for example ASVS 5.0) and a review of AI output against it | Review record per requirement |
| 8.29 Security testing in development and acceptance | Tests cover access control and abuse cases, not only “the feature works” | Test results per release |
| 8.30 Outsourced development | The AI tool is directed, monitored and reviewed like an outside developer | Review and approval records |
| 8.4 Access to source code | Rules on which code, keys and data may be shared with AI tools | Tool settings and one written rule |
An ISO 27001 certificate covers an organisation’s ISMS, not the security of a specific codebase; what ISO 27001 certification covers for app development explains what the certificate does and does not prove. When an auditor asks “which secure coding standard do you apply?”, the answer should be a document name and version — for example “OWASP ASVS 5.0.0, Level 1, Level 2 for authentication and access control” — not “best practices”.
If your app has AI features: OWASP Top 10 for LLM Applications
Products that call a language model at runtime — a chatbot, document search or an agent — need a second list: the OWASP Top 10 for LLM Applications 2025 (OWASP GenAI Security Project). The list covers features that send user input to a model, not code an AI tool wrote. Four entries matter most for a small team:
- LLM01 Prompt Injection — text from a user or a document changes the model’s instructions.
- LLM02 Sensitive Information Disclosure — the model returns data the user should not see.
- LLM06 Excessive Agency — the model can send emails, change records or call tools without limits.
- LLM10 Unbounded Consumption — no cap on requests or spend, so one user can run up the model bill.
The other six are LLM03 Supply Chain, LLM04 Data and Model Poisoning, LLM05 Improper Output Handling, LLM07 System Prompt Leakage, LLM08 Vector and Embedding Weaknesses and LLM09 Misinformation. For teams that build or adapt models, NIST SP 800-218A (July 2024) adds generative-AI practices to the SSDF. The model checks to complete before launch — least privilege, a prompt-injection test and a spend cap — are part of the production readiness checklist.
EU rules that point to these standards
No EU law names OWASP or makes ISO 27001 mandatory for an AI-built product, but three EU rules require security measures that a named standard helps you prove.
- GDPR Article 32 requires “appropriate technical and organisational measures” for personal data, and Article 25 requires data protection by design and by default. A named standard such as ASVS shows what “appropriate” meant; the Autoriteit Persoonsgegevens supervises in the Netherlands.
- NIS2 Article 21(2)(e) covers security in network and information systems acquisition, development and maintenance, including vulnerability handling. The Netherlands transposed NIS2 in the Cyberbeveiligingswet, in force since 15 August 2026 (Staatsblad 2026, 187). Companies in scope pass these duties to software suppliers by contract.
- The Cyber Resilience Act (Regulation (EU) 2024/2847) applies to products with digital elements, such as installable software and mobile apps. Its reporting obligations apply from 11 September 2026 and its main requirements from 11 December 2027. Software delivered purely as a service is generally outside its scope, unless it is remote data processing a covered product needs to work.
The EU AI Act regulates AI systems, not the code an AI tool writes for you. For a SaaS product with no NIS2 customers, GDPR Article 32 is the rule that applies first; NIS2 scope or an installable app sold in the EU adds the other two.
Which standard to start with
The right starting standard depends on who is asking and what data the product holds. Table 4 gives the starting point for six common situations of an AI-built product.
| Situation | Start with | Add when |
|---|---|---|
| Internal tool or prototype with test data | OWASP Top 10:2025 awareness, secret scanning and dependency scanning | Real users or real data arrive |
| Real users’ personal data or payments | ASVS 5.0 Level 1 everywhere; Level 2 for login, access control and data handling | A customer sends a security questionnaire |
| Enterprise customer security questionnaire | ASVS review record plus the Top 10 mapping as evidence | The customer asks for ISO 27001 or SOC 2 |
| ISO 27001-certified customer, or your own certification plan | Annex A 8.25–8.30 procedures with ASVS as the named secure coding standard | An auditor schedules a stage 1 audit |
| Product calls an AI model at runtime | OWASP Top 10 for LLM Applications 2025 on top of ASVS | Agents get permission to change data |
| Company or customer in NIS2 scope; installable app sold in the EU | NIS2 Article 21(2)(e) and CRA evidence built from the same ASVS and ISO records | CRA main obligations apply on 11 December 2027 |
We’d recommend not starting with ISO 27001 certification to answer one customer’s questionnaire. The questionnaire asks about the product, and an ASVS-based review record answers that question directly, while certification covers the whole organisation and takes an audit cycle to complete.
What evidence to show a customer or auditor
A customer or auditor accepts evidence that names the standard, shows the result and carries a date. For an AI-built product, these six records provide a practical starting evidence pack; individual customers may request additional evidence:
- Named baseline — for example “OWASP ASVS 5.0.0 Level 1, Level 2 for authentication and access control”.
- Automated results — static analysis (SAST, a scan of the source code for known weakness patterns), software composition analysis (SCA, a scan of third-party packages for known vulnerabilities) and secret scanning, all from the release the customer is evaluating.
- Human review record — who reviewed, when, and pass or fail per requirement ID; the AI code review guide explains how to run the review.
- Security test record — access-control and abuse-case tests for Annex A 8.29, including a test that one user cannot open another user’s data.
- Open findings — each with an owner and a target date.
- AI tool record — one line naming the AI coding tools used and the Annex A 8.4 rule on what may be shared with them. Team-wide rules for AI tools are covered in ai code governance.
Prototype scans remain useful historical evidence, but they do not replace checks on the release being assessed. If a record is older than the release the customer is evaluating, run the check again before you send the pack.
How Sunbytes reviews AI-built products for security questions
A security standard turns “we think the code is secure” into a list a customer can check. AI coding tools can write the code and run the scanners; a person still has to check the product against that list.
Sunbytes’ AI-built product review helps teams identify where their product’s security controls, code and technical setup need attention before launch or wider use. The review begins with an agreed scope across relevant areas of security, architecture, critical workflows, deployment and maintainability. Engineering and security findings are explained in plain English, with supporting evidence and a prioritised action plan.
When a customer requires verification against specific OWASP ASVS controls or a separate security-only assessment, those requirements should be confirmed during scoping. This keeps the evidence relevant to the customer’s question without presenting a general product review as a certification.
For a security-only check of the code itself, Sunbytes’ cybersecurity team runs a secure code review. Both services run under Sunbytes’ ISO/IEC 27001-certified information security management system and are backed by 300+ delivered projects.
If a customer questionnaire or a launch date is waiting on this answer, start with an AI-built product review.
