Cloud security in the age of vibe-coded applications

Let's start with the facts. The attack surface is spreading fast. Attackers are using AI to work faster and more effectively, much to our own detriment. It's the kind of work that scales in ways manual attacks never could. But that's not even surprising anymore, we could have guessed that from the beginning. 

The other piece is that attackers have gone cloud conscious. They're moving through environments like they already know the place, utilizing the specific cloud infrastructure they've landed in and taking advantage of the uniqueness of cloud environments.

But here's the scary part. A huge share of cloud incidents come down to valid account abuse. No malware, no obvious signature. The attacker authenticates and walks in the front door with real credentials, doing things that look like normal work.

It absolutely blends in with the work that your cloud engineers are doing every day. They're hiding in plain sight.

What vibe coding leaves behind

AI is responsible for opening up endless opportunities for us. It's making us faster at our jobs, letting us take on more work and get more done in the same amount of time. For example, writing code has become more efficient and much more accessible to the masses. 

Our teams are using AI to write code (what everyone is calling vibe coding), and it's already changing the world. It's no longer a question of if we should use the advantage or not; your teams are already using it in their everyday work. Much like we did with cloud, we're watching innovation race past us without pausing to secure it, and now we need to figure out what we can do about it.

Research from the Cloud Security Alliance shows that teams are shipping three to four times more commits from developers year over year, and with that comes security findings being amplified by 10 times per developer. Again, this is something we have already guessed, and we are already talking about it. However, much of the conversation centers around vulnerabilities. Which is fair, because that same research shared that 45% of AI generated samples carry a known OWASP Top 10 flaw.

But that's the easy part. Vulnerabilities, misconfigurations and other known security flaws will show up with your classic CSPM or CNAPP scanners. The real problems are the blind spots that are constantly being multiplied by the use of AI generated code. 

With identity blast radius exploding through permissive roles and long-lived keys, we are seeing the kind of access attackers will use to gain a wider foothold or hide undetected once they are already in. And what nobody loves talking about is that vibe coded apps often need that same broad access just to work well, so locking it down is not as simple as it sounds.

On top of that, a lot of teams genuinely do not know what is being deployed anymore. Code is shipping so fast that nobody has a real inventory of what is actually out there, let alone who signed off on it.

You have two different personas to think about here. 

The first is citizen developers. Regular employees, outside of DevOps, who are being encouraged to use AI to build things, automate a workflow, spin up a quick tool. And that's great, that's exactly what this technology is for. The problem though, is that most of them have never been trained to properly code or to think about security. They don't know what a hardcoded secret looks like or what the risks would be. They don't know what overly broad access looks like or all the potential it would provide if it got in the wrong hands. They don't even know what needs to be documented or where it would go. They're not doing anything wrong. They just don't know what to look for.

The second group is your experienced developers, and their risk looks different. They're using AI to write code faster, which is great too, that's the whole point. But if you don't have time to write the code yourself, you probably don't have time to read every line that got generated and double check, triple check, or verify dependencies and permissions either. All of that takes time that the speed gain was supposed to hand back.

Either way, you are introducing blind spots. One group doesn't know what to check for. The other doesn't have time to check at all.

Vibe coding expands what you trust

AI generated tooling tends to go one of two ways. It can hide inside something you already trust; your existing pipeline, approved runtime, an approved image. Or it becomes newly trusted on its own; a new proxy, an MCP server, an agent quietly performing tasks no one explicitly reviewed. All of it gets allowlisted because it works well, so why would anybody object? 

None of it gets documented either. AI built it, and AI does not update your asset list, your risk register, or anything else you rely on to track what you have actively running. Either way, your trusted surface just grew, and you cannot review what you did not know you had.

The worst part is that exact pattern is being used by some of the most notorious cyber criminal groups. According to a joint advisory released by the FBI and CISA, Scattered Spider leans on trusted remote access tools already sitting in the environment, tunneling traffic past perimeter defenses, using tools built for remote support to take control of a device. All legitimate software, doing exactly what it was built to do. Living off the land means using allowlisted tools so nothing looks out of place, then moving through the environment looking like everyone else, eventually exfiltrating your data without leaving a trace. 

So on one hand, it could be your employees moving fast on a Tuesday, or it could be a named criminal group using the exact same tools.  

The controls have to move to runtime

And this is why we need to shift our cloud security strategy.

Shift left has always been the ideal. Move control to the very start of the pipeline. Control what developers can even push. Scan for vulnerabilities and misconfigurations before any of it hits the cloud. None of that stops being true.

But we are also hearing the same message from our respective leadership teams: we need to innovate! So we cannot slow down. But remember, three to four times more commits. Ten times the security findings per developer. We don't have the time to remediate everything before it hits production. 

Shift left is not wrong, in fact it's still ideal. But the controls need to supplement those missteps that are bound to get through the cracks, and move to where the risk actually shows up. We need to start watching the runtime, understanding behavior so we can identify any anomalies, watch how identities move and start limiting the excessive access that is being handed out. 

This on top of your existing proactive cloud security understanding; control plane signals, identity signals, workload signals, all resolving to a single incident instead of scattered across a dozen dashboards. You still need that traditional context, we just need better analysis on top of it. 

This is what cloud detection and response is built for.

Detection and response: watching, and acting

The cloud security market has made a clear shift over the past couple of years. New startups are popping up left and right with runtime detection as their main focus, sometimes their only focus. The major players are moving the same direction, pouring large investment into runtime sensors, automated remediation, all of it. 

Everything we just went over reflects exactly why this is happening, and why it's the right move. 

Now, we can watch runtime for actual behavior, watch how identities move, limit the excessive access that keeps getting handed out. And keep it all in one place, because we still need the context from the cloud scanners we already run. We just need to get better at reading what that access is actually doing.

And the part that matters most? Detection and response does not just tell you something is wrong. It lets you act on it. Kill the process. Pull the host off the network. Whatever it takes to stop the behavior from continuing while your security engineers work out what actually happened.

Vibe coding is not going away, and neither is the pressure it puts on all of us. Code will keep shipping faster than anyone can fully review. The answer is not trying to out review the volume. It is making sure something is watching the runtime, ready to act the moment it needs to.

If you would like to learn more about this strategy behind this shift or about who the new and existing players are in this market, do not hesitate to reach out.