Vendor Health Methodology

Every number on a vendor health report comes from one of the data sources and SQL queries documented below. We publish this methodology so vendors, researchers, and curious readers can verify our work and submit corrections when warranted.

Data sources

  • NVD National Vulnerability Database (nvd.nist.gov) — CVE records, CVSS v3.1 severity scoring, publication dates, references.
  • MITRE cvelistV5 (github.com/CVEProject/cvelistV5) — CNA-published CVE records, used as the canonical CVE timestamp when NVD hasn't completed analyst review.
  • CISA Known Exploited Vulnerabilities (KEV) catalog (cisa.gov/known-exploited-vulnerabilities-catalog) — flag for in-the-wild exploitation, refreshed on each daily snapshot.
  • Vendor security advisories — RHSA (Red Hat), USN (Ubuntu), MSRC (Microsoft), GHSA (GitHub), CSCO (Cisco), and vendor-specific advisory feeds. Used for the “CVE → vendor advisory” timestamp delta that drives the patch-velocity metric.
  • MITRE CWE taxonomy (cwe.mitre.org) — Common Weakness Enumeration classes assigned to each CVE.

Industry-median cohort

“Industry median” values come from the cohort of vendors with at least 10 CVE advisories in the last 3 years. Vendors below this threshold are excluded from the per-page cohort because small-sample statistics aren't robust enough to anchor comparisons.

For each metric reported (severity composition, KEV rate, patch velocity), we compute the 50th percentile across cohort vendors. Per-vendor pages display the delta from this median. The cohort vendor list refreshes whenever a new vendor crosses the 10-CVE threshold.

Metric definitions

1. CVE Disclosure Volume

For each calendar year in the last 5 years, we count the distinct number of CVEs for which the vendor published at least one security advisory. The CVE's publication year (per NVD's published field) determines its bucket, not the year the vendor published the advisory.

REJECTED and RESERVED CVE statuses are excluded — they were withdrawn or never published with technical detail. Including them would inflate counts with non-issues. Includes all CVEs with the vendor's advisory regardless of NVD analyst review status.

2. Severity Composition

For each NVD CVSS v3.1 severity bucket (CRITICAL, HIGH, MEDIUM, LOW, NONE), we count the distinct number of CVEs with one of the vendor's advisories, all-time. The percentages displayed are these counts divided by the vendor's total CVE count.

Severity values come directly from NVD's CVSS v3.1 analyst assignment. If a vendor disputes a severity assignment, the disagreement is with NVD's analyst — not with EchelonGraph's aggregation.

3. CISA KEV Rate

We count what share of the vendor's last-3-year CVEs appear on the current CISA Known Exploited Vulnerabilities catalog snapshot. The numerator is the count of CVEs with the vendor's advisory that are currently KEV-listed; the denominator is the vendor's total CVEs in the same 3-year window.

If CISA removes a CVE from the catalog, that CVE flips back to “not KEV” on our next snapshot refresh. KEV listing means CISA observed real-world exploitation in the wild — it's a CISA judgment, not ours.

4. Vendor Patch Velocity

For each CVE in the last 3 years where the vendor published an advisory, we compute the wall-clock interval (in calendar days) between the CVE's NVD/MITRE publication timestamp and the vendor's first advisory for that CVE. We then report the 25th, 50th (median), and 75th percentiles across all such intervals.

CVEs where the vendor's advisory predates the CVE publication (pre-disclosure) are excluded — those represent a different process. The metric is suppressed entirely when the sample size is below 10 CVEs (insufficient data to be reliable). Reported in calendar days, not business days.

5. Top Recurring Weakness Classes

Across the vendor's last 3 years of CVE disclosures, we group by the CWE-ID assigned to each CVE and report the 5 most-frequently-occurring weakness classes. A single CVE can carry multiple CWE assignments — each is counted independently in its respective group.

CWE assignments come from NVD's analyst review or, where NVD hasn't mapped yet, the CNA-published cvelistV5 record. The CWE taxonomy itself is maintained by MITRE.

Refresh cadence

  • Raw vendor counts: live, queried on each page request (CDN-cached 6h)
  • Industry medians: refreshed every 6 hours via internal cache; serves stale data while a refresh is in flight
  • Source data ingestion: MITRE cvelistV5 polled hourly, NVD modified-feed polled every 2 hours, CISA KEV polled every 6 hours, vendor advisories polled per-vendor (typically every 1-4 hours)

What this report doesn't claim

  • It is not a security ranking. A higher CVE count can mean better disclosure practices, more product surface area, or both — these are distinct from security quality.
  • It is not a comprehensive list of vendor vulnerabilities. It only counts CVEs the vendor publicly acknowledged via advisory. Issues handled privately under embargo or never disclosed aren't in here.
  • It is not a recommendation to use or avoid any vendor. Use it for vendor benchmarking, not procurement decisions.
  • It is not a real-time threat feed. These are historical activity statistics.

Submitting a correction

If a number on a vendor page is wrong, please email support@echelongraph.io with:

  • The exact vendor page URL and specific metric in dispute
  • The corrected number, ideally with the source you believe is correct
  • A link to the authoritative upstream record (NVD, CISA, vendor advisory page)

We review every correction request. Material errors are fixed within 72 hours; methodology updates that result from a correction are documented at the bottom of this page.

Methodology changes

Initial version published 2026-05-28. No changes yet.