Vibe coding security is the practice of securing software built primarily with AI coding assistants like Cursor, GitHub Copilot, and Claude Code. Because AI-generated code contains roughly 2.74 times more vulnerabilities than human-written code (AppSec Santa, 2025), vibe-coded applications require automated security scanning — SAST, SCA, and secret detection tools — to catch the flaws that AI consistently introduces.
What is vibe coding?
Vibe coding is the practice of building software by describing what you want in natural language to an AI coding assistant, then iterating through conversation until the output works. Instead of writing code line-by-line, developers prompt tools like Cursor, GitHub Copilot, Claude Code, or Windsurf and accept, reject, or refine the generated output.
The term was coined by Andrej Karpathy in early 2025. In a post on X, he described his workflow: “I just see things, say things, run things, and copy-paste things, and it mostly works.” The phrase caught on because it captured something real. Developers were already building this way. Karpathy gave it a name.
Adoption has been fast. As of early 2026, roughly 85% of professional developers use AI coding tools in some capacity. GitHub Copilot alone reports that it generates up to 46% of code in files where it is active. Cursor, Claude Code, Amazon Q Developer, and Windsurf have added millions of users. For many developers, vibe coding is not an experiment. It is the default workflow.
How vibe coding differs from traditional development
Traditional coding requires a developer to translate requirements into logic, then logic into syntax. The developer thinks about data structures, edge cases, error handling, and security at each step.
Vibe coding compresses this. The developer describes the intent. The AI generates a complete implementation. The developer tests whether it works. If it does, they move on. If it does not, they describe the problem and the AI tries again.
This changes the failure mode. In traditional development, bugs come from incorrect logic. In vibe coding, the code often works correctly for the happy path but fails on everything the developer did not explicitly describe: error handling, authentication, input validation, rate limiting. The AI gives you what you asked for. It does not give you what you forgot to ask for.
Security risks of AI-generated code
The vulnerability gap
AI-generated code contains far more security vulnerabilities than code written by experienced developers. In our research testing 6 major LLMs on 534 code samples, roughly one in four samples contained at least one confirmed vulnerability. Across multiple studies, the consensus is clear: AI-generated code introduces about 2.74 times more security flaws than human-written code.
This is not because AI models are bad at coding. They are very good at producing functional code. The problem is that functional correctness and security are different things. A login endpoint that accepts credentials and returns a token is functionally correct. A login endpoint that does those things while also rate-limiting attempts, hashing passwords with bcrypt, validating input length, and logging failed attempts is secure. AI consistently delivers the first version and skips the second.
Why AI models generate insecure code
AI coding assistants are trained on massive datasets of public code. Public code includes Stack Overflow answers, GitHub repositories, tutorials, and documentation examples. Much of this code was written to demonstrate functionality, not security. The training data is biased toward making things work, not making things safe.
Pattern matching without context is the core issue. When you ask an AI to build a REST API, it matches the pattern of thousands of REST API implementations it has seen. Most of those implementations in training data did not include authentication middleware, input sanitization, or rate limiting. The AI reproduces the statistical average, and the statistical average of public code is not security-hardened.
The “it works” trap
Vibe coding amplifies a specific human bias: when code runs and produces the expected output, developers trust it. This is the “it works” trap. The code passes the functional test. The developer moves on to the next feature.
With hand-written code, developers naturally encounter friction at each step. They think about what could go wrong because they are building the logic themselves. With AI-generated code, there is no friction. The code appears fully formed. Reviewing a 50-line function you did not write requires more discipline than writing those 50 lines yourself. Most developers do not apply that discipline consistently.
Stanford University’s 2023 study confirmed this pattern: developers using AI assistants were more likely to introduce vulnerabilities and simultaneously more confident that their code was secure. The AI does not just write insecure code. It creates a false sense of security.
Confidence without competence
AI coding assistants present output with uniform confidence. There is no hesitation before a hardcoded API key. No warning before an unparameterized SQL query. No flag on a missing authentication check. The code reads exactly the same whether it contains zero vulnerabilities or five.
This makes code review harder, not easier. A human developer writing insecure code might leave a # TODO: add auth check comment. The AI never does.
Common vulnerabilities in vibe-coded applications
Based on our AI code security research and industry findings, these are the vulnerabilities that appear most frequently in AI-generated code:
| Vulnerability | OWASP Category | Why AI introduces it | Severity |
|---|---|---|---|
| Hardcoded secrets and API keys | A07: Authentication Failures | AI copies patterns from training data that include placeholder or real credentials | Critical |
| SQL injection | A03: Injection | AI uses string concatenation instead of parameterized queries | Critical |
| Missing input validation | A03: Injection | AI focuses on the happy path and skips boundary checks | High |
| Broken authentication | A07: Authentication Failures | AI builds endpoints without auth middleware unless explicitly told | Critical |
| Missing rate limiting | A04: Insecure Design | Rate limiting is rarely demonstrated in training code samples | Medium |
| Insecure deserialization | A08: Software Integrity Failures | AI uses pickle, eval(), or JSON.parse on untrusted input | High |
| SSRF (Server-Side Request Forgery) | A10: SSRF | AI passes user-supplied URLs to HTTP clients without validation | High |
| Missing error handling | A04: Insecure Design | AI generates try/catch blocks that swallow errors or expose stack traces | Medium |
| Outdated dependencies | A06: Vulnerable Components | AI suggests dependency versions from training data, which are often outdated | High |
| Path traversal | A01: Broken Access Control | AI constructs file paths from user input without sanitization | High |
The pattern: omission, not commission
Notice the theme. Most AI security failures are things the code does not do, not things the code does wrong. The SQL query works. It just is not parameterized. The API endpoint works. It just does not check authentication. The file upload works. It just does not validate the file type.
This is why SAST tools are especially effective against AI-generated code. They are built to detect these exact patterns: missing sanitization, absent validation, insecure function calls.
How to secure vibe-coded applications
Securing vibe-coded projects requires a layered approach. No single tool or practice catches everything. The three-layer defense model covers pre-commit, CI/CD, and runtime.
Layer 1: Pre-commit (catch issues before they enter the repo)
Secrets scanning is the first line of defense. AI frequently generates code with hardcoded API keys, database passwords, and tokens. Gitleaks runs as a pre-commit hook and blocks commits that contain secrets. It takes less than five minutes to set up and catches the single most common AI coding vulnerability.
Linting with security rules adds a second check. ESLint with security plugins (for JavaScript), Pylint with Bandit integration (for Python), and similar tools flag insecure patterns before the code leaves the developer’s machine.
Pre-commit hooks are lightweight. They run in seconds. Developers get feedback immediately, while the AI-generated code is still fresh in context.
Layer 2: CI/CD pipeline (catch what slips through)
SAST scanning is essential for vibe-coded projects. Run Semgrep or SonarQube on every pull request. These tools detect injection flaws, insecure function calls, hardcoded credentials, and missing validation that made it past the pre-commit stage.
In our research, 78% of confirmed vulnerabilities in AI-generated code were caught by only one SAST tool. Running multiple scanners improves coverage. A practical setup: Semgrep for speed and custom rules, plus SonarQube for broader language coverage and code quality metrics.
SCA scanning catches vulnerable dependencies. When an AI suggests npm install express@4.17.1, that version may have known CVEs. Trivy and Snyk scan your dependency manifests and container images on every build. This matters more for vibe coding because developers are less likely to question the specific version an AI chose.
Infrastructure as code scanning applies if the AI generated Terraform, CloudFormation, or Kubernetes manifests. Tools like Checkov and Trivy catch misconfigurations before deployment.
Layer 3: Runtime (catch what testing missed)
DAST scanning tests the running application for vulnerabilities that are invisible in static code. ZAP runs automated scans against staging environments, testing for injection, authentication flaws, and security misconfigurations from the outside.
Runtime monitoring catches exploitation attempts in production. Log analysis, anomaly detection, and API monitoring create a safety net for vulnerabilities that made it through all prior layers.
Prompt engineering for security
You can reduce AI-generated vulnerabilities at the source by including security requirements in your prompts. Instead of “build me a login API,” ask for “a login API with bcrypt password hashing, rate limiting of 5 attempts per minute, parameterized SQL queries, and input validation on email and password fields.”
This does not replace automated scanning. AI still makes mistakes even with detailed instructions. But it shifts the baseline. In testing, specific security prompts reduced vulnerability rates by 30-40% compared to generic functional prompts.
Code review as the final gate
Every PR with AI-generated code should get a security-focused review. The reviewer’s job is not to check whether the code works. It is to check what the code does not do:
- Does it validate input?
- Does it check authentication and authorization?
- Does it use parameterized queries?
- Does it handle errors without leaking information?
- Does it sanitize file paths and URLs?
This checklist is short because AI omission patterns are predictable.
Recommended security tools for vibe coding
These tools address the specific vulnerability patterns that AI coding assistants introduce. All are available on AppSec Santa with detailed reviews.
| Tool | Category | What it catches | Best for |
|---|---|---|---|
| Semgrep | SAST | Injection, hardcoded secrets, insecure patterns | Fast scanning with custom rules |
| SonarQube | SAST | Code quality + security flaws across 30+ languages | Broad language coverage |
| Gitleaks | Secrets Detection | API keys, passwords, tokens in code and git history | Pre-commit hook integration |
| Trivy | SCA + IaC | Vulnerable dependencies, container misconfigs, IaC flaws | All-in-one dependency + infra scanning |
| Snyk | SCA | Known vulnerabilities in open-source dependencies | Developer-friendly SCA with fix suggestions |
| Bandit | SAST (Python) | Python-specific security issues: eval, pickle, subprocess | Python vibe coding projects |
| ZAP | DAST | Runtime vulnerabilities: injection, auth flaws, misconfigs | Free, open-source DAST scanning |
Minimum viable security stack for vibe coding
If you are starting from zero, this is the order to add tools:
- Gitleaks as a pre-commit hook. Stops hardcoded secrets. Takes five minutes to set up.
- Semgrep in your CI pipeline. Catches injection, insecure patterns, and common AI mistakes. Free tier covers most needs.
- Trivy for dependency scanning. Finds known CVEs in packages the AI chose. Runs in CI alongside Semgrep.
- ZAP against your staging environment. Tests the running application from the outside. Free and open source.
This four-tool stack covers secrets, code-level flaws, dependency vulnerabilities, and runtime issues. It can be set up in under an hour.
Browse all SAST tools and SCA tools on AppSec Santa for more options.
Vibe coding security checklist
Before you start coding
- Set up a pre-commit hook with Gitleaks to block hardcoded secrets.
- Add SAST scanning to your CI pipeline using Semgrep or SonarQube.
- Enable dependency scanning with Trivy or Snyk.
- Create a security prompt template that includes authentication, input validation, error handling, and rate limiting requirements.
- Define which modules are off-limits for AI generation: authentication logic, cryptographic operations, and access control code should be written or reviewed by a security-aware developer.
While vibe coding
- Include security requirements in every prompt. Do not assume the AI will add authentication, validation, or error handling on its own.
- Review generated code for omissions, not just correctness. Check: does it validate input? Does it check auth? Does it handle errors?
- Ask the AI to threat-model its own output. After generating code, prompt: “What security vulnerabilities exist in this code?” AI is surprisingly good at identifying flaws in code it just wrote.
- Do not accept AI-suggested dependency versions blindly. Check them against vulnerability databases or let your SCA tool handle it.
- Keep generated code in small, reviewable chunks. A 500-line AI-generated file is nearly impossible to review effectively. Break it into smaller pieces.
After code is written
- Run SAST scanning on every pull request. Block merges on critical findings.
- Run SCA scanning to check all dependencies for known vulnerabilities.
- Run DAST scanning against the deployed application in staging using ZAP.
- Conduct a security-focused code review on every PR that contains AI-generated code.
- Test authentication and authorization manually for any new endpoints. AI-generated auth logic is the highest-risk code you will encounter.
- Monitor production for unexpected behavior patterns that suggest missed vulnerabilities.
Ongoing
- Track your vulnerability rate for AI-generated versus hand-written code. This gives you data to adjust policies.
- Update SAST rules as new AI vulnerability patterns emerge. Semgrep makes custom rules easy.
- Re-scan dependencies monthly. New CVEs are published daily, and the packages your AI chose six months ago may now have known issues.
- Review the OWASP Top 10 and What is SAST? guides periodically to keep your security knowledge current.
