Methodology

What CVE counts do not measure

CVE volume reflects disclosure diligence as much as product quality. A vendor that publishes thoroughly will accumulate more CVEs than one that patches silently. These scores measure disclosed, weighted exposure — not engineering quality.

A vendor that runs a mature disclosure program, publishes thoroughly, and acts as its own CVE Numbering Authority will accumulate more CVEs than one that patches quietly and publishes little. Read a high count as evidence of transparency at least as much as evidence of weakness. That is why the default ranking is risk-weighted rather than volume-based, and why confirmed exploitation carries the heaviest multiplier.

Risk score

cve_risk = severity_weight x kev_multiplier x epss_factor

Scoping risk to a product category

A vendor's total risk across a whole portfolio compares badly between a pure-play firewall vendor and one that also ships switches, phones and collaboration software. Every risk figure can therefore be narrowed to a single product line — the vendor ranking defaults to Firewall / NGFW — and the score is recomputed from only the CVEs affecting products in that category, not filtered down from the total.

Two consequences worth stating plainly. A CVE affecting products in two categories counts in full under each, because it is a real vulnerability in each of them — so the category scores sum to more than the vendor's all-categories total, and comparing a category score against a portfolio score is not meaningful. And a CVE is scored once per category regardless of how many individual SKUs the advisory enumerates, so a vendor that lists five affected models is not penalised against one that names a single umbrella product for the same flaw.

Who discovered it

Every CVE is labelled with who found it: the vendor's own security team, an outside researcher, or a customer. This is the honest counterweight to raw counts. A vendor that finds and publishes its own bugs is doing something materially different from one whose bugs are found by outsiders, and volume alone cannot tell those apart.

The percentage shown on each vendor page divides by CVEs where attribution was actually disclosed. Undisclosed records are reported separately and never enter the denominator — folding them in would turn a vendor's silence into a fake quality signal, which is the exact error this measure exists to avoid.

Where the label comes from

Vendors differ in what they publish. Cisco and Palo Alto record discovery directly in the CVE record. Fortinet publishes nothing there, but every FortiGuard PSIRT advisory carries a labelled Discovered field — Internal, External, or Third-Party Library — which is read from the advisory page. That is Fortinet's own value, not our reading of a sentence, so it is treated as a published field. Where the field is absent the Acknowledgement prose is classified by rule instead, and the CVE says which of the two it got. Where a vendor publishes nothing at all, the CVE is shown as “not disclosed” rather than guessed at.

Third-Party Library is folded into “third party”. It marks a flaw in a bundled upstream component, which reached Fortinet through someone else's disclosure — so whatever else it is, it is not the vendor's own team finding its own bug, and that is the only question this measure asks. Fortinet's raw label is kept on the CVE page so you can disagree with the folding.

Time to exploitation

On Exploited, each known-exploited CVE carries the number of calendar days between its record publishing and CISA listing it in the KEV catalog. It is the closest available proxy for how long customers had to patch before attackers were documented using the vulnerability.

What the number does and does not say

• The KEV date is when exploitation was documented, not when it began. CISA adds an entry once it has reliable evidence, which trails real attacker activity by an unknown margin and by CISA's own process. Every figure is therefore an upper bound on the defender's warning and a lower bound on the attacker's head start.
• A long runway does not prove diligence. The metric cannot separate "the vendor found and fixed this early" from "nobody bothered attacking this product". Both produce the same number.
• Zero is a real value, not a missing one. A CVE published the same day it was listed had no patch window at all. Where CISA listed a CVE before its record published, the lag is negative and is shown at the same position — exploitation preceded disclosure.

Why the median, and why no percentiles

The median is the only summary shown. The arithmetic mean is not reported because it is actively misleading at this scale: one vendor's mean is more than twenty times its median, carried by two late catalogue additions, and ranking on it would show the vendor whose typical exploited CVE is weaponised within two days as the one giving customers the most time. Percentiles are not reported either — with eleven to twenty-three exploited CVEs per vendor, a 95th percentile interpolates between the last two observations and is the maximum under another name.

For the same reason a median is withheld entirely below five exploited CVEs. The individual observations are still plotted, because each is a real CVE with a real date; it is the summary that is not supportable. Most products fall under this threshold.

Comparing one year against another

The charts can be filtered to a single publication year, but two filtered years are not directly comparable, and the page says so when a year is selected. Cohorts have not been observed for equal time: CVEs published this year have had months in which to be exploited, where 2024's have had years. The recent cohort therefore cannot show long lags at all, its longer buckets are necessarily emptier, and the year reads as "exploited faster" for reasons that have nothing to do with attackers. This is right-censoring, and it is the most common way a trend like this gets misread.

The "Is it getting better or worse?" table avoids it by giving every year the same ruler: the share of each year's CVEs exploited within a fixed 90-day window, counting only CVEs old enough to have been watched for all 90 days. A cohort still accumulating is excluded rather than reported short. The denominator is every CVE attributed to the vendor that year, not only the exploited ones, so a vendor cannot improve its rate by having more unexploited CVEs left out of the calculation.

Ninety days rather than a year because it is the longest window the newest cohort still has a usable denominator for — at 365 days it has none, and the most interesting row disappears.

Counting

In the vendor and discovery views a CVE counts once no matter how many products it affects. In the per-product view it counts in each product it affects, because it is a real vulnerability in each — so per-product totals sum to more than the vendor total. Products are listed alphabetically rather than ranked, since sorting by median would order the many products holding a single observation against one another.

How CVEs are attributed to vendors

Not every CVE affecting a vendor is filed by that vendor. Researchers routinely submit through MITRE or another CNA, so matching on the assigning authority alone would undercount. Three signals are used, and the one that matched is recorded on every CVE page so attribution is auditable:

1. cna-assigner — the CVE was assigned by the vendor's own CNA.
2. affected-vendor / cpe — the record names the vendor in its affected products or CPE identifiers.
3. reference-host — the record links to the vendor's own security advisory.

Product categories

Raw product strings are mapped to categories through a version-controlled mapping file. Anything unmatched enters a review queue rather than being dropped, so gaps surface as work instead of as silent undercounting.

Vendors differ enormously in portfolio breadth. Cisco ships routers, switches and collaboration software alongside its security line; counting those against a pure-play security vendor's firewall CVEs would be meaningless. Non-security categories are tracked and browsable but excluded from the default comparison.

Categories a vendor does not compete in

A vendor with no CVEs in a category and a vendor that sells nothing in that category look identical in the raw data, and they are opposite claims. Palo Alto showed 0 under Web & Application Security, which reads as “they ship a WAF and it is clean”. They do not ship a WAF. Those cells now read N/A.

Which categories each vendor competes in is declared in the same version-controlled config as everything else, not inferred from which products we happen to have mapped. Inferring would have published “Cisco has no vulnerability management product” purely because nobody has written a matching rule for Kenna yet — a claim about a company caused by a gap in our own taxonomy. The build refuses to start if a product is filed in a category missing from its vendor's list, so the declaration cannot drift away from the data beneath it.

The distinction is worth the trouble in both directions. A real 0 — they compete there and had no CVEs this year — is a genuinely good result, and it used to be invisible because the row was dropped entirely. These are editorial judgements about real companies, so if one is wrong, tell us.

When the product is named in the description

A CVE record has a structured list of affected products, and it is normally the only thing we read. But some products run the same software as the product they manage, and the vendor files the advisory under that software's name. Palo Alto's Panorama runs PAN-OS, so its advisories list “PAN-OS” and mention Panorama only in a sentence: this issue is applicable to PAN-OS software on PA-Series and VM-Series firewalls and on Panorama. Read literally, the record says firewall and nothing else.

So a small number of products carry rules that read the description as well. Two things make that safe enough to publish. The rules are matched one sentence at a time, and a sentence that denies never counts — most descriptions naming a product name it to say it is not affected, and treating those as evidence is precisely the error this is designed to avoid. And the rules are written per product by hand rather than derived from product names, because a name is not a claim: the string “Cisco IOS Software” appears in hundreds of descriptions that are really about IOS XE or IOS XR.

A description can only ever add a product, never remove one the structured record established, and every link made this way is labelled description in the “Matched by” column on the CVE's own page. If you think one of them is wrong, it is visible and you can tell us.

Sources and update cadence

• CVE List — checked every 15 minutes via the delta feed. Primary source for records, affected products, CVSS and CWE.
• CISA KEV — refreshed daily. Public domain.
• FIRST EPSS — refreshed daily. EPSS data courtesy of FIRST.
• Vendor PSIRT feeds — used for advisory identifiers and freshness, not as a primary source.

Corrections are welcome and there is a form for them: report a correction. If a CVE is attributed to the wrong product, the match signal shown on its page is the place to start.

Known limitations

These are the things most likely to make a figure on this site misleading. They are listed here rather than discovered by a reader.

• Coverage begins in 2024. Comparisons "since 2024" are complete; anything implying a longer history is not. Earlier years are intended but not yet loaded.
• Four vendors. Fortinet, Palo Alto Networks, Cisco and Check Point. A vendor absent from a category ranking may simply not be tracked yet.
• Coverage depth differs enormously between them. Cisco has published roughly thirty times as many CVEs as Check Point over the same period. On any chart with a shared scale, the smaller vendor's bar is a sliver — which is a fact about how much each company discloses, not a measure of how secure their products are. Read the numbers, not the bar lengths, when comparing vendors of very different size.
• Some held records are counted nowhere. When one of these vendors acts as CVE Numbering Authority for an unrelated company's product, we store the record but attribute it to no vendor, because it is not their vulnerability. Those CVEs appear in no count on this site.
• Acquisitions lag. Splunk counts under Cisco, and CyberArk and Venafi under Palo Alto, from the whole period we cover — not from the acquisition date. A newly acquired brand is invisible until its name is added to the taxonomy.
• A product stated only in prose may be missing. We read the structured affected-product list, plus hand-written rules for the handful of products vendors describe in a sentence instead. Where no such rule exists yet, the product is counted nowhere — it does not appear as a gap, it simply is not there. Palo Alto's Panorama sat at zero CVEs for exactly this reason until a reader pointed it out.
• Product categories are our judgement. Vendors do not publish a category per CVE. Where a product plausibly belongs in two, it is filed in one. The category is shown on every record so you can disagree — and say so.
• Discovery attribution is uneven. Cisco and Palo Alto publish a discovery field; Fortinet does not, so theirs is read from published advisory pages. Records with no attribution are reported separately and never silently counted as either.
• Year-filtered exploitation charts are censored, not wrong. The most recent year cannot show long lags because there has not been time for one to occur. Compare years using the fixed-window table, never by reading two filtered charts against each other.
• Time-to-exploitation rests on very few CVEs. Only about fifty CVEs we track have ever been listed as exploited — eleven to twenty-three per vendor, and a single observation for half the products involved. The vendor medians sit within days of each other and the distributions overlap almost entirely, so the ordering between them is not a finding. Treat that panel as a description of how little warning these products tend to come with, not as a ranking of the companies behind them.