Silent Fixes — The Invisible Threat

A Silent Fix is a security correction applied to the source code of an open source project without a public vulnerability notification (CVE). The vulnerability exists, the fix exists — but nobody learns about it who does not actively follow the source code.

How big is the problem? #

Studies show: for every registered CVE, there are on average 4 to 11 Silent Fixes. This means that the majority of all security corrections in open source projects never appear in a vulnerability database.

Why do Silent Fixes exist? #

Silent Fixes have various causes — and not all are malicious:

Maintainers assess the risk as low and do not report it formally
The effort of a CVE registration is too high for individuals without resources
The project has no structured vulnerability handling (no CVD policy, no security contact)
The maintainer does not recognise that the correction is security-relevant
A deliberate decision to avoid giving attackers a time window before the majority of users have updated

Regardless of the motivation: the result is the same. You are running a version with a known vulnerability, and your scanner reports nothing.

Why do scanners not find Silent Fixes? #

Classical vulnerability scanners — so-called SCA tools (Software Composition Analysis) — work on the same principle: they compare the version numbers in your SBOM against a database of registered CVEs. If no CVE exists, there is no problem from the scanner's perspective.

Silent Fixes pass straight through this filter. They are visible in the source code but listed in no database. A scanner can only find what has been reported.

This is why a "green" scan report does not mean security. It merely means: no registered vulnerabilities were found.

Legal relevance #

EU legislation implicitly recognises this problem:

DORA Art. 25(1) expressly requires "open source analyses" and "source code reviews" as testing methods — not just CVE scans
DORA Art. 13(1) requires capacities for gathering vulnerability information
NIS2 Art. 21(2)(e) obliges vulnerability management and disclosure — also beyond registered CVEs
CRA Annex I Part I No. 2a requires that products are placed on the market "without known exploitable vulnerabilities"
CRA Art. 13(5) obliges manufacturers to exercise due diligence when integrating FOSS — including checks against the EU vulnerability database
ISO 18974 (4.1.5 No. 2) requires a method for detecting known vulnerabilities — the benchmark goes beyond pure CVE scans

A pure CVE scan does not meet these requirements. It covers at best a fraction of the actual security posture.

What does this mean for you? #

If you rely on scanners, you are overlooking the majority of security corrections. Your SBOM shows "no vulnerabilities" — but in reality, you are running versions for which fixes exist that you have never applied. An auditor who examines a project's source code will see this. An attacker who searches the same sources will too.