Which security bug should you actually worry about first?

Imagine your security scanner hands you a list of 50 problems. Each one says: "this is bad,
it's in this file, on this line." But it never tells you the thing that actually matters:
if someone exploited this, how much of your app would break — and whose job is it to fix it?

Here's the catch. A scanner rates a bug in some forgotten, unused file exactly the same as the
same bug sitting in the login code that half your app depends on. Same label, wildly different
danger. So teams waste time on the harmless ones and sometimes miss the scary one.

For the GitLab Transcend Hackathon, I built a little assistant to fix that. It's called
Vulnerability Blast Radius.

What it does, in plain words

Think of it like this: when a bug is found, the tool doesn't just shrug and show you the line.
It asks a simple question — "what else in the code touches this?" — and follows the trail.

1. It finds the security bug.
2. It maps the "blast radius": which other parts of the code call or rely on the broken file. (This is the clever part — it uses GitLab's "knowledge graph," basically a map of how all the code connects.)
3. It gives it a score from 0 to 100, so the genuinely dangerous bugs float to the top.
4. It finds the right owner (the team responsible for that code).
5. It writes a tidy note suggesting what to do — but it only suggests. A human always decides.

A real example from the demo: one bug turned out to have 11 other files depending on it → it
scored 96/100 (Critical) → and got routed straight to the security team. That's the difference
between "a bug somewhere" and "a bug that can really hurt you."

The part I'm most proud of: it doesn't make things up

AI tools can be confidently wrong. So I made a deliberate choice: the score is calculated by
plain, predictable code — not by the AI. Same bug in, same number out, every single time. You
can check the math yourself:

Severity (critical)        40
Likelihood of exploit      16
Known to be exploited?     15
Is the code reachable?     10
How much depends on it     15
───────────────────────────────
                           96 / 100

And if the tool doesn't have real data yet, it says so honestly and leaves blanks — it never
invents a number to look smart. It also asks permission before changing anything, and won't post
the same note twice. Trustworthy beats flashy.

The funny twist

When I ran it for real, the very first bug it caught… was a small mistake in my own demo code.
Honestly? That's the best possible advertisement. It works on real problems, not just neat examples.

A peek behind the curtain (for the curious)

GitLab's knowledge graph is brand new, so the docs didn't always match reality. The most useful
lesson of the whole project: check what the system actually does, don't trust the example. A
couple of surprises only showed up when I tested against the live system — like the fact that the
"link" I expected between a bug and its file simply didn't exist, so I had to find another way in.
Little things like that would have quietly broken everything if I'd trusted the manual.

The result: it's open-source (MIT), backed by 94 automated tests, and published as a reusable
agent on GitLab's AI Catalog.

Have a look

• 🎥 2-minute demo: https://youtu.be/cEhLA04SV2c
• 📦 Code (free, MIT): https://gitlab.com/gitlab-ai-hackathon/transcend/7723089
• 🤖 The agent: https://gitlab.com/explore/ai-catalog/agents/1011711/

The big idea is simple: a security finding shouldn't just tell you what's wrong — it should tell
you how much it matters and who can fix it. Now it can.