Why CVSS Alone Lies: Exploit-Chain Reasoning with Recon

If you’ve ever stared at a vulnerability scanner’s output and tried to explain to a CFO why a 9.8 CVE doesn’t actually need a war-room, you already know the problem. CVSS is a useful lingua franca and a lousy prioritiser. A critical on an internal dev database that nobody can reach is less dangerous than a medium on a customer-facing asset sitting one hop from your production data store.

Recon, our AI attack-surface management product, is built around that observation. Instead of handing you a ranked list of CVEs and wishing you luck, it builds a graph of your surface and reasons about which chains of weaknesses actually let an attacker get somewhere that matters.

The CVSS problem, stated plainly

CVSS scores a single vulnerability in isolation. That’s its job, and it does it consistently. What it doesn’t do — can’t do — is tell you whether the vulnerability is reachable, whether it connects to something else, or whether exploiting it gets an attacker closer to anything you’d be sad to lose.

Two real examples sketch the shape of the problem.

First: a CVSS 9.8 remote code execution in a library used by an internal analytics tool. The tool runs on a segmented VLAN, accessible only from two admin jump hosts, behind a firewall that drops everything except port 22 from the admin bastion. Patching matters, but it’s not a pager-worthy issue.

Second: a CVSS 5.3 information disclosure on a public-facing marketing site. Medium severity, not scary on its own. Except the disclosed information is the internal hostname of the CMS admin, which happens to share credentials with a more sensitive asset because someone copy-pasted a deployment template six months ago. Now the 5.3 is a stepping stone.

Any prioritisation that ranks these by CVSS alone gets the order backwards. The right question isn’t “how many highs do I have” — it’s “what chains exist, and where do they end up?”

Graph-based reasoning, not flat lists

Recon models your surface as a graph. Nodes are assets: domains, subdomains, IPs, cloud resources, services, exposed APIs, identity principals. Edges are relationships — reachability, trust, shared credentials, DNS pointers, cloud IAM grants, inferred network paths. On top of the graph sits the exploitability layer: each node carries its vulnerabilities and misconfigurations, and each edge carries a confidence score for whether an attacker can actually traverse it.

That graph is the substrate for reasoning. When a new finding arrives, we’re not asking “is this critical.” We’re asking “starting from this finding, what paths exist, and what’s at the other end?”

Recon pulls from more than forty data sources to build this graph. Passive DNS, cert transparency, ASN ownership records, cloud provider APIs (AWS, GCP, Azure where you’ve granted read-only access), BGP routing data, common open-source intelligence feeds. Under the hood we use massdns for bulk resolution, subfinder and amass for subdomain enumeration breadth, dnstwist for look-alike detection, and Nuclei for targeted probing on assets we’ve decided are worth looking at more closely.

The graph is stored in Neo4j because the queries we run — “find all paths from any internet-exposed asset to any node tagged as PII” — are exactly what a graph database is built for. Change diffs run on roughly 60-minute intervals, so new edges and nodes show up within the hour.

Walking through one exploit chain

Here’s the shape of a chain we see often enough that it’s worth sketching.

Step 1. An orphaned subdomain — legacy-api.example.com — is still in DNS but the backend service was decommissioned a year ago. A new team accidentally re-provisions a host behind that subdomain for a testing sprint. It’s a new node in the graph; Recon flags it within the hour.

Step 2. The new host is serving a default TLS certificate, and the TLS configuration allows protocols the current security team would never approve. That’s a node attribute — misconfigured TLS, low CVSS, probably a 4 or 5 if you scored it straight.

Step 3. Recon notices the host responds on a path that looks like a staging API. It’s a staging endpoint that accepts session tokens issued by production — because whoever set it up copy-pasted the production auth config. That’s an edge in the graph: staging API trusts production identity.

Step 4. The staging API, being staging, has relaxed authorisation checks. It’ll happily return data that production would block. One of the endpoints reads from a shared database — the same Postgres instance production uses.

End of chain. A publicly-resolvable subdomain with weak TLS, trusting production tokens, reading from production data. No single step is a critical. Chained, it’s a path from the internet to customer data with four hops and no exotic exploitation.

A CVSS-ranked list would bury this under actually-higher scores that have no path to anything sensitive. The graph surfaces it because the graph is answering a different question.

How this compares to scanner-vendor output

Most ASM and vulnerability products hand you a list. Some of them cluster by asset. A few do basic correlation. Almost none of them model reachability as a first-class concept, and almost none ask “what chain is this part of.”

The symptom you feel as a security engineer is that you spend your mornings sorting a queue of findings by CVSS, working top-down, and a week later your ticket tracker has 400 closed mediums and the one chain that actually matters is still open on page four. Recon inverts that. The findings we raise are ranked by path — what’s reachable, what does the path lead to, what’s the blast radius if the chain completes.

We still give you CVSS. We just don’t treat it as the headline.

DPDP tagging and the PII dimension

For Indian companies, there’s a regulatory layer on top. India’s Digital Personal Data Protection Act cares about exposure of personal data, and “exposure” includes indirect paths — if an attacker can reach PII through a chain, you’re responsible for it the same as if it were sitting in a public bucket.

Recon tags nodes in the graph that hold or process personal data. That tag propagates — if a path ends at a PII node, the whole chain inherits an elevated priority. When we raise a finding, the report includes which PII categories are at risk and flags the clauses of DPDP that apply, so when your compliance team asks whether a finding triggers a reportable event, the answer’s already attached.

The same graph feeds Compass, our compliance engine, where those tags get mapped to clauses across DPDP, CERT-In, RBI, SEBI, ISO 27001, and SOC 2 without someone retyping findings into a tracker.

Deployment — SaaS, cloud, or air-gapped

Not every organisation can send surface data to a third-party SaaS. Defence, regulated finance, and some government entities need the analysis to run inside their own perimeter. Recon ships as a SaaS service, a single-tenant cloud deployment, or an on-prem install that can run fully air-gapped with local model weights. The graph engine and the reasoning layer are the same across all three; only the data flow changes.

The right business question

The way security leaders usually frame ASM to their boards is “we have N highs, we’re working them down.” That’s a metric that makes the board feel briefed and leaves the actual risk posture opaque.

The better framing — and the one Recon is built to answer — is “here are the chains that lead to our crown jewels, here’s what it would take to break each chain, here’s the order we’re breaking them in.” That answer is shorter, more honest, and closer to how an attacker thinks.

CVSS isn’t lying exactly. It’s just answering a question nobody should be asking as the top-level question. The question is the chain. The chain is the risk.