How to find out whether the kit on your network is already being attacked

Most published vulnerabilities are never used against anybody. Tens of thousands are disclosed each year, and the overwhelming majority sit in a database while nobody writes a working exploit.

This is the practical problem with patching by severity score. A CVSS rating measures how bad a flaw would be if exploited. It says nothing about whether anyone is exploiting it. Sort your queue by severity and you will spend the week on theoretical problems while the one being used against you sits further down the list.

There is a free, public list that solves this, and it is not widely used outside security teams.

The KEV catalogue

The US Cybersecurity and Infrastructure Security Agency maintains the Known Exploited Vulnerabilities catalogue. The entry bar is evidence of exploitation in the wild — not severity, not theory, not a proof of concept on a researcher’s blog.

If something is on that list, somebody is already being attacked with it.

It is published in the open with no account, no licence and no rate limit. There is a browsable table on the website and a machine-readable JSON file that anyone can pull.

What each entry tells you

Every record carries the same fields, and three of them do most of the work:

• Vendor and product — plain names like “Cisco” and “Secure Firewall Adaptive Security Appliance”, not just a CVE number. This is what makes the list usable by someone who knows what they run but not which CVEs affect it.
• Date added — when CISA confirmed exploitation.
• Due date — the deadline for US federal agencies.
• Required action — usually pointing at the vendor’s mitigation.
• Known ransomware campaign use — whether the flaw has been tied to a named ransomware operation.

The trick with the due date

The gap between the date added and the due date is the single most useful signal in the catalogue, and it is easy to miss.

Under Binding Operational Directive 22-01, US federal agencies must remediate KEV entries on a set timetable — typically around three weeks.

When CISA shortens that to a few days, it is telling you something. It did exactly that on 11 August, giving agencies three days to patch a Cisco firewall flaw. A compressed deadline means the exploitation is bad enough that the standard clock was judged inadequate.

Sort by the shortest gap between added and due, and you have a priority queue built by people with access to incident data you do not have.

How to actually use it

If you run a business network. Write down what you actually run — the firewall, the VPN appliance, the file transfer tool, the remote management software. Check those vendor names against the catalogue monthly. Almost every entry is enterprise kit, and the same categories recur: edge devices, remote access, and management consoles.

If you are a developer. Pull the JSON and match it against your dependency list. It is a flat file with stable field names; a scheduled job that alerts when a vendor you depend on appears is an afternoon’s work.

If you are at home. Very little consumer equipment appears, and you do not need to read it. The one category worth caring about is your router — it is the only internet-facing appliance most households own, and the one nobody updates. Check whether yours still receives firmware updates. If the manufacturer has stopped, that is your answer.

What it will not do

The catalogue is US-centric in its obligations. Nothing on it is legally binding on a British organisation, and the due dates are federal agency deadlines, not advice aimed at you.

It also lags. A vulnerability appears once CISA has confirmed exploitation, which is necessarily after exploitation began. It is a good prioritisation tool and a poor early-warning system.

For a framework rather than a list, the NCSC’s vulnerability management guidance is the British equivalent worth reading, and it is also free. Use the KEV catalogue to decide what to do first, and the NCSC guidance to decide how to run the process at all.