Vibe Coding: Risks and Security Best Practices

This episode offers an extensive exploration of AI-driven code generation, known as vibe coding. This episode details how AI tools like Lovable simplify app development for both technical and non-technical users by generating code from natural language prompts. It contrasts this emerging practice with traditional software engineering and the future of AI-native development. The podcast also highlights significant cybersecurity risks associated with AI-generated code, citing reports from Veracode and Backbench that reveal a high percentage of insecure code. Finally, it provides recommendations for secure vibe coding, emphasizing human review and secure prompting techniques, and identifies new skill sets essential for the evolving landscape of AI-powered software creation.

Transcript

Copy Transcript Copied

SPEAKER_00 0:11

Hey everyone, welcome to today's episode of the Shiva Man Show. Today's topic is very interesting, something new, just like the last topic on MCP servers. Today I'm going to talk about vibe coding and associated risks. So we'll talk about the concepts of wipe coding. I'll also share some background on software engineering, how code things are developed for people who don't come from development background, then how wipe coding works, risks associated with it, and recommendations, and finally the takeaway. Okay. With that, let's get started. So last week I was going through an article where I read that this company called Lovable has crossed $100 million ARR in just eight months. So I was blown away by this fact. It's not an easy feat. 100 million ARR in eight months is just spectacular. Now then uh what I did is uh I was going through some of these similar companies, but for people who don't know, uh Lovable is an AI uh-based app development platform, and it's designed to simplify the creation of full stack web apps using like natural language prompts. And it's very popular. Uh so uh as per some of the articles, around 70,000 apps are getting created on this platform every day, and it speeds up the traditional coding process by 20 times uh for uh simple ideas or less complicated projects, right? So the essentially the theme that that I'm seeing across is uh build with AI. So companies that I work with professionally, friends in my circle, they are all telling me that their enterprises, and this is mostly software companies where I have connections, um, and some of the companies not with that are not software, software is not their primary business, but they are all experimenting with AI, or essentially build with AI is a very common common theme. In fact, some of the articles and uh podcasts uh as well as the leadership talks from various keynotes suggest that uh today at least 25 to 45, 41 percent code is AI generated, and um essentially what that means is these platforms are getting popular. Okay, and you can track this by looking at their ARR. Customers are paying, and this includes not only companies who are adopting these platforms at enterprise wide scale, but also individual developers who are using these tools for their efficiency. So that kind of gave me the idea to look into this. Um, because while new tech always comes, nobody thinks about cybersecurity as a primary use case. It is always there somewhere in the back end, and you know, we'll or we'll handle security issues when they happen. Okay, so that's a typical mindset I've heard. Now, with that, let's get into the basics of what this is. So the common term that's that's used for these kinds of platforms is called vibe coding. It's uh essentially an emerging uh software development practice that uses AI to generate functional code from natural language prompts, and it falls into two categories. So there are two categories of vibe coding tools. One is a simple uh uh AI coding tools, so essentially tools like cursor, windsurf, replate, where you give the instructions and they uh uh generate the code. Um, and then there are AI prototyping tools like lovable, bolt, and in AI coding, you have uh cursor, windsurf or replate. So in the prototyping side, what happens is you can quickly build the skeleton of the app uh from simple instructions, and so it reduces the time for uh developers as well as non-technical users. So you don't have to be a developer to create your app. Okay, that's the advantage of wipe coding. If you have an idea, if you're a teacher, for example, uh and you want to create an educational platform uh for your students for a particular topic, you can just start wipe coding and build that platform without understanding code. Okay, so it helps you build apps quickly. Okay, and that's why wipe coding and platforms who support vibe coding are getting popular. Okay, now this includes tools uh like Lovable. Uh, I've not personally worked on Lovable, I've seen how it works because I've worked on multiple such tools uh just for the sake of playing with them. I've used uh cursor, I've used uh Gemini, Canvas, similar capabilities on ChatGPT. Essentially, this is AI-based coding, I'm putting instructions, it's writing code. And I've played with Python scripts, I've played with some of the scripts uh uh on Java's side as well as uh something on stock trading. So I use a platform called TradingView, and they provide language in a format or a language called PineScript, and I've I've developed some custom indicators using that, okay. And I don't understand PineScript. So using natural language, I was able to achieve this. So non-developers like me can uh write scripts now. So that's that's very good, very helpful. Okay. Now, but to get into the cybersecurity issues of it, we have to first understand how we came to wipe coding today and where we're gonna go. So let's look into some background of software engineering. So traditional software development, it's characterized by human-centric processes. So they rely on explicit logic and structured, predictable development cycle. So human has full control over the software development cycle, developers work individually or as teams through write code. Umually, each line is debugged, and it requires extensive technical knowledge of the language and of course the problem that you're trying to solve. Okay, so this is how traditional software works. We have trained developers, thousands and millions of developers exist uh in the world right now. Now, from there, we in the last few years with uh Gen AI catching up, the world started moving towards AI augmented software engineering, and this is where wipe coding falls. And this is where you use an AI code assistant uh to generate code. Okay, and in such cases, you give a problem or a specific task, and the software like Lovable or Cloud or Gemini, they will write that code in some cases, depending on the tool, full application, and um then you can deploy that application. Okay, so this is where you are as a developer, you're taking assistance from the AI programmer, your AI co-pilot to build code. Okay, now this is the current state where which which is very popular. Now, where we are going is the AI native software engineering, which is you know which is essentially about more involved usage of AI-based tools, more towards autonomy and or semi-autonomy uh for tasks across the software development lifecycle. So AI can handle some of the tasks completely on their own, and for others, it would lead little human guidance. And this is where humans in AI will work together with humans guiding the overall process, essentially working as an orchestrators of all the tasks and AI programs, we call them agents, uh, understand what human wants to achieve, and they make it happen by translating the human intent into action. And uh typically it will be a multi-agent system, including things like uh specification agents, architecture agents, uh coding agent, testing agent deployment agent, so on and so forth, right? So, this is the future. So we started from manual coding, writing every line of piece to AI augmented, which is what we are doing today, and now slowly uh we are going towards the AI uh native software engineering. Okay, this is where I expect a lot of money going into. I'm already seeing some companies who have automated the AI-based testing and some other faces will also get uh have get to have AI, and then an orchestrator system can be created that will put all these two systems together and ensure that applications are developed in a much faster way with full software development lifecycle concepts. Okay, so this is some background on software engineering. Now, so going back to wipe coding, right? The input that the wipe coding tool takes is human language. And let's say give an instruction, create a code that fetches uh the prices for my favorite product um every time from uh from top 10 websites in the world. Okay, and I give it a list of websites. Okay, so that the coding agent or the uh wipe coding platform, it's gonna create that code, fetch all the APIs, and then um we'll generate user interface in or it will suggest, depending on what kind of prompt you have given, it might suggest to give you a user interface also. And then once the output comes back, user can redefine or look it look into what came out. If it they if you don't like something, it can keep giving inputs till the final uh outcome is liked by the user. Okay, now the thing with wipe coding is that the code is accepted without fully understanding how the code got implemented. Now that's where the issue lies. Okay, so again, reiterating user gives an input in natural language, system creates on uh the code, code is given back, and that is accepted by a user. If it works for him, who cares what's happening in the back end, right? And that's the thing that leads to all the risks that are there. Let's look at those risks. So, what I did is while I was researching this, I found out two amazing reports, one from Vera Code. Let's start with there. Uh, so this is a report called 2025 Gen AI Code Security Report. Uh, it was published by Vera Code. Uh they are into AppSec business. Again, no association, I just found them uh amazingly interested uh uh from content uh perspective on this topic. Uh so they did a study, uh, and the goal of this study was to quantify the security properties of AI generated code across a range of languages and models. And the central question that they were trying to answer is that what happens in the absence of security-specific guidance? Essentially, are the LLMs generating secure code or not? Okay, so their methodology involved uh uh a complete test set uh that had around 80 coding tasks. They use over 100 LLMs covering a wide range of model uh vendors and target applications, example general uh purpose software or creating a code for a specific task. Okay, and the goal was to assess the security properties of each model, how the security trend has evolved as the model size has changed, and have models been getting better at security over time, okay. And uh they decided they created these sets that had uh tasks to identify uh security vulnerabilities. So essentially what they did is if you give a task to the AI co-pilot or AI code generating platform, the same task can be written in a secure way or in the unsecure way. So the purpose of this test was to find out if by default, without any specific instructions, the code that gets generated is secure implementation or an insecure implementation. Okay. And what once the output came, where a code was testing the code and the model uh with their SAST uh products. Uh and SAS stands for static application security testing uh product. And uh this test focused on uh four common weakness enumerations categories. This includes SQL injection, cross-site scripting, log injection, and cryptographic algorithm implementation. And they tested it across four programming languages Java, JavaScript, Python, and C, and uh five different coding tasks instances for each combination of target CWE and programming languages were given. Okay, so for those who don't know about CWE, CWE or common weakness enumeration is a standard classification system of uh common security weakness and vulnerability. Essentially, it's a common language for describing software flaws. Okay, and uh each category of software weakness is identified by unique uh number. So, example CW79 it stands for CSS cloudside scripting, CWE 259 stands for use of hardcoded password. Okay, so if you if the software finds or the or the or a person finds this issue, they will categorize this issue in this particular category of weakness. Okay, so with that, let's go into the results. So that this particular report highlighted something uh very strange. Uh uh I was expecting it though in full honesty. Okay, so what the report says is that across all models and all tasks, only five 55% of generation tasks results in insecure code. In other words, 45% of these tasks of model introduces no security flow into the code. Okay, that's number one. Number two, larger models do not perform significantly better than smaller models, and number three, SQL perform security performance has been largely unchanged over time, even as models get better at generating syntactically correct code. So while models are getting faster, better performance-wise, security-wise, there's no change in the trend. And this caught my eye because what I was expecting is that as large companies are releasing their code generation models, they would also focus on security. But 45% is a big number. Uh now, uh, what this report also highlighted is that uh for SQL injection and cryptographic LGOs, models are performing relatively better uh over time, but for CSS and log injection models generally perform very poorly and appear to be getting worse, and it could be because the CSS and log injection are complicated problems to solve compared to SQL injection and cryptographic L GOS. And remember, they all they did not even go into all categories of CWE, they only went into uh four categories of CWE. So that was uh interesting, and essentially what it stated is that there is the there is an issue with the code. Okay. This the second uh report that I read related to this topic uh is something called as Backspench. So Back Spench um is an evaluation uh benchmark consisting of 392 tasks for testing the capabilities of LLMs to generate correct and secure backends, and it's uh jointly published by uh created by ETH Zurek, LogicStar AI, and UC Berkeley. So I found this paper on the archive site uh and their findings are similar that only 35% of the generated backend codes were both correct and insecure, and on an average, security exploits were successfully executed on more than half of the functional correct programs generated by each LM. So, what these two studies are telling us while we are generating these codes, they're still vulnerable. Okay, some of them could have very basic vulnerabilities also because you whether you take the number 35 percent or 45 percent, it's a large chunk of number. So, if we are making these companies or any person who doesn't have the development background capable to generate these applications, it's gonna leave a lot of attack surface open, which means cyber criminals, hackers, whatever you want to call them, they will be able to get into these apps, bring them down, or worse, extort. Okay, so that's a major issue. Okay, so uh so these are the problems. What are the recommendations? And that's where I um went and did some research, found an amazing paper by Cloud Security Alliance, and uh what this paper starts is some of this the best practices of application security, uh DevSecOps, uh secure SDLC, along with some things that are specific to vibe coding. So let's look into all those things high-level. So let's start with things like treat by default, treating a uh AI generated code as drafts and not pushing them into production, and human reviews are paramount, so you are using the code, but don't push into the production unless it's validated by a uh human. So mandatory code reviews for all AI generated code has to be the default principle. Okay, now I know large enterprises will comply with it, but nothing is preventing a small company or an individual developer, uh a person who's working on his own to ignore all this and just push the code because they they are eager to uh test this out in public and uh make some money off it. Okay. The second recommendation uh that uh came is of course including the security fundamentals, which is avoiding hard-coded sensitive data, securing API endpoints, validating input, configuring cross-origans researching uh properly, using HTTPS, um doing peer reviews, involving uh app sec best practices, including things from a WASP, secure coding practices like least privilege, data encryption, CICD security scanning, use SAS of DAS tools that are popular in DevOps, uh securing the code repo, security of data store or database, and then specific threats to AI in case your AI application or application has AI capabilities, so looking at OASP and agent uh LLM uh top 10, uh, and then of course the uh security of the compute hosting this uh application. Okay. Also, the best practices have to be followed from each of any of the tools that are there for uh code generation. Okay. Now, the most important thing in uh in this is ensuring that secure vibe coding is done by using prompts containing security specification. What does the art mean? An example could be instead of just writing create an endpoint, you can write create an endpoint that authenticates using an API key stored securely in an environment variable. Another example, instead of just writing create a function for specific tasks, you write create a person function for this task that validates the user input so ensure it matches a specific format or range before processing it. So you're doing the input validation tech checks. Okay. Also, uh, so depending on your background, and now it's very important to understand how security is taken care of in the vibe coding or the app sec side. It's important that you imbibe by default all those principles into our prompts. Okay, so secure wipe coding is a shared responsibility. Now, so those are the risks that I mentioned. So code is insecure, it can be hacked easily using automated tools or some of the exploits that are there. Uh, and then there are recommendations and best practices, uh, including traditional ones as well as specific to wipe coding. Now, what are the key takeaways? One, we will have new skills. Okay, from all the literature that I've read, one is thing one thing that's gonna happen is one AI PMs, AI product managers will be be the new job. These will be the people will be responsible to build AI features or use AI to focus on high-leverage tasks as well as prototype with AI. Okay, so you'll be asked to create quick prototypes without us asking the development team to go full uh on. AIPMs have to be smart enough to uh use the white coding platform uh to create the application uh that the companies want to test. The second thing that I found is the uh AI AppSec uh will be a critical uh skill set for cybersecurity folks, of course, even for developers also. So if you understand about the basics of cybersecurity, basics of development, start learning on the security side, especially uh the OAPS top 10, at least the basic uh security check hygiene that is associated with uh uh application development has to be uh learned by every developer, is what I recommend. And of course, uh lastly, the new skill will be to build secure prompts uh beyond the app second code uh recommendations of these platforms. So these are the key takeaways for me. So what I'm gonna do personally is I'm gonna uh all them testing, but uh I will start looking into learning how do I put up a secure prompt when I'm using a wipe code tool. Okay, and of course, if I can create prototypes with the tools that I have access to. With that, I'm very thankful to all the sources. This includes Cloud Security Alliance document called Secure Wipe Coding Guide, the Backsbench paper from archive.org and as well as Veracode for their recent report. Thank you. I hope you found this useful. Keep sharing, keep liking, and I'll see you guys next time.