Skip to main content
Intelligence · Correlated per tenant

A feed tells you what is happening. This tells you whether it is happening to you.

ShadowMap correlates vulnerability, exploitation and threat-actor data against the technology it has actually discovered on your estate, tenant by tenant. The output is not a briefing on the threat landscape. It is the subset that touches something you run, each finding carrying the confidence of the match that produced it.

Request an exposure snapshot How to evaluate this
97
Curated intelligence feeds, normalised on ingest
1,000+
Curated threat-actor profiles
STIX/TAXII
With YARA and Sigma carried through, not flattened to hashes
0–100

Threat Exposure Score, every component published

Almost no vendor publishes the weights behind its rating. Ours are on this page: five penalty components, the most each can subtract, and the shape of every curve. The score is 100 minus those penalties, so 100 is an estate with no measured exposure and every point below it traces to a finding in your queue. A score whose derivation you can follow is a score you can argue with, and a rating nobody can argue with is a rating nobody should act on.

The boundary, first

What this is, and what it deliberately is not

Threat intelligence is supporting context inside ShadowMap rather than the thing we ask you to buy. That distinction changes what the rest of this page is worth reading for, so it goes here and not at the bottom.

If you are shopping for a threat intelligence platform as your primary purchase — actor tracking, malware family research, finished intelligence written for an analyst team to read — there are vendors who do exactly that as their whole business, and on that requirement they will beat us. That is a real category with real specialists in it, and we would rather say so on the page than let you find out in month three of a contract. What ShadowMap does is different in kind. It holds an inventory of what you actually run, discovered rather than declared, and correlates global vulnerability, exploitation and actor data against that inventory per tenant. The output is not "here is what is happening in the world". It is "this vulnerability is being exploited, you are running the affected version, and the host is reachable from the internet". Intelligence you cannot map onto your own estate is reading material. The correlation is the product, and the correlation is what the sections below describe.

How the correlation is done

From a detected product to a vulnerability that applies to you

Three stores are joined per tenant: the asset inventory ShadowMap discovered, a CVE database derived from NVD, and event data in MISP format. The join is the hard part, and it is where correlation usually fails quietly.

  1. Detect

    Establish what you are actually running

    Technology fingerprinting across discovered hosts yields the product and, where the exposed service reveals it, the version. A declared inventory is never the source of truth here — correlating against an asset list nobody has reconciled in a year produces confident findings about machines that no longer exist, and silence about the ones that do.

  2. Normalise

    Reconcile the detected name to the catalogue

    A banner announces Apache httpd. The catalogue files the vulnerability under http_server. A product-name mapping resolves detected names to catalogue identifiers, and both forms are carried into the match together, because direct string comparison silently misses real matches and reports a clean result while doing it.

  3. Match

    Draw the candidates, and do not stop here

    Both name forms go to the vulnerability catalogue in one pass. What comes back is every vulnerability ever filed against those products — which is, more or less, what most correlation hands over as its result. It is a candidate set, not a finding set. The stage after this one is the expensive one to build, which is why it is often missing.

  4. Filter

    Test the version against ranges, not strings

    Every candidate carries affected and fixed version ranges, and detected versions are compared against them rather than string-matched. A candidate is dropped only when every instance of that product carried a readable version and none of them fell inside an affected range. One instance whose version cannot be read keeps the candidate alive for all of them — a single patched host does not get to vouch for the ones nobody can see.

  5. Grade

    State the evidence on the finding itself

    Each surviving match is graded high, medium or low on the strength of its version evidence — and a vulnerability that reaches you through more than one product is reported at its weakest grade, never its strongest. The grade travels on the finding, not in a methodology appendix that the analyst working the queue at 09:00 has never opened.

  6. Test

    Probe exploitability, where it is safe and authorised

    Continuous Automated Red-Teaming exercises the matched exposure within agreed scope and marks a confirmed result as confirmed. Not every finding is validated, and an untested one stays marked untested rather than being presented as verified.

What a confidence grade means

A version we could not read is not a finding we delete

Confidence is published on every correlated vulnerability, and the low grade exists for one specific reason. When a product is detected but its version is not, the finding stays in your list rather than disappearing to make the list look tidier.

A version we could not read is not a finding we delete
StateWhat it meansWhat follows
High The product matched a catalogue identifier and the detected version falls inside a published affected range. Treat as applicable. Prioritise on the exploitation signals, not on the match.
Medium The product matched, but the version comparison was indeterminate — or the vulnerability publishes no usable version range to test against. Confirm the running version internally, then it becomes a High or it goes away.
Low The product is detected on a reachable service, but the version is not readable from outside. Kept on purpose. Suppressing it would remove a real exposure in order to improve a count.
Filtered Every instance of the product carried a readable version, and none of them fell inside an affected range for this vulnerability. Out of the queue — but it takes positive version evidence on every instance to get there. Nothing is dropped for being inconvenient to explain.
Key
  • Applies to you
  • Confirm the version
  • Deliberately retained
  • Dropped on evidence

The score, opened up

Five penalty components, published with their weights

A rating you cannot derive is a rating you cannot challenge. These are the five penalty components of the Threat Exposure Score, the most each can subtract from 100, and what moves it.

ComponentMax penaltyWhat it measures
CVE Severity 30 How many correlated vulnerabilities sit on your estate, weighted by their average severity — a count on a logarithmic curve, scaled by the average CVSS across them.
The tenth correlated vulnerability moves it less than the first, by construction. It is capped below a third of the total on purpose: an unexploited critical on an obscure host does not outrank an actively exploited high on an internet-facing one, and a severity-dominated score would insist that it did.
KEV Penalty 25 How many of your correlated vulnerabilities appear in the CISA Known Exploited Vulnerabilities catalogue — where exploitation is a documented fact rather than a projection.
The heaviest weight after severity, and deliberately so: known exploitation is the one input here that is observed rather than modelled. The same catalogue drives a remediation view, so the number penalising your score is the number your regulator asks about, tracked against your own assets rather than kept in a spreadsheet.
Actor Threat 20 How many distinct threat actors are linked to the vulnerabilities you are actually exposed to, drawn from event data that maps actors to specific vulnerabilities.
Actors reach your score through your own findings, not through your sector. Which actors are active against your industry is worth knowing and is shown elsewhere in the product, but it deliberately does not move this number: being in a targeted sector is not the same as running the thing the actor uses, and scoring it as though it were is how a rating becomes a horoscope.
Critical Count 15 How many correlated vulnerabilities are critical severity, counted separately from how severe they are, so that volume registers without being counted twice.
Logarithmic as well, and capped low. Ten criticals is materially worse than one; a hundred is not ten times worse than ten, and a linear count would insist that it was — which is how ratings become unusable at the top of their range.
Asset Density 10 The average number of your assets running each affected product — the blast radius behind a finding, rather than another count of findings.
The smallest weight, because it multiplies exposure that has already been counted rather than signalling anything new. One vulnerable host and forty running the same unpatched build are not the same position, and a score blind to that difference reports them identically.
Total 100 The five penalties sum to at most 100, and your score is 100 minus whatever they actually total. Higher is better: 100 is an estate with no measured exposure, and nothing outside these five moves the number.
There is no discretionary adjustment and no analyst override, in either direction. If your score changed, one of the five above changed, and the finding that changed it is in your queue with its evidence grade attached.

CVE Severity

Max penalty
30
What it measures
How many correlated vulnerabilities sit on your estate, weighted by their average severity — a count on a logarithmic curve, scaled by the average CVSS across them.

The tenth correlated vulnerability moves it less than the first, by construction. It is capped below a third of the total on purpose: an unexploited critical on an obscure host does not outrank an actively exploited high on an internet-facing one, and a severity-dominated score would insist that it did.

KEV Penalty

Max penalty
25
What it measures
How many of your correlated vulnerabilities appear in the CISA Known Exploited Vulnerabilities catalogue — where exploitation is a documented fact rather than a projection.

The heaviest weight after severity, and deliberately so: known exploitation is the one input here that is observed rather than modelled. The same catalogue drives a remediation view, so the number penalising your score is the number your regulator asks about, tracked against your own assets rather than kept in a spreadsheet.

Actor Threat

Max penalty
20
What it measures
How many distinct threat actors are linked to the vulnerabilities you are actually exposed to, drawn from event data that maps actors to specific vulnerabilities.

Actors reach your score through your own findings, not through your sector. Which actors are active against your industry is worth knowing and is shown elsewhere in the product, but it deliberately does not move this number: being in a targeted sector is not the same as running the thing the actor uses, and scoring it as though it were is how a rating becomes a horoscope.

Critical Count

Max penalty
15
What it measures
How many correlated vulnerabilities are critical severity, counted separately from how severe they are, so that volume registers without being counted twice.

Logarithmic as well, and capped low. Ten criticals is materially worse than one; a hundred is not ten times worse than ten, and a linear count would insist that it was — which is how ratings become unusable at the top of their range.

Asset Density

Max penalty
10
What it measures
The average number of your assets running each affected product — the blast radius behind a finding, rather than another count of findings.

The smallest weight, because it multiplies exposure that has already been counted rather than signalling anything new. One vulnerable host and forty running the same unpatched build are not the same position, and a score blind to that difference reports them identically.

Total

Max penalty
100
What it measures
The five penalties sum to at most 100, and your score is 100 minus whatever they actually total. Higher is better: 100 is an estate with no measured exposure, and nothing outside these five moves the number.

There is no discretionary adjustment and no analyst override, in either direction. If your score changed, one of the five above changed, and the finding that changed it is in your queue with its evidence grade attached.

Derivation

Why the curves are logarithmic, and what the benchmark compares you against

Weights are only half of a score. The other half is how each component is shaped and what the resulting number is measured against — which is where most ratings stop explaining themselves.

Threat Exposure Score — construction As of August 2026
  • The scale runs 0–100 and higher is better: 100 is an estate with no measured exposure, and the five penalties are subtracted from it. It is computed per tenant from that tenant's own correlated findings, never from a questionnaire or a self-assessment.
  • Every component is capped, and every one is shaped by a logarithmic curve — KEV included. Each measures a quantity that saturates, so the first few findings move the score hard and the hundredth barely moves it at all. A linear curve would drive every large estate to the floor of the range, where nothing is distinguishable from anything else.
  • The KEV component carries the second-heaviest cap for its own reason: exploitation is observed rather than inferred. The first known-exploited vulnerability on your estate costs you the most, and around twenty of them reach the cap.
  • Benchmarking is against anonymised sector medians. You see your position against the median of comparable organisations, and a median is only computed where enough of them exist to make one — below that threshold the comparison is withheld rather than estimated. You never see another organisation's score, name or findings, in either direction.
  • Correlation is recomputed on demand against your current inventory; the score itself is snapshotted daily, which is what makes the trend a real time series rather than a redrawn instantaneous reading. Movement traces to a specific finding appearing, being remediated, or having its evidence grade change when a version finally became readable.
  • The same number carries a letter band — A from 85, then B, C and D in fifteen-point steps, and F below 40. The bands are deliberately lenient: almost every organisation carries some correlated exposure, and conventional cut-offs would put most of the market in F, which tells a board nothing it can act on.

Deliberately excluded

  • No precision or accuracy figure is published for the correlation, and none is implied by the score. A number we could not let you reproduce is a number we will not print.
  • Questionnaire responses, self-attestations and declared asset inventories do not move the score. Only what was discovered does.
  • No manual adjustment is available — not to you and not to us. A score that can be negotiated is a score that cannot be compared.
  • The score is an output, not the product. Nobody remediates a number; the findings underneath it are the thing you act on, and the score exists to order them.

Feeds and indicators

One indicator, from arrival to expiry

Every feed is reshaped on the way in, so nothing downstream has to care which source an indicator arrived from. What happens to it after that matters considerably more than how many arrived.

Worked example

A single indicator of compromise

On arrival
It lands in whatever shape its source publishes — a file hash in one feed, a domain with a bespoke confidence field in another, a YARA rule in a third, a Sigma rule in a fourth. Nothing is consumed in its native shape, because a store that keeps every source format eventually needs a parser per supplier and gets one per outage.
After normalisation
It is mapped to a STIX/TAXII-compatible schema with its type declared, and the same indicator arriving from ten sources collapses into one record carrying ten provenance entries rather than ten alerts. Then it is intersected with your discovered estate. That intersection is a deterministic rule-based match with no model anywhere in the path — which is the first thing worth knowing when someone asks how a block-list decision got made. An indicator matching nothing you run stays stored and searchable rather than entering your queue.
At expiry
Indicators decay on a sliding window with revalidation rather than on a timer alone: a time-to-live, plus a check that the indicator is still live. A domain that was serving malware in March is often a content-delivery front by August, and a block list that never forgets is mostly archaeology with a false-positive habit.

Where this gets sharper

Threat Intelligence works from one correlated exposure model

Attack Surface Management Actor, malware, CVE and indicator data is correlated against the technology ShadowMap has actually discovered on your estate — which is the only thing that makes it relevant.

Questions buyers actually ask

Before you evaluate this

Can ShadowMap replace our threat intelligence platform?

If your requirement is a research product — actor tracking, malware family reporting, finished intelligence written for analysts to read — then no, and a specialist will serve you better. If your requirement is that intelligence changes what your team does on Monday, the question is a different one, because no feed can answer it alone. Correlation needs an accurate inventory of what you actually run, and most organisations that already own a threat intelligence platform do not own one. ShadowMap discovers the estate first and correlates second. Running both is a coherent architecture: keep the specialist feed for reading, use the correlation to decide what to act on.

Which feeds and sources do you use?

We publish what the intelligence is normalised to and what it is correlated against, not who supplies it. Naming upstream sources tells a competitor how to reconstruct the collection and tells an adversary which channels to close, and neither outcome helps you. What is checkable from your side is more useful anyway: every correlated finding names the product it matched, the catalogue identifier it normalised to, the version range it was tested against, and the evidence grade that comparison produced. You can verify a correlation without knowing which feed carried the indicator.

Can we push correlated findings into our own SIEM or ticketing?

Yes. Indicators are normalised to STIX/TAXII, so a downstream consumer ingests them in a standard shape rather than through a bespoke connector, and correlated findings route to Slack, Jira, ServiceNow or a SIEM with the affected asset and the match confidence attached. The correlation is the part worth exporting. A raw indicator without your inventory beside it is precisely the thing your SIEM already has too much of.

What stops you quietly retuning the weights when it suits you?

Publishing them. The weights are on this page and in the product's own documentation, which costs us the ability to change them without anyone noticing — and that cost is exactly the property that makes them worth publishing. The alternative is asking a board to act on a number whose derivation is a trade secret: a rating that cannot be reproduced cannot be challenged, and a rating that cannot be challenged gets quietly ignored by the people it was built for. If the number moved, one of the five components moved, and the finding behind it is in your queue.

Correlate the intelligence against what you actually run

One apex domain. We discover the estate, correlate current vulnerability, exploitation and actor data against it, and return the findings with their match confidence attached.

Request an exposure snapshot See Pricing