Vulnerability Graph, Explained

A plain-language guide to how Yuzu finds the vulnerabilities that actually matter

No technical background needed. If you’re curious about why we keep talking about “graphs” and “attack paths,” this is the document for you. It’s the friendly companion to the engineering design in vuln-scan-engine-design.md; you can read this one on its own.

The problem: drowning in a list

Every tool that scans computers for security weaknesses produces the same thing — a list. A very, very long list. A medium-sized company might get back tens of thousands of entries: this program is out of date, that one has a known flaw, this setting is risky.

To help you cope, each item comes with a severity score from 1 to 10. So you sort the list by severity, start at the top, and begin fixing. Sensible, right?

Here’s the trouble. That severity score answers only one question: “How bad is this flaw in the abstract?” It says nothing about a far more important question: “How bad is this flaw for us, right here?”

A “critical, 9.8” flaw on a machine that sits in a locked closet, that nothing else can reach, that holds nothing valuable, is — in real life — not very dangerous at all. And a “medium, 5.5” flaw on a machine that an outsider can touch, and that can in turn reach the database holding all your customers’ money, might be the most dangerous thing you own.

The list can’t tell the difference. It treats every machine as an island. So teams end up patching the loudest thing instead of the most dangerous thing, and the truly scary problems hide in plain sight, halfway down a list of ten thousand.

A better question

Imagine your company’s computers as rooms in a large building. (Really, each program running on a machine is its own little room — but picture one room per machine for now.)

A security flaw is like a faulty lock on one of those rooms. The severity score is just how easy that particular lock is to pick.

But a burglar doesn’t care only about lock difficulty. A burglar cares about getting from the street to the vault. A picked lock on a 40th-floor room with no stairs leading anywhere is useless to them. A slightly tougher lock on the room next to the vault, in a hallway that connects straight to the front door — that’s the one they want.

So the question that actually keeps a security team up at night isn’t “Which of my locks are weakest?” It’s:

“If someone broke in through a door, could they make their way — room by room — to something I truly care about? And if so, how?”

That is a question about how the rooms connect. And a plain list of rooms, no matter how well sorted, simply cannot answer a question about connections. For that, you need something a list can never be.

You need a map.

So… what on earth is a “graph”?

This is the word that makes people’s eyes glaze over, so let’s defuse it immediately. Forget bar charts and maths class. In this world, a graph is just two things:

• Dots — the things. (Engineers call them “nodes.”)
• Lines — the connections between things. (Engineers call them “edges.”)

That’s the entire idea. Dots and lines.

        [ Laptop ] ───── [ Build server ] ───── [ Database ]
                                │
                          [ File store ]

Four “dots” (computers), connected by “lines” (the fact that they talk to each other). That is a graph. Nothing more.

You already understand graphs perfectly, because you use them every day:

• A social network is a graph: people are dots, friendships are lines.
• A subway map is a graph: stations are dots, the tracks between them are lines.
• A family tree is a graph: people are dots, “parent of” is a line.

And here’s the magic that makes a map more powerful than a list. Once you have the dots and the lines, you can ask the one question a list never could: “How do I get from here to there?”

That’s exactly what your phone’s map app does when it finds you the fastest route across a city. It isn’t looking at a list of streets — it’s looking at a map (a graph!) of how streets connect, and tracing a path through it. Finding good paths through a graph is one of the most well-understood, reliable kinds of computing there is. The same maths that routes your morning commute can route an imaginary burglar through your building.

That is why we use a graph. Not because it’s fashionable, but because security is, at its heart, a question about connections — and a graph is the one tool built to answer connection questions.

Why a graph is exactly the right tool for security

Here’s the insight that ties it all together.

A real attacker does not attack one computer. They move. They slip in somewhere soft — a forgotten laptop, an exposed website, a phished employee — and then they hop: from that first machine to the next, to the next, patiently working their way toward something worth stealing. Security people call this “lateral movement,” but you can just call it walking through the building.

That journey — first room, then the next room, then the next, all the way to the vault — is literally a path through a graph.

Which means: if you have the map, you can trace those paths before the attacker walks them. You can stand at the front door, look at your own building, and say: “From here, the shortest way to the vault goes through these three rooms — and look, the lock on the second one is broken.” You can see the danger in advance, as a route, not as a number.

A list can’t do that. A map can. Security was always a map problem; most tools just never bothered to draw the map.

Yuzu’s unfair advantage: a map drawn from real life

Now, plenty of clever security companies have realised that maps beat lists. So what makes Yuzu’s map special? Where the map comes from.

Most tools that try this have to guess the map. They read configuration files — firewall rules, cloud settings, network blueprints — and from those they infer which rooms could connect to which. It’s like drawing a map of a building by reading the original architect’s plans. The problem: plans are often wrong, out of date, or describe doors that were bricked up years ago. So the map is full of hallways that don’t really exist, and it cries wolf constantly.

Yuzu draws its map from real life. Because Yuzu already has a small piece of software running on every machine, it can simply watch which machines actually talk to each other — the real foot traffic through the building, observed as it happens. Our map isn’t the architect’s optimistic blueprint; it’s a record of the doors people actually walk through.

This is a genuinely big deal, and it’s the reason Yuzu can be trustworthy — which is the whole point of the product. A map built from real traffic produces far fewer false alarms than a map guessed from paperwork. When Yuzu says “this is a route to your crown jewels,” it’s because that route is really used, not because a config file hinted it might exist.

There’s an honest trade-off, and we believe in stating it plainly: by watching only the doors people actually use, we might occasionally miss a door that could be opened but never has been. We accept that. We would much rather be quiet and right than loud and wrong. A tool you can trust is a tool you’ll act on; a tool that cries wolf gets switched off within a week.

What the map lets us do: three new powers

Once you have an honest map of your building, three things become possible that a list could never offer.

1. Find the routes that actually matter

Instead of handing you “you have 10,000 problems, good luck,” Yuzu can say:

“Here are the five short, realistic routes an intruder could take from an outside door all the way to your most valuable systems — and here is the broken lock that starts each one.”

The findings get ranked by the route they sit on, not by their abstract scariness. The medium flaw on the stepping-stone machine — the one that opens the door to a path toward the vault — now correctly outranks the “critical” flaw on the island that leads nowhere. That single re-ordering is the heart of the whole idea. (The engineers call one of these routes an “attack path.”)

2. Judge a flaw by where it sits, not just how loud it is

Picture the floor plan again. Some hallways are quiet dead-ends. Others are the busy central corridor that nearly every route to the vault has to pass through.

A broken lock on the busy central corridor is far more dangerous than the identical broken lock in a quiet broom closet — not because the lock is different, but because of where it is. Yuzu scores each weakness by its position in the map: how many of the dangerous routes run through it. Position, not just severity.

3. Find the chokepoints — the highest-payoff fixes

This is the most valuable power of all, and it’s pure defender’s economics.

If forty different break-in routes all funnel through one particular hallway, then putting a single wall across that hallway doesn’t close one route — it closes forty. Yuzu hunts for exactly these spots: the chokepoints where one well-chosen fix — a patch, a closed connection, a new wall between two areas — breaks the most attack routes at once.

So instead of “here are 200 things to fix,” you get “do this one thing first; it protects more than the next twenty combined.” That’s the difference between a to-do list and a plan. (Engineers call these high-value fixes “chokepoints,” and the “build one wall to close the most routes” calculation has a precise mathematical answer.)

Who decides what’s precious — and where danger comes from?

Two things in this picture are your call, not ours, and that’s by design.

What counts as a “crown jewel”? Yuzu does not presume to know which of your systems matter most. Is it the payments database? The patient records? The trading platform? Your own experts mark those — the “vaults” the whole analysis aims at. We bring the map and the maths; you bring the judgment about what’s worth protecting. (In the engineering docs, these precious systems are called “crown jewels.”)

Where do attackers come from? Not every entrance is equally risky. The public internet is the wild street outside. A partner company’s network, reaching in over a private link, is a side door. The staff WiFi at a branch office — with far weaker physical security than a locked datacentre — is another. Your team labels these entrances by how exposed they are, and Yuzu treats each as a possible starting point for an intruder. (Engineers call these labelled areas “trust zones.”)

In short: you declare what’s precious and where danger starts; Yuzu does the tireless work of tracing every route between the two and ranking them.

A story, to make it real

Let’s walk through a day in the life of this idea at an imaginary finance company.

An intern’s laptop, sitting on the office WiFi, is running a slightly out-of-date chat application. That app has a known flaw. On its own, the severity is medium — a 5 out of 10. In a traditional scanner, this entry sits unremarkably around line 4,000 of the report, buried beneath hundreds of “criticals.” Nobody will ever get to it.

But look at what Yuzu’s map reveals:

   STAFF WIFI                                              THE VAULT
   (an entrance)                                       (a "crown jewel")
        │                                                     ▲
        ▼                                                     │
   [Intern laptop] ──talks to──→ [Build server] ──talks to──→ [DB gateway] ──→ [Payments DB]
     broken lock                                                                 the money
        (1)                          (2)                          (3)

That intern’s laptop regularly talks to a build server. The build server talks to a database gateway. And the gateway can reach the payments database — the company’s single most precious system. Three hops. A short, real road from a forgotten laptop to the money.

Yuzu surfaces that medium-severity laptop flaw as finding number one, because it’s the beginning of the shortest genuine route to a crown jewel. The old tool’s 4,000 “criticals” on dead-end machines drop below it, exactly where they belong.

And then the chokepoint analysis adds the move that a list could never suggest. It points out that the single highest-payoff action isn’t even patching the laptop. It’s putting a wall between the build server and the database gateway — because that one wall doesn’t just break this path, it breaks forty other routes that all squeeze through the same spot. One change. Forty roads closed. That’s the recommendation that lands on the security team’s desk first.

That is the entire product in one story: from “here are ten thousand problems sorted by how scary each sounds” to “here is the one road to your money, and the one wall that closes the most roads.”

Being honest about what we can’t see

A trustworthy tool has to be candid about its blind spots, so here are ours.

Yuzu sees the world from inside each of your machines. That gives it a wonderful view: the real conversations between machines, and what’s locked (or unlocked) within each one. There’s even a special advantage here — from inside a machine, Yuzu can see fine details about how one program could quietly hand control to another on the same machine, a kind of internal pathway that a tool peering only at the network from outside would entirely miss.

But Yuzu does not see the building’s hidden wiring behind the walls — the deep network plumbing, the cloud provider’s own controls, the configuration of physical network gear. That’s a different blueprint, owned by a different team, and we refuse to pretend we have it. Where that information matters, we leave a clean way to plug it in later from a system that does have it — but we will never fabricate a map we can’t actually see. Quiet and right beats loud and wrong, every time.

Why this is part of Yuzu, not a bolt-on

You might reasonably ask: couldn’t you buy a separate product for this? Here’s why it lives naturally inside Yuzu.

• It uses information we already gather. The map is drawn from machine-to-machine traffic that Yuzu’s software already observes for other reasons. We’re not asking you to install yet another agent or open yet another data feed.
• It runs on the platform you already have. No new console to learn, no separate world to manage.
• And — crucially — it turns a finding straight into an action. Other tools hand you a prettier list and wish you luck. Because Yuzu also manages your machines, the moment it identifies “these are the machines on the dangerous route” or “wall off this connection,” it can hand that set of machines directly to the part of Yuzu that fixes things — patch them, isolate them, enforce a rule on them. The insight and the cure live in the same place.

It isn’t another dashboard of problems. It’s a prioritised plan, with the reasoning shown, wired directly to the levers that resolve it.

The whole idea, in one breath

Traditional scanning hands you a list of every problem, sorted by how frightening each one sounds in isolation.

Yuzu hands you a map of how an intruder could actually move through your systems toward the things you care about most — the real routes, ranked by danger, and the single fixes that close the most routes at once.

From a list to a map. From noise to a plan. From “how bad is this flaw?” to “could this flaw get someone to the vault — and what’s the one wall that stops the most of them?”

That’s the shift. Everything else is detail.

If you’d like the real vocabulary

Curious enough to want the proper terms? Here’s the plain-language idea mapped to the words the engineering team uses — so you can follow along in the technical docs and the glossary (CONTEXT.md):

When you’re ready for the full picture — including how we keep this accurate at the scale of over a million machines — the engineering design lives in vuln-scan-engine-design.md.