patchgap

Every number on this page comes from a live query to NVD's public CVE API (no caching layer of ours in front of it beyond a browser-side cache that keeps repeat visits fast and respects NVD's request rate) — this is not a snapshot baked in at build time.

Read the counts carefully. A CVE count mostly measures how many vulnerabilities got found, disclosed, and assigned an ID — not how secure a system actually is. A vendor that treats nearly every fix as CVE-worthy (Microsoft's monthly Patch Tuesday does this close to mechanically) will out-count one that's historically been looser about filing CVEs for its own fixes. More scrutiny — more users, more researchers, bug bounties — also means more CVEs get found, not fewer; an obscure, low-adoption system can look artificially "safer" by this metric just by being ignored. None of the charts below can separate "actually more vulnerable" from "more thoroughly checked."

What raw counts can't show you is the part of the open-source case that's actually structural: with the code public, anyone can read a fix, audit it, and check the vendor's story against the diff — rather than taking a closed vendor's disclosure on faith. That's not a number this dashboard can chart, so it's stated here instead of implied by a bar height.

Counts use NVD's virtualMatchString CPE match, which sums every shipped version under one vendor/product pair in a single query. macOS additionally sums the legacy mac_os_x and current macos CPE names for the all-time total only — recent-activity metrics use the current name alone, since essentially all recent CVEs are filed under it.

"Debian" here is a rollup, not one CPE query — read that carefully. NVD catalogues most Linux CVEs against the affected package (OpenSSL, the kernel, curl, …), not against a distro-wide CPE. Windows, macOS, iOS, and Android are each shipped and CVE-tracked as one product, so a query against the OS itself captures the whole picture; a Linux distro is thousands of independently-versioned packages. Querying just debian_linux alone would badly undercount — over a trailing 90 days it returns single digits, because NVD only attaches that distro-version match node when an advisory explicitly cross-references it. So the Debian bars sum debian_linux with the set of packages every Debian install actually ships: the Linux kernel itself, glibc, bash, coreutils, dpkg, systemd, and OpenSSL — Debian's own "Priority: required" package set plus the kernel (obviously mandatory but not an apt package) and OpenSSL (pulled in almost everywhere transitively, and the single highest-profile source of Linux CVEs historically). The exact list and reasoning are in public/lib/os-data.js.

That rollup is dominated by the kernel, and that's worth understanding, not just a bar chart to read at face value. The Linux kernel security team assigns a CVE to almost every fix that touches security-relevant code — a deliberate, and debated, disclosure policy shift, not evidence the kernel ships more real bugs than Windows or macOS. That policy alone can make the kernel's count outweigh every other package in the Debian rollup combined, several times over. Treat a big Debian bar the same way the general caveat above asks you to treat every bar here: more filed CVEs measures more disclosure, not more risk. Summing per-package totals also doesn't dedupe a CVE ID that happens to be cross-referenced under more than one of these CPEs — a small, disclosed overcount, not a hidden one.