Security testing for vibe-coded applications: what changes when AI writes the code
Security testing for vibe-coded applications: what changes when AI writes the code
In 2026, a growing number of product features ship without a human reading every line of the code that implements them. A product manager describes what they want to Claude Code or Cursor. The agent writes the feature, runs the tests, and opens a pull request. A reviewer glances at the diff and merges it. The feature ships.
This is vibe coding. It is not a joke. It is how significant portions of real products are now built, and the people doing it ship faster than teams that do not.
The problem: the code that ships looks correct to a human reviewer, passes its own unit tests, and still contains a class of defects that traditional QA has never encountered at this scale. If your testing process was designed around "the developer knows what the code does", you are about to learn new failure modes the hard way.
What actually changes in a vibe-coded application
Three things shift at once.
Velocity goes up 10x. A feature that used to take a senior engineer three days takes an AI-assisted one three hours. Teams that used to ship weekly now ship daily. The old "manual QA pass before release" rhythm stops working when releases are every few hours.
Code review becomes shallow. When an engineer writes 500 lines of Rust, they understand every branch. When they accept 500 lines of AI-generated Rust, they usually read the diff, nod at the happy path, and trust the tests. Subtle bugs in error handling, race conditions, and edge cases now sail through review (a web security checklist run by hand on each release catches much of what slips past).
The failure profile is different. Human engineers miss boundary conditions. AI assistants miss them too, but they also confidently hallucinate library APIs that do not exist, invent security assumptions, and write code that is convincing but subtly wrong. The bugs look smart.
These are not hypothetical. Teams that have adopted vibe coding are already reporting the new failure modes.
The top security failure modes in vibe-coded code
1. Hallucinated dependencies
An AI assistant suggests a Python library called secure-input-validator that does not actually exist on PyPI. A developer accepts the suggestion, runs pip install secure-input-validator, and it succeeds. But now they have installed a real package uploaded by an attacker who watches the suggestion output of popular coding assistants and registers the names. This is the dependency confusion attack, and vibe coding makes it far more common.
2. Silent try/except blocks
Ask an AI to make a function "safer" and you frequently get a try/except block around the whole thing that swallows every error. The code no longer crashes. It also no longer works. Errors that should have been logged, alerted, and fixed now just return None silently. Traditional unit tests pass because they only check happy paths.
3. Unsafe defaults
AI assistants default to what is convenient, not what is safe. "Set up a new SQLite database" produces a file with permissions 0644 instead of 0600. "Generate a random password" produces 8 characters instead of 20. "Add a rate limiter" produces a per-process in-memory counter instead of a shared store. Each one looks correct until you ask the question the AI did not think of.
4. Missing authorization checks
An AI asked to "add an endpoint to fetch user data" will authenticate the request but often forget to check that the authenticated user is allowed to fetch that specific user's data. This is broken object-level authorization, OWASP API #1, and it is now being written into production code by the thousand.
5. Prompt injection in meta
If the vibe-coded code itself calls an LLM, the developer may not realize they just introduced a prompt injection surface. The AI writes a function that takes user input and sends it to Claude for summarization. Nobody tests what happens when the input contains "Ignore previous instructions".
6. Secrets in the agent's context
A coding assistant with access to a repo's environment variables or secrets manager can leak those secrets into code it writes if the prompt is not careful. An AI assistant that reads .env.local and then writes a config file may write a real secret into a committed example.
7. Silent data loss
Ask an AI to "clean up this database migration" and you sometimes get a DROP TABLE followed by a CREATE TABLE that looks equivalent but is missing a column. The data is gone. The tests pass because the tests never check for column completeness against the old schema.
What QA has to do differently
You cannot catch all of the above with the test suite the AI assistant wrote. The AI is the thing that made the bugs. Asking it to test its own work catches only the categories it already thinks about.
Add an independent test layer. Tests must come from a source that did not write the code. That can be a human QA engineer, a different AI instance given only the spec (not the code), or an external QA team with no visibility into the implementation. The key property is independence.
Test the failure modes the AI does not care about. The categories above are the test plan. For every feature, ask: does it check authorization for the specific resource? Does it validate inputs? Does it fail loudly when things go wrong? Does it use secure defaults? Does it handle partial failures? Those are the questions the AI does not ask itself.
Run security scanners on every commit. SAST tools like BugBoard's integrated security checks catch the common patterns. SCA tools like Trivy catch known-vulnerable dependencies. Secret scanners catch accidental commits. These are not optional when code review is shallow.
Fuzz the AI integration points. If the vibe-coded feature calls an LLM, it has prompt injection surface by default. Test it the way you would test any untrusted input: with hundreds of adversarial payloads.
Measure the velocity tax. Track how many of your production incidents are traceable to AI-generated code. If the ratio is above 30%, your QA process has not caught up with your development velocity and you need to either slow down development or speed up QA.
How BetterQA approaches vibe-coded codebases
BetterQA has been testing AI-assisted codebases since 2024. The approach:
Engineers with no prior context. Our QA engineers review code they did not write and did not see being written. Independence catches things the original author and their AI assistant both missed.
Security-first review. Every PR is scanned for the seven failure modes above before functional review begins. Most teams catch functional bugs and miss security ones. We flip the order.
AI assistant audit. For teams using Cursor, Claude Code, or similar tools, we audit the prompts being used and the tool permissions granted to the assistant. The biggest attack surface is often the assistant itself, not the code it writes.
Real incident patterns. Our engineers have seen what breaks in production across dozens of AI-assisted codebases. That pattern library catches issues that would otherwise surface as Tuesday afternoon outages.
The core insight: when development velocity goes up 10x, QA is no longer a bottleneck you can remove. It is the only remaining layer that prevents the 10x bug surface from becoming a 10x outage surface.
The new QA rhythm
The old rhythm: feature ships on Friday, QA starts Monday, bugs surface by Wednesday, fix and re-release. That rhythm assumed releases were slow enough that QA could run in parallel.
The new rhythm has three layers:
Layer 1, inline: security scanners, linters, and test generators run on every PR. Machine-fast, catches common patterns.
Layer 2, daily: a QA engineer or agent reviews every merged PR within 24 hours. Focused on the seven failure modes, not general functionality.
Layer 3, weekly: deeper audit of any feature that touches authentication, authorization, payments, or external integrations.
BugBoard helps teams organize this flow. Layer 1 failures become test cases automatically. Layer 2 findings are tracked as bugs with AI-assisted triage. Layer 3 audits use the AI test plan generator to cover every scenario before release.
Summary
Vibe coding is not going away. Teams that have tried it do not go back. The challenge is that the traditional QA process was built around code review that understood every line. That assumption is broken in 2026.
The fix is not to slow down development. The fix is to accept that QA now does the job code review used to do, and to run QA at the same velocity as development. Tools like BugBoard make this feasible. Services like BetterQA make it reliable for teams that cannot afford to learn the hard way.
If you are shipping AI-generated code and not catching the seven failure modes above, your current incident rate is probably hiding the ones you have not detected yet.