The editorial argues the dashboard itself is unremarkable — what's remarkable is that one person's side project is materially better than the NVD's own triage UI. Since NIST stopped enriching most new CVEs in February 2024, vulnerability coordination has been held together by hobbyists routing around a lagging federal data pipeline.
By submitting cve.0xosprey.com and driving it to 135 points, the submitter and upvoters endorsed a tool whose virtue is its restraint: a searchable, filterable table with CVSS scores and primary-record links, no login wall, no newsletter popover, no 'threat intel platform' veneer. The reception suggests defenders value a plain triage surface over feature-laden commercial offerings.
The piece notes 0xosprey's tracker is one of a dozen alternatives — cvecrowd, vulners, GitHub's advisory feed, Mastodon/Bluesky bots — that have appeared in the enrichment gap. The HN thread wasn't celebrating novelty; it was acknowledging that building around NVD is still necessary, meaning the community has effectively absorbed what was supposed to be a federal function.
A developer going by 0xosprey put a CVE dashboard online at `cve.0xosprey.com` and parked it on Hacker News. It hit 135 points. The site itself is unremarkable in the way the best tools are unremarkable: a searchable, filterable, sortable table of recent CVEs, with CVSS scores, affected products, and links back to the primary record. No login wall, no newsletter popover, no VC-backed "threat intel platform" veneer.
What's remarkable is that a single person's weekend project is a materially better triage surface than the National Vulnerability Database's own UI in 2026. The NVD, run by NIST, is supposed to be the canonical enrichment layer on top of MITRE's CVE list — it adds CVSS vectors, CPE (product) mappings, and references. In February 2024, NIST quietly stopped enriching most new CVEs, citing resource constraints and a planned consortium handoff. The backlog grew into the tens of thousands. By mid-2025 the enrichment rate had partially recovered but never caught back up, and the UI remained the same slow, framed, pagination-heavy artifact it has been for a decade.
So the community did what the community does: built around it. 0xosprey's tracker is one of a dozen that have appeared in that gap — alongside projects like `cvecrowd`, `vulners`, GitHub's own advisory feed, and various Mastodon/Bluesky bots that stream new IDs in real time. The HN thread wasn't celebrating a novel idea. It was acknowledging that the novel idea is still necessary.
The story here isn't the dashboard. The story is what the dashboard is a symptom of. Vulnerability coordination in 2026 is being held together by hobbyists and vendor security teams routing around a federal data pipeline that is, functionally, a lagging indicator.
Consider the actual workflow of a defender today. A CVE gets reserved by MITRE. The vendor publishes an advisory on their own blog, maybe with a GitHub Security Advisory attached. Someone drops the ID into a Slack channel. A detection engineer reads the vendor post, hand-rolls a CPE string, and checks their SBOM. Hours or days later, NVD may add CVSS and CPE data — or may not. If the CVE is in the enrichment backlog, your SIEM's vulnerability feed shows it as "awaiting analysis" indefinitely, which most downstream tools render as "unscored," which most dashboards hide by default. The vulnerability is in production. The alert is suppressed by a missing field.
This is the context in which a tracker like 0xosprey's gets 135 upvotes. It reads the raw MITRE JSON feed directly and renders it without waiting for enrichment, which is exactly the posture a defender should have adopted two years ago. Compare that to commercial platforms — Tenable, Rapid7, Snyk, GitHub Advanced Security — which charge accordingly for essentially the same transformation plus some proprietary scoring. The commercial scoring (EPSS, VPR, Snyk Priority Score) is genuinely useful for prioritization, but the base layer — "what CVEs exist and what do they affect" — is a public good that is currently being maintained by whoever has a weekend free.
The community reaction in the HN thread is instructive. The top comments aren't "cool project" — they're war stories. One commenter notes they rebuilt the exact same thing internally because they stopped trusting NVD timestamps. Another points out that CVE IDs now sometimes appear on exploit-DB and in active ransomware campaigns before they appear with any enrichment at all. A third asks why we're still pretending CVSS v3 base scores mean anything in a world where EPSS probability of exploitation is a better signal and is calculated by a non-profit (FIRST.org) on a shoestring.
The uncomfortable read: the United States' flagship vulnerability program became unreliable, the private market didn't fully absorb the gap, and the slack is being taken up by individuals who are good at scraping JSON. That is not a stable equilibrium. It's a reminder that a lot of security infrastructure you assume is "the system" is actually one underfunded team or one bored developer.
If you own patch management, detection engineering, or anything that consumes a vulnerability feed, three concrete changes are worth making this quarter.
First, stop treating NVD as source-of-truth. Treat MITRE's CVE List (the raw JSON on GitHub) as primary. Treat NVD as one enrichment source among several. Treat the vendor advisory as the authoritative description. Build your pipeline so a CVE with `cvssMetricV31: null` still shows up in triage — don't let your dashboard filter it to invisibility. If your scanner vendor's UI can't do this, that's a procurement conversation.
Second, add EPSS to your prioritization. CVSS tells you how bad something could be in theory; EPSS (Exploit Prediction Scoring System, maintained by FIRST.org) tells you the probability it'll be exploited in the next 30 days. For a shop that can only patch ten things a week, EPSS > 0.5 beats CVSS > 9.0 as a selector, and the data is free. Most of the commercial "risk scores" are EPSS with a logo on it.
Third, have a plan for the day the hobbyist tracker goes down. The lesson of 0xosprey's dashboard is not "use this specific site." It's that the layer you're depending on may be run by one person on a hobby budget. Mirror the feed. Cache the data locally. If a CVE tracker becoming unavailable would meaningfully degrade your ability to respond to a zero-day, that's a dependency to formalize before it bites.
CVE enrichment is probably going to be fixed — eventually, partially — by the CVE Program Consortium that CISA and MITRE have been standing up, and by GitHub's increasingly serious investment in GHSA. But "eventually" and "partially" are the operative words. The structural problem is that a global vulnerability coordination system was being funded as a line item in a single national budget, and that line item got cut. Whatever replaces it will be some mix of federated, commercial, and volunteer, and the handoff will be messy. In the meantime, bookmark the hobbyist dashboards. They're not a stopgap. For most of 2026, they're the actual tier-one feed.
I think a tricky thing about these metrics is GitHub and the Linux Kernel became their own CNA in mid-2024[1] and mid-2025[2]. This caused a bunch of new automation and lowered barriers to actually filing a CVE.As a small data point I have a >20k downloads Obsidian plugin and it got a CVE on a Be
It’s impressive that the number of CVEs issued the last two years has skyrocketed, given how badly DOGE gutted the cybersecurity [0] agencies. Unfortunately we don’t know how huge the backlog may have since grown[0] https://www.securityweek.com/mitre-signals-potential-cve-pro...
Cool. This would be easier to interpret with a log scale. There's an option for it, but clicking it doesn't change the chart and freezes the site for me.
Others have pointed out that we thought we would get security vulnerability from AI code, but it turns out AI is uncovering vulnerabilities in decades of human code.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
I was suspicious the absence of a severity filter was exaggerating the trend...But then I found this:https://craci.com/resources/CVE-publication-trends?sev=criti...Trend for critical CVEs is actually worse, at roughly 25x that of 2020, compared to all CVEs which are roughly 5x co