Ist jeder Programmfehler eine Schwachstelle?

Nein. Entscheidend ist der Zusatz „die bei einer Cyberbedrohung ausgenutzt werden kann“. Ein Anzeigefehler oder ein falsch gerundeter Wert ist ein Bug, aber keine Schwachstelle. Umgekehrt gilt: Nicht jede Schwachstelle ist ein Programmierfehler. Auch eine unsichere Voreinstellung, ein zu weit gefasstes Berechtigungskonzept oder eine veraltete Bibliothek fallen darunter.

Müssen wir jede Schwachstelle melden?

Nein. Die Meldepflicht knüpft nicht an die Schwachstelle als solche an, sondern an die Aktiv ausgenutzte Schwachstelle. Alle übrigen Schwachstellen müssen Sie erkennen, dokumentieren und beheben, aber nicht an Behörden melden. Diese Unterscheidung ist der häufigste Irrtum beim Einstieg in den CRA.

Gilt das auch für Schwachstellen in fremden Komponenten?

Ja. Für die Sicherheit Ihres Produkts sind Sie verantwortlich, unabhängig davon, wer die betroffene Komponente geschrieben hat. Der CRA geht sogar einen Schritt weiter: Haben Sie eine Korrektur für eine Komponente entwickelt, müssen Sie den betreffenden Code oder die einschlägigen Unterlagen der Person oder Stelle mitteilen, die diese Komponente herstellt oder wartet.

Cyber Resilience Act

Schwachstelle

Legaldefinition Art. 3 Nr. 40 CRA

„eine Schwäche, Anfälligkeit oder Fehlfunktion eines Produkts mit digitalen Elementen, die bei einer Cyberbedrohung ausgenutzt werden kann“

Verordnung (EU) 2024/2847, Art. 3 Nr. 40 CRA

Der Schwachstellenbegriff des Cyber Resilience Acts (CRA) ist bewusst weit gefasst. Er nennt drei Erscheinungsformen (Schwäche, Anfälligkeit, Fehlfunktion) und knüpft sie an eine einzige Bedingung: Sie muss bei einer Cyberbedrohung ausgenutzt werden können.

Damit ist eine Schwachstelle mehr als ein Programmierfehler. Auch eine unsichere Standardkonfiguration, ein zu großzügiges Rechtekonzept oder eine Abhängigkeit, für die es längst eine gepatchte Version gibt, erfüllen den Begriff.

Drei Stufen, die man auseinanderhalten muss

Der CRA definiert nicht nur die Schwachstelle, sondern auch zwei Steigerungen davon. An den drei Stufen hängen sehr unterschiedliche Pflichten:

Eine Schwachstelle kann grundsätzlich ausgenutzt werden.
Eine ausnutzbare Schwachstelle lässt sich von einem unbefugten Dritten unter praktischen Betriebsbedingungen wirksam nutzen.
Bei einer aktiv ausgenutzten Schwachstelle liegen verlässliche Nachweise vor, dass ein böswilliger Akteur sie tatsächlich in einem System ohne Zustimmung des Systemeigners ausgenutzt hat.

Nur die dritte Stufe löst die Meldepflicht aus. Wer das verwechselt, meldet entweder viel zu viel oder verpasst die 24-Stunden-Frist bei dem einen Fall, auf den es ankommt.

Was der CRA für alle Schwachstellen verlangt

Auch ohne Meldepflicht sind Schwachstellen kein rein internes Thema. Anhang I Teil II verpflichtet Hersteller, Schwachstellen ihrer Produkte zu ermitteln, zu dokumentieren und unverzüglich zu beheben, unter anderem durch Sicherheitsaktualisierungen. Für die Dokumentation ist die Software-Stückliste (SBOM) ausdrücklich vorgesehen.

Diese Pflicht gilt über den gesamten Unterstützungszeitraum hinweg. Sie endet also nicht mit der Auslieferung, sondern begleitet das Produkt über Jahre.

Woher Schwachstellen bekannt werden

In der Praxis erfahren Hersteller auf drei Wegen von Schwachstellen: aus eigenen Tests und Codeanalysen, aus öffentlichen Datenbanken über die eingesetzten Komponenten und durch Meldungen von außen. Solche Meldungen kommen von Sicherheitsforschenden, Kunden und Behörden.

Der dritte Weg wird oft unterschätzt. Der CRA verlangt, dass Hersteller eine Kontaktadresse für solche Meldungen angeben und eine Strategie für die koordinierte Offenlegung von Schwachstellen aufstellen und umsetzen. Ohne einen benannten Kanal landen Hinweise im allgemeinen Support. Oder sie erreichen niemanden.

Abgrenzung zu Exploit und Angriff

Drei Begriffe werden häufig vermischt: Die Schwachstelle ist die Eigenschaft des Produkts. Der Exploit ist das Verfahren, mit dem sie sich ausnutzen lässt. Der Angriff ist die tatsächliche Anwendung dieses Verfahrens auf ein konkretes System.

Für den CRA ist die Unterscheidung nicht akademisch: Sie entscheidet, ob nur zu beheben ist oder ob eine Frist läuft.

Fragen aus der Praxis

: Nein. Entscheidend ist der Zusatz „die bei einer Cyberbedrohung ausgenutzt werden kann“. Ein Anzeigefehler oder ein falsch gerundeter Wert ist ein Bug, aber keine Schwachstelle. Umgekehrt gilt: Nicht jede Schwachstelle ist ein Programmierfehler. Auch eine unsichere Voreinstellung, ein zu weit gefasstes Berechtigungskonzept oder eine veraltete Bibliothek fallen darunter.
: Nein. Die Meldepflicht knüpft nicht an die Schwachstelle als solche an, sondern an die Aktiv ausgenutzte Schwachstelle. Alle übrigen Schwachstellen müssen Sie erkennen, dokumentieren und beheben, aber nicht an Behörden melden. Diese Unterscheidung ist der häufigste Irrtum beim Einstieg in den CRA.
: Ja. Für die Sicherheit Ihres Produkts sind Sie verantwortlich, unabhängig davon, wer die betroffene Komponente geschrieben hat. Der CRA geht sogar einen Schritt weiter: Haben Sie eine Korrektur für eine Komponente entwickelt, müssen Sie den betreffenden Code oder die einschlägigen Unterlagen der Person oder Stelle mitteilen, die diese Komponente herstellt oder wartet.

Dieses Glossar dient der Orientierung und ersetzt keine Rechtsberatung. Maßgeblich ist der Wortlaut der Verordnung (EU) 2024/2847.