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

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 none there, so their labels are read from the Acknowledgement section of each PSIRT advisory — a rule applied to prose, not a fact the vendor stated in a structured field. Where a vendor publishes nothing at all, the CVE is shown as “not disclosed” rather than guessed at.

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.

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. If a CVE is attributed to the wrong product, the match signal shown on its page is the place to start.