An idea for discussion — read-only, describe-only

Which CVEs actually matter in your real network?

A vulnerability feed tells you a product has a flaw. It can't tell you whether this one is reachable, or even switched on, in your network. IP Fabric can.

verified on demo1.eu.ipfabric.io · IP Fabric v7.11 · 2026-07-07 · no writes, no attacks

CVSS says
0
"critical" findings
grounded in
your network
Your network says
0
actually exploitable
The gap

A CVE is a fact about a product. Risk is a fact about a network.

So security teams face hundreds of "critical" findings with no way to know which ones bite. Two things decide whether a CVE is real — and both are things IP Fabric already discovers.

the feed / a scanner

"FortiOS 6.0.5 has CVE-2018-13379."

True — and KEV-listed, mass-exploited. But it's context-free, ranked by a generic score. Is this box even reachable? Is SSL-VPN on? Silence.

CVE-2018-13379 · CVSS 9.8 · reachability: unknown · feature: unknown
IP Fabric + the reasoning layer

"…and here is its real path to the DC."

Grounded in the discovered topology: a real reachable route, the ACLs and zone-firewalls on it, and whether the vulnerable feature is actually enabled.

reachable ✓ path=37 hops · 4 ACL · 4 ZONEFW · feature=check
Grounding — real data from the demo

Path-lookup doesn't just say "reachable." It shows the controls on the route.

A single path-lookup on the S01 lab returned a full route Pilsen DR → Ostrava DC — and reported exactly where the ACLs and zone-firewalls sit along it. That's the difference between "a CVE exists" and "here's the path an attacker would traverse through your topology."

path-lookup · 10.38.116.132 → 10.66.123.110 · tcp/443 live
source: IP Fabric
src DC ACL ZONEFW ACL
live flow ACL decision point zone-firewall stylized — real counts below
37
nodes on path
47
edges
4
ACL checks
4
zone-fw checks
How it reads your network — four steps

Discover → surface → ground → validate. All read-only.

01

Discover live

IP Fabric's discovered estate — not a declared asset list. On the demo: 729 devices, 12+ vendors, 88 version tuples, down to the FortiGate at site L71 running FortiOS 6.0.5.

driven on screen · IP Fabric
02

Surface exposure concept

Feed that real inventory to the CVE + attack-path layer. FortiOS 6.0.5 → CVE-2018-13379, a described attack chain — generated, never executed.

reasoning layer we'd add · Cairn / red model
03

Ground it live

Path-lookup checks whether the exposure has a real reachable route to something that matters — with the ACLs and zone-firewalls on it. No path → deprioritise. This is where most "criticals" fall away.

driven on screen · IP Fabric
04

Validate exploitability concept

Read the live config: is the vulnerable feature actually enabled? Confirm → real. Off → drop. Ambiguous → don't guess — flag for a human.

reasoning layer we'd add · AI SOC
◆ describe — don't detonate

Nothing here runs against the network.

Every step is analysis over what IP Fabric already sees — discovery, path-lookup, config. No exploit is ever launched. It respects the same read-only, segregation-of-duties boundary IP Fabric is built on. Any live execution would need signed rules of engagement — and would happen only on infrastructure we own, never a customer's fabric.

An idea for discussion

Three questions worth 20 minutes.

01

Do your customers feel the "CVSS noise vs. real reachable risk" pain — enough to want a product for it?

02

Is a security-exposure product built on IP Fabric data on-strategy for you — or a boundary you'd keep?

03

Which frameworks land hardest — DORA / NIS2 first? And is a read-only report the wedge, or closed-loop remediation later?