Vibe Coding, Copilots, and Security Drift

0:00SPEAKER_00:Let's talk about vibe coding for a second. You know the feeling. The code is flowing, the tests are passing, you and your AI assistant are on a roll. And then six weeks later, you're staring at the code thinking, why did we do it that way? That feeling that you are feeling, that's called security drift. Hi, I'm Tanya Jenka, also known as SheHacksPurple. Welcome to DevSecStation, a podcast for software developers who want to build more secure software.

0:38SPEAKER_00:In each episode, I'll share a short practical lesson about secure coding, software security, and how to build safer systems without slowing development down. You can jump in at any episode, at any time. No homework required. This episode is sponsored by MAISE. One of the biggest problems in security right now is that every vulnerability or cloud scanner says everything is critical, and honestly, no one has time for that. MAZES uses AI agents to investigate vulnerabilities in context, so you can focus on the issues that are actually exploitable in your environment and not just theoretically scary.

1:20SPEAKER_00:Their AI agents also generate and prioritize fixes that knock out multiple vulnerabilities at once, which is honestly the kind of scaling that security teams really need right now. Learn more about maze at mazehq.com slash devsec. If you use Copilot, ChatGPT, Cursor, or any AI-powered coding assistant, even occasionally, this episode is for you. I want to pause for a second and define what I mean by security drift because clarity is kindness and important.

1:55SPEAKER_00:Security drift is when software keeps functioning, but the security assumptions it was built on slowly change, without anyone explicitly choosing to change them. So the code still works, nothing's actually obviously broken, but the protections that you thought were there aren't quite the same anymore. And this doesn't come from bad decisions, this comes from convenience. AI assistants are very good at helping you move fast, but they are terrible at knowing your threat model.

2:29SPEAKER_00:They optimize for what compiles, what looks idiomatic, and what they've seen before. They do not optimize for your environment, your data sensitivity, or your risk tolerance. Essentially, they don't have any context. And that's a very normal scenario where this can happen. So imagine this: you ask your assistant to generate a helper function. It gives you something that works. Great. Later, you ask it to extend that logic and it copies a pattern from earlier.

3:05SPEAKER_00:Then someone else asks it to refactor a file and it removes a check because it looks like it's redundant. No one made a conscious decision to weaken security. It just drifted. The code still works, the tests still pass, but the authentication logic is just a little bit thinner, the validation is just a little bit looser. Maybe some of the logging disappeared. This is not necessarily an AI problem, but it is definitely a workflow problem. How do we avoid this?

3:41SPEAKER_00:The bad, but unfortunately, very common approach that I see is treating AI-generated code as correct by default. It looks clean, it compiles, it feels professional. I'm sure it's good. But AI is extremely confident even when it's wrong. And confidence does not ensure security. A better approach is reviewing AI-generated code the same way you'd review code from a teammate. And this helps. But it still assumes that reviewers remember to look for security issues every time while they're trying to move fast.

4:16SPEAKER_00:And this is where drift could potentially sneak in. The best approach is not reviewing harder, it's constraining the patterns AI is allowed to introduce. So what I mean by that is you explicitly decide which security-sensitive patterns are acceptable and you make everything else harder for it to use. In practice, this looks like a few very specific things. So you keep one or two known good examples of how your team does authentication, authorization, validation, or secret handling.

4:52SPEAKER_00:You treat those examples as the source of truth and you expect the AI-generated code to always match them. If the code does not match, it does not get merged. Not because it's bad, but it's inconsistent. And wherever possible, you back all this up with automation. So feed all of those good examples into a reg server or add it to your prompts that you work with every day. Then you add on top of that tests, linters, or static analysis that double-check those patterns so humans don't have to remember them every single time.

5:28SPEAKER_00:When AI is forced to stay inside a known pattern, it stops making security decisions on your behalf that you're not necessarily aware of. And that's how we get speed without getting security drift. If you do just one thing after this episode, please do this. Pick one place where AI writes code for you and add a guardrail. There's a manageable way that you can do this. Step one, identify where AI shows up in your workflows. Is it generating functions, tests, configurations, infrastructure as code?

6:02SPEAKER_00:Whatever it's doing. Step two, pick one security-sensitive area. Authentication, authorization, input validation, secret handling sensitive data, your choice. Step three, make a rule. AI can suggest code here, but it must be reviewed against a known secure pattern. So this could be an internal code example, a checklist item in your PR template, or a simple comment such as, was this written by an AI? If yes, was security explicitly reviewed? Step four, if you can, automate all of it.

6:44SPEAKER_00:Use a reg server, prompts, lint rules, tests, static analysis, anything that can help you catch drift. And just to be clear, we are not banning AI. We are protecting the security assumptions that your system depends on every day. Vibcoding's not bad. But speed without boundaries allows for subtle, quiet, unnoticeable changes that aren't always good. When you add secure guardrails, you keep the speed and the security. That's not us slowing down, that's us maturing.

7:23SPEAKER_00:Thanks for listening to DevSecStation. If you enjoyed this episode, please subscribe, share it with a friend, or leave a review. It helps more people discover the show. If you'd like to learn more, I'm Tanya Jenka, also known as SheHacksPurple. And I teach secure coding training for software developers. You can find me online at shehackspurple.ca. Thank you for being here.