Take your medicine

Whoever said AI wasn’t good for your health clearly wasn’t drinking enough of the kool-aid. But I think it’s important to note that because of how these models work, it’s very easy to almost become gaslighted with their output and trust everything they’re saying actually is correct and working in your favor.

So how can it all begin to go wrong? I think what’s very interesting with the speed of these models developing and the applications that surround these models, one of the scariest things that someone can come up to say to me when they’re asking for advice is, hey, Ahmed, I’ve vibe coded my own app. And this is where the danger really begins.

Which rabbit hole do you pick

A recurring pattern in the blogs that I write, I always talk about how important it is to set up one’s foundation. Because once you have an understanding of how this thing is going to run in production with real users and real risks and real attacks with real data, then you can be ready for pretty much anything. However, when people are developing at the speed of thought, coupled with the enthusiastic nature of these coding agents telling you that you’re always right or you’re absolutely right or whatever, very quickly our endorphins can send us down a path of deciding which poison we pick in order to vibe our V1.

Often people will mistake speed with complexity, but what they end up doing instead is creating complexity out of the box because they haven’t set assumptions for how security is going to run, how the system is going to build, or how it’s going to then be deployed onto the final platform that’s going to run the system. And this is where they can fall into many rabbit holes of despair.

Now, of course, it’s very easy to say, hey, this is my V1. It’s not for production. I’m just using it as a way to test the market. And that’s completely fine. But what people then need to appreciate is just as fast as it took you to get that V1, it should also be just as fast to tear it down and then build up the V2 from a stronger foundation.

Typically, I see the rabbit holes and the way that people navigate the rabbit holes almost like a golfer, a high handicap golfer, like myself. Now, I’m sitting there staring at a simple chip onto the green, but the green has greenside bunkers. There’s a water feature in front of me. There’s tall trees and I’m in the rough. Now, of course, I’ve played this shot several times. I know how this thing goes, so I absolutely yeet it. And then guess what? I hit a trap and I have to take my medicine.

Fighting gravity

Remember, the moment your thing goes live, it’s going to be hit with threats. And it’s almost like you’re fighting gravity all the time. So one of the key aspects is to think about how your thing is going to run operationally. What this means in practice is what happens when something goes wrong at 3 a.m.? What happens when something goes wrong when you’re on holiday? What happens when something goes wrong and you’ve run out of tokens?

And obviously, there is a wide range of things that could go wrong, from the actual application code itself, all the way to infrastructure misconfiguration, state issues, for example, your database runs out of space, to permissions issues. And this is where it can become really tricky.

This is a favorite subject of mine because one thing I see quite often is people will show how well authenticated their application is for users, but they will take a somewhat lazy approach to providing the permissions that their applications need. And this could be as simple as having overly permissive database users that the application uses, all the way to having overly permissive IAM policies on AWS. And this is a fight that you can’t fight for too long.

If we consider the most common hacks on cloud infrastructure are generally to access some sort of credential that can then be used to spin up more infrastructure to mine bitcoins or run botnets or whatever. So it always, always frustrates me when I see people deploying overly permissive applications to the cloud that with one slip up could lead to an incredibly high cloud bill.

Gravity always wins

What I ask customers to do, and friends and family, when they’re vibing away at the frontier, is to make sure they add into their workflow a simple check before every commit. Let’s look at what APIs or systems or access my application really needs and trim down my policies, my controls, my IAM, whatever it may be, to make sure that the application has the bare minimum access it needs. And in case that access ever slips into the wrong hands, the blast radius is controlled.

And there are common controls we have to think about and how we verify these controls as well. These could be as simple as file permissions that are deployed onto our LAMP PHP server to make sure that no one can upload and then execute executable scripts, all the way to making sure that the database user for our application has simple CRUD permissions and doesn’t have the ability to delete databases, create databases, or adjust any of the actual system settings in the database itself.

One of the interesting and most common ones that I see is user authentication, especially when it comes to JWT. Now, one can be forgiven in trying to understand all of the RFC complexities when it comes to JWT tokens. But again, as fast as your agent has coded that application for you, it’s actually very important that the application implements your user authentication properly for you.

I bring this up because I see this really is a common vulnerability that customers have. I mean, yes, of course, it’s very simple for someone to deploy a very simple and basic authentication system, but not actually set the routes to require authentication as they’re accessed. We’ve all been there. But it’s something else to assume that your authentication system has been set up correctly and is using standards like JWT and it’s being stored in correct fashion, such as HTTP only cookies, for example, secure transport, etc. Only to find out that your system is not correctly validating the JWT token and potentially allowing anyone with a similar signature or a similar JWT token setup to come in and go about their business.

The crash landing

Things can come to a head very quickly if your authentication or security systems are messed up. But when you have customer data in there and you haven’t fully appreciated all of the legalities, well, depending on your locale, maybe for customer data being leaked, things can come crashing down very, very quickly.

So how do we avoid this? How do we make sure that the applications we’re developing are actually secure, are actually properly permissioned, so we don’t have to take our medicine when issues occur, especially at an operational level? Well, I think it always comes down to that foundational piece. These models are very, very good when they’re given a brief at the start. Sometimes we have to accept that they will gaslight us in letting us know or letting us think that we know what we’re doing. But we always have to constantly doubt ourselves, always have to constantly assume that these models are taking the lazy route, which they most probably are.

So build your checklist. Reiterate your checklist. Before your deployments, make sure you’re validating that checklist. And then over time, as you’re maturing your development process, your deployment process, etc., that checklist should naturally form into a set of features. Those features should then naturally form into a set of test suites. And very quickly, those test suites will mature into unit tests and potentially E2E tests. And all of this helps control the guidance that your application will use, the way that it understands what the functional and non-functional requirements of your application are, and then hopefully ensure that you don’t have to always take your medicine.

And of course, I’m speaking from experience here. We’ve all been that young buck who never took notice of the product owner’s requirement gathering sessions and just YOLO’d their way into failure. Don’t be like me.