Silent Fixes -Die unsichtbare Gefahr

Ein Silent Fix ist eine Sicherheitskorrektur, die in den Quellcode eines Open-Source-Projekts eingepflegt wird, ohne dass eine öffentliche Schwachstellenmeldung (CVE) erfolgt. Die Schwachstelle existiert, der Fix existiert - aber niemand erfährt davon, der nicht aktiv den Quellcode verfolgt.

Wie groß ist das Problem? #

Studien zeigen: Auf jede registrierte CVE kommen durchschnittlich 4 bis 11 Silent Fixes. Das bedeutet, dass die Mehrheit aller Sicherheitskorrekturen in Open-Source-Projekten nie in einer Schwachstellendatenbank auftaucht.

Warum gibt es Silent Fixes? #

Silent Fixes haben verschiedene Ursachen -und nicht alle sind böswillig:

• Maintainer stufen das Risiko als gering ein und melden es nicht formal
• Der Aufwand einer CVE-Meldung ist für Einzelpersonen ohne Ressourcen zu hoch
• Das Projekt hat kein strukturiertes Vulnerability-Handling (keine CVD-Policy, keinen Security-Kontakt)
• Der Maintainer erkennt nicht, dass die Korrektur sicherheitsrelevant ist
• Bewusste Entscheidung, um Angreifern kein Zeitfenster zu geben, bevor der Großteil der Nutzer aktualisiert hat

Unabhängig von der Motivation: Das Ergebnis ist dasselbe. Sie nutzen eine Version mit einer bekannten Schwachstelle, und Ihr Scanner meldet nichts.

Warum finden Scanner Silent Fixes nicht? #

Klassische Schwachstellenscanner -sogenannte SCA-Tools (Software Composition Analysis) -arbeiten nach dem gleichen Prinzip: Sie vergleichen die Versionsnummern in Ihrer SBOM mit einer Datenbank registrierter CVEs. Wenn keine CVE existiert, gibt es aus Sicht des Scanners kein Problem.

Silent Fixes durchlaufen genau dieses Raster. Sie sind im Quellcode sichtbar, aber in keiner Datenbank gelistet. Ein Scanner kann nur finden, was gemeldet wurde.

Das ist der Grund, warum ein "grüner" Scan-Bericht keine Sicherheit bedeutet. Er bedeutet lediglich: Es wurden keine registrierten Schwachstellen gefunden.

Gesetzliche Relevanz #

Die EU-Gesetzgebung erkennt dieses Problem implizit an:

• DORA Art. 25 Abs. 1 fordert ausdrücklich "Open-Source-Analysen" und "Quellcodeprüfungen" als Testmethoden -nicht nur CVE-Scans
• DORA Art. 13 Abs. 1 verlangt Kapazitäten zur Sammlung von Schwachstelleninformationen
• NIS2 Art. 21 Abs. 2 lit. e verpflichtet zu Schwachstellenmanagement und -offenlegung -auch über registrierte CVEs hinaus
• CRA Anhang I Teil I Nr. 2a fordert, dass Produkte "ohne bekannte ausnutzbare Schwachstellen" auf den Markt gebracht werden
• CRA Art. 13 Abs. 5 verpflichtet Hersteller bei FOSS-Integration zur Sorgfalt -einschließlich Prüfung gegen die EU-Schwachstellendatenbank
• ISO 18974 (4.1.5 Nr. 2) fordert eine Methode zur Erkennung bekannter Schwachstellen -der Maßstab geht über reine CVE-Scans hinaus

Ein reiner CVE-Scan erfüllt diese Anforderungen nicht. Er deckt bestenfalls einen Bruchteil der tatsächlichen Sicherheitslage ab.

Was bedeutet das für Sie? #

Wenn Sie sich auf Scanner verlassen, übersehen Sie die Mehrheit der Sicherheitskorrekturen. Ihre SBOM zeigt "keine Schwachstellen" - aber in der Realität nutzen Sie Versionen, für die Fixes existieren, die Sie nie eingespielt haben. Ein Auditor, der den Quellcode eines Projekts prüft, sieht das. Ein Angreifer, der dieselben Quellen durchsucht, auch.

Weiterlesen #

• Was ist eine SBOM und warum reicht sie nicht?
• Falsche Sicherheit: Warum Scanner und Versprechen nicht reichen
• OTTRIA im Vergleich zu anderen Ansätzen

Sie möchten wissen, welche Silent Fixes in Ihrer SBOM schlummern? OTTRIA erkennt, was Scanner übersehen. Fordern Sie eine Analyse an.