SBOM im Lebenszyklus: Was ein Praxistest über Schwachstellen-Nachweise zeigt

In meinem letzten Beitrag habe ich gezeigt, wie MVO Security Software-Stücklisten erfasst und mit Schwachstellendatenbanken abgleicht. Bleibt die Frage: Was bringt das im Alltag, wenn die Maschine längst ausgeliefert ist?

Der Cyber Resilience Act beantwortet das eindeutig. Hersteller müssen Schwachstellen über den gesamten Lebenszyklus eines Produkts behandeln, nicht nur bei der Abnahme. Die Maschinenverordnung verlangt in Anhang III, Nummer 1.1.9, Schutz gegen Korrumpierung. Beides lässt sich nur mit Nachweisen belegen, die aktuell sind und stimmen.

Für diesen Beitrag habe ich das an einem Testsystem durchgespielt: einem Linux-Server mit Virtualisierung und rund 770 installierten Paketen, der – wie in vielen Betrieben – über längere Zeit nicht aktualisiert worden war. Erfasst, ausgewertet, aktualisiert, aufgeräumt und wieder erfasst. Vier Erkenntnisse daraus halte ich für jeden Maschinenbauer für relevant.

1. Ein Update bringt mehr als jede Analyse

Die erste Erfassung ergab 3.787 Treffer in 157 Quellpaketen. 151 Pakete hatten eine Schwachstelle, für die es längst eine korrigierte Version gab. Nach dem Update und dem Entfernen alter Pakete sah es so aus:

Ein großer Teil der Arbeit war damit erledigt, ohne dass ein einziger Treffer einzeln bewertet werden musste. Die SBOM zeigt also nicht nur, was offen ist, sondern auch, was mit wenig Aufwand verschwindet. Das ist die Reihenfolge, die ich empfehle: erst aktualisieren, dann bewerten, was übrig bleibt.

Was übrig bleibt, ist der normale Grundbestand eines aktuellen Systems. Für diese Treffer gibt es keine Korrektur, oder der Distributor stuft sie als nicht relevant ein. Genau dafür ist die Bewertung im Sinne von VEX da: „betrifft“, „betrifft nicht“ mit Begründung oder „behoben“.

2. „0 Treffer“ ist nicht dasselbe wie „geprüft“

Auf dem Testsystem liefen auch Pakete des Herstellers der Virtualisierungssoftware, darunter ein eigener Kernel. Für diese Pakete meldete die Schwachstellendatenbank keinen einzigen Treffer. Das lag nicht daran, dass sie fehlerfrei sind, sondern daran, dass die Datenbank sie gar nicht kennt.

Für Industrie-PCs ist das typisch. Viele Hersteller liefern eigene Pakete, Treiber und Firmware aus, die in keiner öffentlichen Datenbank geführt werden. Eine SBOM, die dort „0“ anzeigt, erweckt einen falschen Eindruck.

Eine belastbare Stückliste muss deshalb drei Zustände unterscheiden: geprüft mit Treffern, geprüft ohne Treffer und nicht abgedeckt. Für den dritten Fall braucht es einen anderen Weg, etwa den Abgleich mit der NVD über eine bestätigte CPE-Zuordnung oder die Sicherheitshinweise des Herstellers.

3. Auch das Werkzeug muss geprüft werden – gerade wenn KI mitgeschrieben hat

Beim Vergleich der Stände fiel mir ein Paket auf, das mit 43 Treffern in der Liste stand, auf dem System aber gar nicht installiert war. Die Paketverwaltung führt entfernte Pakete weiter, solange noch ihre Konfigurationsdateien vorhanden sind. Das Erfassungsskript hat diesen Zustand nicht unterschieden und das Paket wie ein installiertes gemeldet.

Der Fehler ist behoben: Das Skript fragt jetzt den Paketstatus mit ab und übernimmt nur Pakete, deren Dateien tatsächlich vorhanden sind. Die Lehre daraus gilt aber allgemein. Ein Nachweis ist nur so gut wie das Werkzeug, das ihn erzeugt. Wer Ergebnisse automatisch in die technische Dokumentation übernimmt, sollte die Erfassung selbst gelegentlich gegenprüfen, zum Beispiel indem er Stichproben mit dem tatsächlichen Zustand vergleicht.

Dazu gehört ein offenes Wort: Das Erfassungsskript ist mit Unterstützung von KI entstanden. Das spart viel Zeit, und der Code lief von Anfang an zuverlässig. Genau darin liegt aber die Falle. KI-generierter Code sieht plausibel aus und funktioniert im Normalfall; die Fehler stecken im Detail, in Situationen, die selten vorkommen und nur auffallen, wenn man das Fachgebiet versteht. Hier musste man wissen, wie die Paketverwaltung entfernte Pakete führt. Ohne dieses Wissen hätte niemand gemerkt, dass die Liste Software enthält, die gar nicht mehr da ist.

Für die CE-Akte heißt das: KI ist ein gutes Werkzeug, aber kein Prüfer. Wer KI-generierten Code für Nachweise einsetzt, muss ihn verstehen, testen und mit der Wirklichkeit abgleichen. Die Verantwortung für die Dokumentation bleibt beim Hersteller, unabhängig davon, wer oder was den Code geschrieben hat.

4. Eingerichtet ist nicht gleich wirksam

Zwei Funde hatten nichts mit Schwachstellen zu tun und waren trotzdem die wichtigsten. Beide begegnen mir in der Praxis immer wieder.

Ein geplanter Auftrag kann in der Oberfläche ordnungsgemäß eingerichtet sein und trotzdem nie laufen, etwa weil der Dienst, der geplante Aufgaben ausführt, bei einer Wartung beendet und danach nicht wieder gestartet wurde. Im Testsystem war genau das der Fall. Betroffen sind typischerweise Datensicherungen, also gerade das, was im Ernstfall zählt.

Ähnlich bei der Netzwerkkonfiguration: Regeln, die im laufenden Betrieb von Hand gesetzt und nicht dauerhaft gespeichert werden, sind nach einem Neustart weg. Das System verhält sich dann anders als vorher, obwohl niemand etwas geändert hat. Auch das zeigte sich im Test, beim Neustart nach dem Update.

Für die CE-Akte ist das der entscheidende Punkt. Dokumentiert wird oft die Konfiguration, die vorgesehen ist. Belastbar ist nur, was nachweislich wirkt: die Sicherung, die tatsächlich gelaufen ist, und die Konfiguration, die einen Neustart übersteht.

Was das für die CE-Akte bedeutet

Aus dem Test ergeben sich ein paar einfache Regeln, die ich auch bei Kundenprojekten anwende:

• Die SBOM wird nicht einmal erstellt, sondern regelmäßig. Der Vergleich zweier Stände ist aussagekräftiger als jede einzelne Liste.
• Vor der Bewertung von Schwachstellen kommen die Updates. Was ein Update behebt, muss niemand einzeln begründen.
• Komponenten ohne Abdeckung in den Datenbanken werden ausdrücklich als solche markiert und auf anderem Weg geprüft.
• Nachweise belegen den Ist-Zustand: wann die letzte Sicherung erfolgreich war, nicht nur, dass ein Sicherungsauftrag existiert.
• Werkzeuge, die Nachweise erzeugen, werden selbst geprüft, auch und gerade wenn ihr Code mit KI entstanden ist.
• Änderungen an Konfigurationen werden so gespeichert, dass sie einen Neustart überstehen, und nach einem Neustart geprüft.

Wie es in MVO Security weitergeht

Die Korrektur am Erfassungsskript ist bereits umgesetzt. Als Nächstes stehen zwei Punkte an, die direkt aus dem Test kommen: Pakete ohne Abdeckung in den Datenbanken sollen als „nicht abgedeckt“ erscheinen statt mit null Treffern, und die Ansicht soll Treffer nach Quellpaket bündeln, damit dieselbe Schwachstelle nicht mehrfach gezählt wird. Dazu kommen Prüfpunkte für die Infrastruktur, etwa wann die letzte Datensicherung erfolgreich gelaufen ist.

Wenn Sie wissen möchten, wie das für Ihre Maschinen aussehen kann, oder einen solchen Abgleich an einem Ihrer Industrie-PCs durchspielen möchten, sprechen Sie mich gern an.