Why One Source Is Never Enough: How We Decide a Vulnerability Is Fixed
Every vulnerability record on this platform answers one practical question: is there a fix, or not? The honest answer is often harder to establish than it looks — because the first entity to say “this is fixed” is frequently the one with the least independent standing to confirm it.
Our position is simple and it does not change: no single source is treated as final. A vendor, a CNA, or an automated advisory feed stating that a version is fixed is a claim. We record that claim, we show it to you plainly — and we mark the record PATCH UNDER REVIEW until an independent, separate-origin source (a Linux distribution’s own security team, an enterprise errata feed, or an ecosystem database that did its own analysis) confirms the fix. Only then does a record turn green.
This is not caution for its own sake. The history of security is full of cases where the first “it’s fixed” was wrong — sometimes by accident, sometimes on purpose.
A trusted source can be wrong — or hostile: xz-utils (CVE-2024-3094)
Section titled “A trusted source can be wrong — or hostile: xz-utils (CVE-2024-3094)”In March 2024, a backdoor was discovered in xz-utils, a compression library present in nearly every Linux distribution. It carried the maximum severity score of 10.0. What makes this case essential is how it got there.
The backdoor was not the work of an outside attacker breaking in. It was introduced by a project maintainer — an identity operating as “Jia Tan” that had spent roughly two years building trust, contributing legitimately, and applying pressure through sock-puppet accounts until it was handed maintainer rights to the project. The malicious code was then shipped in the released source tarballs, while being absent from the project’s public Git repository. An observer trusting the maintainer’s published releases would have seen a normal, trusted, actively-maintained project.
It was caught not by trusting the source, but by independent scrutiny: a Microsoft engineer, Andres Freund, investigating an unrelated performance oddity in a Debian development build. Linux distributions — Debian, Red Hat, SUSE — then independently reverted the affected packages, and the hosting platform temporarily disabled the project’s repository.
The lesson: the entity publishing a release is not, by itself, proof that the release is safe or that its claims are true. Confirmation has to come from somewhere that did its own work.
The first “fixed” is often not the real fix: Log4Shell (CVE-2021-44228)
Section titled “The first “fixed” is often not the real fix: Log4Shell (CVE-2021-44228)”In December 2021, Log4Shell became one of the most severe vulnerabilities ever disclosed, affecting an enormous share of Java applications worldwide. A fix was published quickly — version 2.15.0.
Except 2.15.0 was not the end of it.
| Version | Issue | New CVE |
|---|---|---|
| 2.15.0 | Incomplete fix in certain configurations | CVE-2021-45046 |
| 2.16.0 | Denial-of-service issue | CVE-2021-45105 |
| 2.17.0 | Further remote-code-execution issue | CVE-2021-44832 |
| 2.17.1 | Real, stable fix | — |
If a platform had simply recorded “fixed in 2.15.0” the moment that version shipped — because the upstream project said so — it would have told its users they were safe when they were not, three times over. The real, stable fix was established only through independent testing and disclosure over the following weeks.
This is exactly why a stated fixed-version on our records appears as a clearly-labelled unverified vendor claim until independent confirmation arrives — never as a green “you are safe.”
Even the big registries are fallible and incomplete
Section titled “Even the big registries are fallible and incomplete”Relying on a single authoritative registry has a quieter failure mode: gaps and errors in the registry itself.
In early 2024, the U.S. National Vulnerability Database (NVD) sharply slowed its enrichment of new CVE records, leaving large numbers of vulnerabilities without the analysed severity and affected-version data that downstream tools depend on. A platform anchored to one registry inherits that registry’s blind spots.
Registries also carry contested records. In 2023, a CVE was filed against the curl project (CVE-2020-19909) that the NVD graded 9.8 CRITICAL — near the top of the scale. The curl maintainers, who did not file it and were not consulted, pointed out that the underlying issue was an integer-overflow bug in a command-line retry-delay option that they had already assessed as not a security problem and fixed back in 2019. A record can be formally assigned, widely mirrored, and severely mis-rated all at once.
The point is not that any one registry is bad. It is that “a source says so” and “it is confirmed” are different states, and a serious platform has to keep them separate.
How this shapes what you see
Section titled “How this shapes what you see”Our pipeline ingests many sources — NVD, GitHub Security Advisories (GHSA), OSV, Debian, Red Hat, and others. We value every one of them. But we count distinct origins, not raw source count: a GitHub advisory, and the copies of it that NVD and OSV re-publish, are one origin, not three. A record only reaches PATCHED / FIX AVAILABLE when at least two genuinely independent origins agree — for example, a vendor advisory plus a Linux distribution that built and shipped the fix itself.
Until then you see:
- PATCH UNDER REVIEW — a fix is claimed but not yet independently confirmed.
- A vendor-claimed fix line, if a specific version was stated, labelled UNVERIFIED — pending independent confirmation. We show the claim; we do not endorse it.
- Source chips that distinguish an independent confirmation (✓ green) from a same-origin mirror (⧗ yellow).
None of this is adjusted by hand, and none of it is swayed by a request to change a record. We report what the sources show, and we tell you exactly how confident that makes us.