Risk is a flow, not a column

Walk through the average security stack and count how many places store a number called "risk."

The vulnerability scanner stores a CVSS score on each finding. The identity tool stores an anomaly score on each account. The asset inventory stores a criticality tier on each host. The cloud posture tool stores a severity on each misconfiguration. Four products, four columns, four numbers — each computed inside its own domain, from data its own domain can see, and stored on its own row.

Here is the problem that this architecture quietly creates: the number that anyone actually wants — how much damage does this thing enable if it goes wrong — is almost never a property of a single row. It is a property of the relationships between rows. A critical CVE on an isolated test box that nothing can reach is not an emergency. The same CVE on a box that sits one hop from a domain controller, which a contractor's anomalous account logged into an hour ago, is the whole incident. The CVE is identical. The CVSS score is identical. Everything that makes the second case matter lives outside the finding, in the graph of things connected to it.

When risk is a column, that context has nowhere to go. So it goes nowhere. The finding keeps its CVSS, the host keeps its criticality, the identity keeps its anomaly score, and the three never compose. We have watched this play out at the extreme: in one environment, the overwhelming majority of findings were structurally orphaned from any asset record at all — a risk number floating free of the thing it was supposed to describe. Most of the risk in that system, measured correctly, read as zero. Not because the environment was safe, but because the architecture had no way to let danger flow from where it was observed to where it mattered.

This post is about treating risk as a flow over a graph rather than a value in a column — and what changes when you do.

The seams are where risk hides

Security has natural domains, and they are useful. Identity, assets, vulnerabilities, network, cloud posture — each is a coherent way to organize a slice of the world, each has its own tooling, its own data model, its own specialists. The domains are not the problem. The seams between them are the problem, because that is exactly where real attacks live and exactly where per-domain scoring goes blind.

Consider how an actual intrusion reads across the seams:

• A user account starts behaving unusually. That is an identity signal.
• The account authenticates to a workstation. That edge crosses from identity into assets.
• The workstation has an unpatched remote-code-execution vulnerability. That is a vulnerability signal on the asset.
• The workstation can reach a database server two hops away. That is a network/graph fact.
• The database holds regulated data. That is an asset-criticality fact.

No single domain sees this chain. The identity tool sees a weird login and stops at the workstation's edge. The scanner sees a CVE and stops at the host boundary. The asset inventory knows the database is sensitive but has no idea a risky identity is two hops away from it. Each tool is correct within its walls and useless across them. The chain only exists in the composition — and composition is precisely what a column cannot represent.

This is the same lesson we have written about before in narrower form. When we argued that blast radius, not intent, is the right primitive for identity security, the underlying move was to stop scoring an identity in isolation and start scoring it by what it could reach through the graph. Cross-domain risk propagation is that same move, generalized: stop scoring anything in isolation, and let danger diffuse along the edges that connect identities to assets to the vulnerabilities and data those assets carry.

What it means for risk to flow

If risk is going to flow, you need three things that a column-based architecture never had to provide: a substrate for it to flow over, rules for how it moves, and a discipline for where it stops.

The substrate is a unified entity graph. Not a federated query that joins four products at read time, and not a data lake that piles their exports in one bucket. A graph in which a user, a host, an IP, a service account, and a sensitive datastore are nodes, and the observed relationships between them — authenticated-to, accessed, connected-to, seen-together-in-the-same-event — are edges. The edges are the seams made first-class. Once the seams are edges, risk can travel them.

The movement has two complementary modes, and you need both.

The first mode is focused diffusion. Start from a small set of high-confidence trouble spots — the accounts and hosts that today's detectors are most certain about — and let risk spread outward from each, decaying with distance, the way heat spreads from a source. This is a well-understood family of graph algorithms (personalized PageRank and its relatives), and its job is to answer "given that this specific thing is hot, what else is implicated?" It is precise and it respects provenance: every elevated score can name the seeds that elevated it. Its limitation is that it is deliberately seeded and deliberately bounded, so it illuminates the neighborhoods around known trouble but does not, on its own, sweep the entire environment.

The second mode is graph-wide lift. Sweep every connected entity and let each one inherit the maximum risk reachable within a couple of hops along the relationship edges. This has no seed budget; it covers everything. Its job is the systemic question: "anywhere a risky thing touches a less-risky thing, has the danger been carried across?" It is what finally pushes a risky identity's score onto the otherwise-quiet host it logged into, and from that host onto the finding sitting on it.

The two modes are not redundant. Focused diffusion is a hot-spot amplifier with high fidelity and named provenance; graph-wide lift is a coverage guarantee that nothing connected to danger stays at zero just because no detector pointed at it directly. Run only the first and you get sharp answers about a few neighborhoods. Run only the second and you get coverage without nuance. Run both and the sharp answers live inside complete coverage.

The discipline is knowing where risk must not flow. This is the part that separates a propagation system that helps from one that turns everything red. The danger is the hub. In any real environment there are nodes that touch hundreds of others — a NAT gateway every machine routes through, a jump host the whole team logs into, a shared service account half the automation uses. If risk flows freely through hubs, one compromised laptop lights up eighty unrelated machines that happen to share a gateway, and the output is noise wearing the costume of signal. So high-degree hubs are treated as risk sinks, not relays: danger can accumulate on them but does not radiate through them. Propagation without hub suppression is worse than no propagation, because it is confidently wrong at scale.

A scanner score is an input, not an answer

Letting risk flow across the asset and identity seams fixes half the problem. The other half is the finding itself — and here the failure mode is subtler, because the scanner's number looks like an answer.

A CVSS score describes a vulnerability in the abstract: how bad is this class of flaw, in a vacuum, for a hypothetical worst-case deployment. It is a genuinely useful input. It is not, and was never meant to be, a statement about your risk. Your risk from that finding is the CVSS conditioned on everything around it: how critical is the asset it sits on, is that asset exposed to the internet or buried on an internal segment, is the flaw actually being exploited in the wild right now, and — crucially — do you have a compensating control that already blunts it.

So the right shape for a finding's risk is not "copy the CVSS." It is a small function that takes the vulnerability's intrinsic severity and the asset context and the live threat intelligence and the controls in place, and composes them into one number that means "what should I, this organization, do about this, today." The CVSS is one term. The asset's criticality and exposure — inherited across the seam we just made flowable — are more terms. A compensating control is a term that reduces the result, because a mitigated critical is not a critical.

Whose math? The case for configurable scoring

The moment risk becomes a composed function instead of a copied column, an awkward question surfaces: whose function?

Vendors love to ship a single proprietary scoring formula and call its opacity a feature. We think that is backwards. A bank regulated under one framework, a hospital under another, and a pharmaceutical manufacturer under a third do not share a risk appetite, do not weight exposure and exploitability the same way, and in several cases are required to use a specific risk matrix that their regulator or their internal risk committee has already blessed. A fixed black-box score is not neutral; it is one organization's opinion, hard-coded, and usually undocumented.

The alternative is to make the scoring model an explicit, inspectable, swappable policy. Some organizations want a weighted blend — exploitability, impact, and urgency combined with tunable weights, the way most modern risk engines work. Others are mandated to use a multiplicative matrix where base impact is multiplied by an environmental factor and a threat factor, doubled when the finding sits in an attack chain, halved when a control applies — the shape that several government and sector frameworks specify. Both should be first-class. The customer should be able to read the formula, adjust its knobs, see the effect of the change before committing it — how many findings move from high to critical, which ones move the most — and then activate it, at which point everything re-scores under the new rule.

That last property matters more than it looks. A risk score you cannot interrogate is a risk score your own auditors will not trust, and an analyst defending a containment decision at three in the morning cannot stand behind a number whose derivation they are not allowed to see. Configurable scoring is not a convenience feature. It is what makes the number defensible — to the analyst, to the auditor, and to the regulator.

What changes when risk flows

When risk is a flow over a graph instead of a column on a row, several things that used to be impossible become routine.

An asset's risk is the maximum of its own danger and the danger of the identities and neighbors that reach it — so the quiet workstation a risky contractor logged into is no longer quiet. A finding's risk reflects the asset under it and the controls around it — so the critical CVE on the isolated test box correctly de-prioritizes itself, and the medium CVE on the internet-facing box next to the crown jewels correctly climbs. The remediation queue finally sorts by something true, because the thing it sorts by has seen the whole picture rather than one domain's slice of it. And every elevated score can explain itself: this host is hot because of that identity, across that edge, under this policy.

None of this requires a new detection breakthrough. The detectors were already firing. The CVEs were already known. The asset criticalities were already recorded. The information was all present and all stranded, one domain apart from the context that would have made it actionable. The only thing missing was a way for danger to cross the seams.

Build the graph. Let risk diffuse from where it is certain and lift across where things connect. Refuse to let it flow through the hubs. Make the finding's score a function of its asset and its controls, not a copy of a number computed in a vacuum. And let the customer see and shape the formula, because a score nobody can read is a score nobody will defend.

Risk was never supposed to be a column. It is what moves between them.