From Feed to Decision

Most organisations that buy threat intelligence get a feed, connect it to something, and then discover the hard part was never acquisition. A feed produces more information per week than any team can act on; the real work is deciding what to throw away.

This is what the work actually looks like between an alert arriving and somebody deciding to do something.

The funnel, with real numbers in it

Every vulnerability programme starts with a scanner report listing a few thousand findings. That number isn't a workload; it's just unfiltered data.

Here is what the public data does to it.

That last row is the one nobody can sell you, and it is why intelligence programmes fail more often over asset inventory than over intelligence.

The first three filters are free, public, and machine-readable. If your prioritisation does not use them, you are ranking by severity score, which measures how bad a vulnerability would be if exploited — a different question from whether anyone is exploiting it.

Severity is not priority

The most common failure in vulnerability management is treating the CVSS severity score as a work queue. It was never designed for that. It describes intrinsic badness: how much damage, how easily, with what access. It says nothing about whether the bug is being used, whether an exploit exists, or whether the affected component is reachable in your particular deployment.

Two vulnerabilities can both score 9.8. One is being used by ransomware operators this week; the other requires an attacker to already be inside the network holding valid credentials, and has never been seen used. Ranking by severity puts them side by side. Ranking by exploitation does not.

This is the single highest-value use of threat intelligence in most organisations, and it is available before you buy anything.

What the catalogue does to your assumptions

Two patterns in the confirmed-exploited data change how a queue should be ordered.

Old vulnerabilities dominate. 54.6% of the exploited catalogue is five years old or more. If your patching effort is organised around this quarter's disclosures, you are working on the smaller half of the problem. The realistic reading is that attackers prefer reliability to novelty, and an unpatched 2019 vulnerability is more dependable than a fresh one.

Concentration is extreme. Microsoft accounts for 23.1% of the exploited catalogue. If you run a substantial Microsoft estate, roughly a quarter of everything known to be exploited is potentially in scope for you, and your patch cadence for that vendor is doing more work than any other control you own.

The other direction: intelligence about behaviour

Intelligence about specific vulnerabilities is easy to consume—it maps directly to a patching queue. Intelligence about attacker behaviour is more durable.

Indicators like an IP address, file hash, or domain expire almost immediately. An adversary's infrastructure is cheap, and a competent operator rotates it faster than most organisations can ingest a feed. A blocklist of yesterday's IP addresses is a record of where an adversary used to be.

Behaviour lasts longer, because changing how you work is expensive. If a group reliably establishes persistence a particular way, a detection built on that behaviour survives their next infrastructure change. This is why frameworks like MITRE ATT&CK matter operationally: they give you something to detect that the adversary cannot cheaply rotate away from.

The practical version of this is unglamorous. Take the handful of techniques most relevant to your environment, check whether you could actually detect each one today, and fix the gaps. Most organisations find that the answer is "no" for behaviours they assumed were covered — and that finding is worth more than another feed.

The behavioural half of this is counted directly in what a threat actor name buys you, which finds that the median tracked group accounts for 2.7% of the technique catalogue — a useful corrective to detection strategies built around a handful of famous names.

Where intelligence should stop

If an intelligence function produces reports nobody acts on, it has failed, no matter how accurate they are. Three honest tests will tell you if yours is working.

• Does it end in a decision? A product that describes a threat without a recommendation has handed the analysis back to the reader.
• Did it arrive before the decision was made? Intelligence delivered after a patch window is history.
• Could it have changed anything? If the answer to "what would we do differently" is nothing, the report was interesting rather than useful.

The uncomfortable implication is that a smaller volume of reporting is usually a sign of health, not neglect.

The limits of this arithmetic

The funnel above uses public data, and public data has a specific bias: it records what has been confirmed and published. Absence from the exploited catalogue is not evidence that something is safe. It is the absence of published evidence that it is being used, which is a much weaker claim and must not be treated as clearance.

The catalogue is also assembled to direct US federal patching, so its coverage reflects that estate. A bank in Jakarta and an agency in Virginia do not face the same weighting, and a regional risk picture needs regional sources the public list does not provide.

Use it as a floor. Everything on it is worth fixing. Nothing is cleared by being absent from it.

Figures measured from CISA's catalogue and NVD's totals on 19 August 2026; the script is in our repository. We have written separately on what threat intelligence actually is, which sets out where that one-in-228 ratio comes from.