Everyone Is a Developer Now. That's Your New Attack Surface.

Underneath that sits a more dangerous assumption: that code written by an AI is secure because a capable model wrote it. It is not. AI-generated code is not secure by default, it is not secure on average, and it does not get secure just because the model got bigger. That belief is the load-bearing myth of vibe coding, and every pain point below rests on it.

The instinct is to treat this as a tooling story: better AI, better code, problem solved. It is not. The problem is not the quality of any single generated function. It is that application creation has moved to people who were never in the security loop, trusting output that was never trustworthy by default, at a volume no security team was staffed to review. The attack surface did not grow. It changed shape.

The attack surface went vertical

For most of software's history, the number of people who could ship a working application was small and known. Security's operating model assumed exactly that: a finite set of engineering teams, a shared lifecycle, and a review gate everyone eventually passed through.

That assumption is gone. Gartner projects that 70% of new applications will be built with low-code and no-code technology, up from less than 25% in 2020, and that citizen developers now outnumber professional developers by roughly four to one inside large enterprises. Vibe coding, the term Andrej Karpathy coined in early 2025 and which Collins named its word of the year, pushed that curve further and lowered the floor to zero. You no longer need a low-code platform. You need a chat box.

The result is not incrementally more code from the same teams. It is a different population of builders entirely, shipping to production and to internal environments in parallel, without ever entering the pipeline security was designed to watch. When Karpathy described the practice, he was candid about the workflow: "I 'Accept All' always, I don't read the diffs anymore." That is the honest default. And it is the root of five distinct pain points that are already landing on security teams.

Pain point 1: the builder cannot see the vulnerability

A professional developer who introduces an IDOR or a missing authorization check has at least a chance of recognizing it, because they know the failure class exists. A marketing analyst shipping an internal dashboard does not. Injection, server-side request forgery, broken object-level authorization, and insecure direct object references are not concepts they have ever had to hold. The vulnerability is not hidden from them. It is invisible to them.

Worse, the tool actively suppresses the instinct to check. In a controlled Stanford study, "Do Users Write More Insecure Code with AI Assistants?", participants with an AI assistant wrote significantly less secure code than those without one, and were more likely to believe their code was secure. The confidence and the security move in opposite directions. The person least equipped to catch the flaw is also the person most sure there is not one.

Pain point 2: AI-generated code is not secure by default

The most consequential misconception in this whole shift is the belief that code an AI writes is safe because the AI is sophisticated. Fluent, well-structured, confidently-explained output reads as trustworthy. It is not the same thing as secure, and the gap is measurable.

This is not a matter of one bad model or one careless prompt. In Veracode's 2025 GenAI Code Security Report, which analyzed code generated by more than 100 large language models across Java, JavaScript, Python, and C#, AI-generated code introduced risky security flaws in 45% of tests. Nearly half. And the report's uncomfortable conclusion is that larger and newer models did not improve the security outcome, so this does not resolve itself as the technology advances. It is a systemic property of how these systems generate code, not a bug that the next release quietly fixes.

Now combine that 45% with "accept all, don't read the diffs." Insecure-by-default output meets a workflow with no review step. In a traditional team, code review and an AppSec gate are the compensating controls that catch a fraction of those flaws. In vibe coding, both controls are absent by design. The insecure code does not get caught. It gets deployed.

Pain point 3: these applications are invisible

Security cannot protect what it cannot see, and vibe-coded applications are built specifically to skip the steps that would make them visible. There is no design review, no repository the AppSec team watches, no change ticket, no line item in an inventory. An internal tool goes from idea to running URL in an afternoon, and the first time security hears about it is during an incident, if at all.

Part of why is that the builder has no idea the visibility was ever their responsibility. A non-traditional developer has most likely never heard of an API specification, does not know their application exposes one, and could not tell you which endpoints it stands up. The single artifact that would let security inventory and test the app, a spec of its API surface, is something the person who built it cannot produce and does not know exists. You cannot ask someone to document an attack surface they do not know they created.

This is the shadow application problem, and it is worse than classic shadow IT because the shadow is now something the organization built itself, not a SaaS product someone expensed. It also dismantles the comforting idea that internal applications are lower risk. An internal-only app that queries a customer database is not safe because it is internal. It is exposed to every credential, every insider, and every attacker who reaches the internal network, and it was built by someone who did not know to ask whether it should authorize the request.

Pain point 4: nobody owns the lifecycle

A vibe-coded application is often born without an owner, and it stays that way. Ask who patches the app a product manager built six months ago and the answer is usually silence. The dependencies it pulled in on day one will never be updated. The API key the model hardcoded to make the demo work is still there. The person who built it has moved on to the next thing, or out of the role entirely.

Traditional software carries an implicit maintenance contract: a team, a backlog, a patch cadence. Vibe-coded software frequently carries none of that. It is treated as a finished artifact the moment it works, when in security terms it is a liability that ages badly. Every one of these orphaned applications is a small, permanent, unmonitored piece of attack surface that will still be running, and still vulnerable, long after everyone has forgotten it exists.

Pain point 5: real data behind naive authentication

The applications that create the most risk are not the throwaway experiments. They are the useful ones: the internal portal, the customer-facing form, the automation that touches a production system. These get wired to real data, and authentication and authorization are exactly the parts an AI assistant tends to stub out or oversimplify to get to a working state.

The pattern is predictable. Authorization checks that trust a client-supplied identifier. Endpoints that return any record if you change the number in the URL. Secrets embedded in front-end code because that was the path of least resistance to a running app. Each of these is a well-understood, high-severity failure class, and each is trivially likely in code written by someone who does not know the class exists, generated by a model that produces it 45% of the time.

Why the old AppSec model cannot absorb this

Every pain point above lands on a security function whose review model quietly assumed the old world. Manual AppSec review, threat modeling sessions, and a human gate before release all scale with headcount, and they were sized for a handful of engineering teams. They cannot be sized for the entire company.

The failure mode this pushes teams toward is the department of no: block the tools, forbid the practice, force everything back through the gate. That does not work, and it is not even desirable. The productivity gain is real, the business wants it, and prohibition just drives the building further into the shadows where security has even less visibility. The volume is not going back down.

So the honest problem statement is not "how do we stop vibe coding." It is "how does security operate when the people writing code cannot evaluate it, the tools generate flaws by default, and the applications never announce themselves." That is a different question than AppSec has been answering, and it does not have a headcount answer.

What actually has to change

If the builders cannot see the vulnerabilities and will not slow down, the security check has to meet the application where it now gets created, and it has to speak in evidence rather than in expertise the builder does not have. A finding is only useful here if it points at the exact request that failed and the exact line of code responsible, because that is the only form an outcome that a non-expert, or an AI agent acting on their behalf, can actually act on. Determinism on the finding, agents on the fix, a human on the merge.

How NightVision solves this

This is the problem NightVision was built for, and it solves it in two moves, not one.

First, API eNVy reads the application's source code and builds a complete map of its API: every endpoint, including the ones nobody documented and a crawler would never reach, along with how each one is meant to be authenticated. Then the DAST engine takes that full surface and exercises it against the running application, logged in as a real user, and confirms what is genuinely exploitable, with proof. Source discovery tells you where to look. Runtime testing tells you what is real. For code no one reviewed, you need both halves: the source side finds the attack surface the builder never knew they created, and the runtime side proves which parts of it an attacker can actually reach.

Because the runtime test assesses the application the way an attacker would, it works regardless of who wrote the code, what tool generated it, or whether a single line was ever reviewed. It does not care that a marketing analyst vibe-coded the app instead of a senior engineer. It cares whether the app is exploitable, and it proves the answer. That is what makes NightVision fit this world, where the code is a black box even to the person who shipped it. Map it back to the five pain points:

• Findings a non-expert can actually act on. Most tools hand back a vulnerability class and a confidence score, and leave someone to go investigate. NightVision hands back the exact request that triggered the issue and the source line responsible. The builder never has to learn what an IDOR is. They get the endpoint, the proof it is real, and the one line to change. That turns a finding into a fix instead of a research project. (pain point 1)
• The review step that vibe coding deleted. Code review and an AppSec gate are the controls that "accept all, don't read the diffs" removes. NightVision puts one back, without slowing anyone down. It exercises the live application for the OWASP-class flaws AI generates by default, injection, SSRF, broken authorization, and returns them as proven, reproducible evidence, not a maybe. The 45% that shipped unreviewed finally gets looked at. (pain point 2)
• It sees the apps and endpoints nobody told you about, and inventories them. You cannot test what you cannot find, and vibe-coded apps are built to stay off the radar. This is where API eNVy earns its keep: it derives the API surface directly from source, so it reaches endpoints a crawler never links to and no one ever documented, the shadow attack surface these applications quietly create. A hand-maintained Swagger doc is fiction the moment the app changes; a spec built from the code is not. Run it across the application estate and the security team finally has the thing it never had: a living inventory of every API in every app, built from the code rather than from what people remembered to write down. Point it at your own environment and CI, and internal tools land in that inventory alongside public ones, not in a blind spot. That is the difference between hoping you know your attack surface and having it enumerated. (pain point 3)
• Findings that get owned, fixed, and verified. An orphaned app is dangerous because nothing forces the loop to close. Because API eNVy already ties each finding back to its source line, a finding becomes an assignable, trackable piece of work, and a rescan confirms the fix actually held instead of taking someone's word for it. From that same source mapping, NightVision can draft the remediation pull request for the builder, so they are handed a proposed fix, not just a problem. A human still approves the merge. (pain point 4)
• Authenticated testing against the auth that is actually broken. The highest-risk flaws live behind the login, in the authorization logic AI assistants tend to stub out. NightVision logs in the way a real user does and tests from inside the authenticated session, which is exactly where broken object-level access, privilege escalation, and exposed data hide. Scanning the front door was never the point. (pain point 5)

Here is the part that matters most for where software is going. NightVision runs as a server an AI coding agent can call directly, so both halves, API eNVy's source discovery and the runtime proof, live in the same loop that built the application. The agent that generated the app can hand it to NightVision, get back the full API map and the source-linked findings, and draft the fix, with a person still approving what merges. Bake that into how your teams build and every AI-generated app gets its attack surface mapped and tested before it ships, by default, without adding a single step to anyone's day. That is how security keeps pace with a company where everyone is a developer: determinism on the finding, agents on the fix, humans on the merge. You do not have to turn your builders into AppSec engineers. You just have to meet them where they build.

Frequently asked questions

What is vibe coding?

Vibe coding is writing software by describing what you want to an AI in natural language and using what it produces, often without reading or reviewing the generated code. The term was coined by Andrej Karpathy in early 2025.

Why is vibe coding a security risk?

Two effects stack. The people doing it are frequently not developers and cannot recognize a vulnerability, and the AI generates insecure code at a high, consistent rate. Veracode found AI-generated code introduced security flaws in 45% of tests. With no review step, that code ships.

Are internal applications actually a concern?

Yes. An internal application that touches customer or employee data is exposed to insiders, stolen credentials, and any attacker who reaches the internal network. "Internal only" describes network placement, not safety, and these apps are often built with the weakest authorization.

Isn't better AI going to fix this?

The evidence says no. Veracode's report found that larger and newer models did not improve security outcomes, indicating a systemic issue rather than one the next model release resolves.

Why can't we just require security review for these apps?

Manual review scales with headcount and was sized for a small number of engineering teams. It cannot be sized for a workforce where citizen developers outnumber professional developers roughly four to one, and most vibe-coded apps never enter the pipeline in the first place.

What does a security check for vibe-coded apps need to do?

Meet the application where it is built, exercise it while it runs, and return evidence specific enough to act on without security expertise: the exact failing request and the source line responsible, so a person or an agent can fix and verify it.

See what your vibe-coded apps expose

Everyone became a developer. The security check has to meet them where they build. NightVision maps your API surface from source, tests the running application for real vulnerabilities, and anchors every finding to the line that caused it, so a person or an agent can fix it. NightVision is SOC 2 Type II attested; report available under NDA.