Handling a Security Issue: Letting AI Triage the Alert While You Judge the Real Exposure

You’re building along, things are going well, and then a warning shows up. Maybe your tools flag a vulnerability in one of the libraries your app depends on, or you get an automated email with a scary-sounding ID and the word “critical” in red. Say your app is a little booking tool for yoga studios. You paste the alert into your AI assistant and ask what to do, and it responds fast and confidently: yes, this is serious, here’s the patch, update this dependency, change this setting, here’s the fix. A minute later you’ve applied it. The red went away. You feel responsible, like you handled a real threat.

And maybe you did. Or maybe you just spent your afternoon patching a vulnerability that couldn’t touch your app in a million years, while a much quieter, much realer hole sat wide open three files away. Here’s the thing about security alerts: they come rated by how bad they could be in the worst case for anyone, not by how bad they are for you specifically. A “critical” vulnerability in a feature you don’t use is not critical to you. A “low severity” issue in the exact spot where your users type their passwords might be the thing that sinks you. The careless version of this job isn’t asking AI to help with a security alert. It’s letting the alert’s own scariness, and AI’s confident response to it, decide your priorities, so you end up reacting to the loudest warning instead of the realest risk.

What this job actually is

Handling a security issue is two jobs that get mistaken for one. The first is understanding the alert: what is this vulnerability, how does it work, where in your code does the affected thing get used, what would an attacker actually have to do to exploit it, and what’s the fix? That’s research and explanation, and AI is genuinely good at it. It can read the advisory, trace where the vulnerable library shows up in your project, explain the mechanism in plain language, and propose the patch. Handing AI the investigation is smart; it’s faster and more thorough at it than you’ll be.

The second job is judging the real exposure: given how your specific app actually works, does this vulnerability matter, how much, and how fast do you need to act? A vulnerability is only a risk if the conditions for exploiting it exist in your app. Maybe the dangerous function never runs on user input. Maybe it’s in a dev tool that never ships to production. Maybe it’s exactly the opposite, sitting right on your login flow. That’s not a research problem. It’s a judgment call about your app’s actual attack surface and what you’re protecting.

Here’s the distinction that matters: AI can generate the analysis of the vulnerability, but judging whether it’s a real threat to you is yours. A severity rating is not a priority list. The value of handling security well comes from spending your limited attention on the holes that are actually reachable in your app, and that means weighing each alert against how your product really works and what it really holds. AI can explain the vulnerability perfectly and still not know whether it’s a fire in your house or a fire on the news, because that depends on context about your app and your users that AI doesn’t have unless you give it.

How to delegate the investigation

So lean on AI for the part it does well, which is the patient investigation the alert itself doesn’t give you. The alert tells you something is wrong; it rarely tells you whether it’s wrong in a way that reaches you. That gap is exactly where AI is useful.

Give it the alert and ask it to explain the vulnerability in plain terms: what’s the actual mechanism, what would an attacker need to be able to do to exploit it, and under what conditions does it become dangerous. Then ask it to trace the thing through your own code. Where does this library or function actually get used in your app? Does it ever touch user input? Does it run in production or only in development? Is it on a path a stranger can reach, or buried somewhere only you can trigger? Ask for the patch too, and what the patch changes, and whether applying it risks breaking anything.

The move that makes this delegation good is asking AI to map the exposure conditions, not to rate the urgency. You want it to lay out clearly: here’s what would have to be true for this to hurt you. That’s the raw material you need to make the call yourself.

What you don’t do is ask “how worried should I be?” or “is this urgent?” The moment you ask that, you’ve handed back the judgment you came here to keep, and AI will usually answer by echoing the alert’s own severity rating, because that’s the safest-sounding thing to say. Keep the ask on investigation. Explain the hole, show me exactly where and whether it touches my app, tell me what an attacker would need; I’ll decide how much it matters. You want the map of the exposure. Deciding what the exposure means for you is the part you keep.

The judgment you keep

Whether this is a real threat to you, and how fast you act, is the call, and it’s yours because it turns on something AI can’t fully see: your app’s actual attack surface and what it’s actually protecting.

This is hard because the safe-feeling move is to treat every alert as urgent and patch everything immediately, and that sounds responsible. But you have limited time and attention, and spending them on vulnerabilities that can’t reach you is its own kind of failure, because it’s time you didn’t spend on the ones that can. The judgment is in looking at a genuine vulnerability, with a real severity rating attached, and deciding it doesn’t matter much for you because the conditions to exploit it don’t exist in your app, while reserving your real urgency for the holes that sit right on the paths your users and their data travel. For the yoga booking app, a flaw in an image-processing library you only use to resize studio logos is a very different thing from a flaw in how you store the credit card details people book classes with, even if the first one is rated higher.

AI can’t make this call because it doesn’t know what your app is really protecting or how exposed each part of it is. It can tell you the vulnerability is real and even where the code lives, but it can’t weigh that against the value of what’s behind the door, because that weighing depends on what your users trust you with and which paths a stranger can actually reach. Get this wrong in one direction and you burn your time chasing ghosts; get it wrong in the other and you wave off the one alert that was sitting on your front door. Knowing which is which is the entire job, and it lives with you.

Before you ship this job

Here’s what good delegation looks like, and the line it can’t cross.

The sample prompt. Something real you might send:

I’m building FlowSpot, a booking app for small yoga studios. Studio owners list classes, and students sign up and pay through the app, so we store names, emails, and process card payments through a third-party provider. I just got a security alert about a vulnerability in one of my dependencies (I’ll paste the details below). Don’t tell me how urgent it is yet. First, explain the vulnerability in plain language: what’s the actual mechanism, and what would an attacker need to be able to do to exploit it? Then trace it through FlowSpot specifically: where does this dependency get used in my code, does it ever touch user input or payment data, does it run in production or only in development, and is it on any path a logged-out stranger could reach? Finally, show me the patch and what it changes. I want to understand exactly what my exposure is so I can decide myself how much this matters and how fast I move.

[vulnerability details pasted here]

Use this and you get a clear picture of whether the hole actually reaches you. Copy it as-is and you’re assessing FlowSpot’s attack surface instead of your own, weighing exposure against payment data your app might not even store. The whole assessment only means something when it’s drawn around what your app actually holds and how your app is actually reachable, and that’s yours.

The part you can’t hand off is the verdict: whether this vulnerability is a real threat given your app’s actual attack surface and what it protects, and therefore how fast you act. That weighing is the decision, and it’s the thing the prompt above deliberately stops short of asking AI to do.

How to check AI did its part: before you accept the analysis, ask AI the one question that exposes hand-waving. Point at the vulnerable code and ask it to walk you, step by step, from a stranger on the internet to actually triggering the flaw in your app. If it can lay out a concrete, plausible path (the attacker does this, which reaches this, which runs the vulnerable thing), the exposure is real and you treat it that way. If the only honest answer is that the conditions don’t exist (the function never runs on untrusted input, or the code never ships to production), then the scary rating is mostly noise for you, and you can deprioritize it on purpose instead of by accident. A severity label you can’t trace to a real path through your own app is a label, not a threat assessment.

What you get for doing it this way

Go back to that red “critical” warning and the relief of making it go away. The difference between reacting to the alert’s scariness and judging your real exposure is the difference between a security practice that just chases whatever shouts loudest and one that spends its attention where the actual risk lives. When you let AI do the investigating and you make the call on what matters, you stop patching ghosts, you catch the quiet holes that don’t come with red text, and you build the habit of measuring threats against your app instead of against a rating someone assigned for the whole world.

AI can tell you everything about a vulnerability except the one thing that matters most: whether it can reach you. That judgment was always going to be yours, because only you know what your app is really guarding and where its doors actually are. That’s the job: let AI explain the threat, but decide for yourself whether it’s your threat.