Schwachstellenmanagement mit SBOM und VEX

Schwachstellenmanagement mit SBOM und VEX

0:00 Jetzt haben wir eine Stückliste. Damit lässt sich etwas anfangen — und zwar zunächst etwas Unangenehmes: Wir gleichen sie gegen die Schwachstellendatenbanken ab und bekommen eine Liste mit Treffern, die deutlich länger ist, als jedes Team sie abarbeiten kann. Das ist der Moment, in dem viele Programme scheitern. Nicht weil die Treffer falsch wären, sondern weil sie unbewertet sind. Die Liste der Treffer ist keine Arbeitsliste.

0:24 Sie wird erst eine, wenn jemand bewertet hat — und wie das geht, ist das Thema dieses Moduls.

Schwachstellenmanagement mit SBOM und VEX

0:30 Drei Schritte liegen vor uns. Erstens der Weg von der Komponente zum Treffer und die Frage, was ein Schweregrad eigentlich aussagt — und was nicht. Zweitens VEX, also der maschinenlesbare Weg, eine Betroffenheit oder eben Nichtbetroffenheit zu erklären. Und drittens die Entscheidung und ihre Kommunikation: beheben, ersetzen, absichern oder bewusst tragen — und wie Sie das Betroffenen mitteilen.

Von der Komponente zur Schwachstelle

0:54 Beginnen wir mit dem Abgleich und mit der Frage, warum die Zahl der Treffer so wenig über die tatsächliche Lage aussagt. Vorweg: Das Problem ist nicht, dass die Werkzeuge zu viel melden. Sie melden korrekt. Sie können nur eine Frage nicht beantworten — und das ist ausgerechnet die wichtigste. Der SSDF beschreibt diesen Bereich unter dem Titel „Schwachstellen fortlaufend identifizieren und bestätigen", und die drei genannten Quellen sind aufschlussreich.

1:22 Erstens Informationen aus dem Nutzerkreis und aus öffentlichen Quellen. Zweitens: allen glaubwürdigen Meldungen nachgehen — nicht nur den spektakulären. Und drittens der automatisierte Abgleich der eigenen Komponenten gegen bekannte Schwachstellen. Genau dafür haben wir im letzten Modul die Stückliste gebaut. Beachten Sie das Wort „fortlaufend": Dieser Abgleich ist kein Release-Schritt, sondern Dauerbetrieb — auch für Versionen, die längst ausgeliefert sind.

1:49 Vier Stationen, und die meisten Werkzeuge decken die ersten beiden ab. Die Stückliste liefert den Bestand, der Abgleich liefert die Treffer — beides automatisch, beides schnell. Bei der Bewertung hört die Automatisierung weitgehend auf, und bei der Entscheidung endgültig. Das ist keine Schwäche der Werkzeuge, sondern eine Aussage über die Aufgabe: Die Bewertung braucht Wissen über Ihr Produkt, das kein externes Werkzeug haben kann.

2:14 Wenn Ihr Prozess nach Station zwei aufhört, haben Sie eine Liste. Wenn er bis Station vier reicht, haben Sie Schwachstellenmanagement. Ein Schweregrad beschreibt die Schwachstelle, nicht ihre Lage in Ihrem Produkt. Dieselbe Lücke kann bei Ihnen kritisch und beim Nachbarn bedeutungslos sein, je nachdem, ob der betroffene Code überhaupt erreichbar ist.

2:35 Der SSDF verlangt deshalb ausdrücklich eine Risikorechnung je Schwachstelle, die Ausnutzbarkeit, mögliche Auswirkung und weitere Merkmale berücksichtigt. Der dritte Punkt ist im Alltag der wirksamste: Bekannte aktive Ausnutzung verschiebt die Dringlichkeit unabhängig vom Punktwert. Eine mittelschwere Lücke, die gerade ausgenutzt wird, ist dringender als eine kritische, für die es keinen Angriff gibt.

2:58 Vier Fragen, und die Spalte rechts zeigt ihre Wirkung auf die Priorität. Der Schweregrad ist die Grundlage, nicht das Ergebnis — er kommt zuerst, aber er entscheidet nicht. Die aktive Ausnutzung hebt stark an. Die Erreichbarkeit senkt oder hebt deutlich, je nachdem. Und die Verfügbarkeit einer Behebung bestimmt den Weg, nicht die Dringlichkeit.

3:19 Die Fußzeile benennt die unbequeme Wahrheit: Die dritte Frage kann nur Ihr eigenes Team beantworten. Sie ist die teuerste — und sie ist die wertvollste, weil sie mehr Treffer entschärft als alle anderen zusammen. Der erste Punkt ist die naheliegende Abkürzung: Der Schweregrad wird als Priorität verwendet, weil er als Zahl vorliegt und Zahlen sich sortieren lassen.

3:41 Der zweite ist ein handfester Fehler — der Abgleich läuft gegen den Quellstand statt gegen das ausgelieferte Artefakt; dann fehlen Ihnen die Betriebssystempakete und Sie bewerten das Falsche. Der dritte kostet enorm viel Zeit: Treffer in Testabhängigkeiten und in Produktionscode landen in derselben Liste, obwohl nur eine davon ausgeliefert wird.

4:00 Und der vierte ist Berichtswesen ohne Substanz — die Zahl offener Treffer wird gemeldet, bewertet hat sie niemand.

VEX und die Aussage zur Betroffenheit

4:07 Im zweiten Kapitel geht es um ein Format, das genau die Lücke schließt, die wir eben gesehen haben. Es erlaubt, maschinenlesbar zu erklären, ob eine gemeldete Schwachstelle in Ihrem Produkt tatsächlich ausnutzbar ist — und wenn nicht, warum nicht. VEX teilt die Ausnutzbarkeit einer Schwachstelle im Kontext des Produkts mit, in dem die Komponente verwendet wird.

4:28 Die Frage lautet ausdrücklich nicht, ob eine Schwachstelle existiert — das steht in der Datenbank. Die Frage lautet, ob sie hier ausnutzbar ist. Der genannte Nutzen ist sehr praktisch: Es sinkt der Aufwand für Patches, die nichts bewirken. Und es gibt noch einen zweiten Nutzen, der oft übersehen wird — Ihre Kunden bekommen eine Antwort, ohne dass jemand bei Ihnen anrufen muss.

4:50 Bei einer weit verbreiteten Bibliothek kann das Hunderte Anfragen ersparen. Drei Aussagen, und jede hat eine Voraussetzung. Betroffen verlangt einen Plan mit Frist. Nicht betroffen verlangt eine belegte Begründung — dazu gleich mehr. Und „in Prüfung" verlangt einen Termin für die Entscheidung. Genau diese dritte Zeile wird in der Praxis am häufigsten verletzt, deshalb steht sie in der Fußzeile: Ohne Termin wird „in Prüfung" zum Dauerzustand.

5:17 Und eine Liste, in der die Hälfte der Einträge seit Monaten in Prüfung ist, ist wieder genau das, was wir vermeiden wollten — eine Liste ohne Aussage. Vier typische Begründungen, warum eine Schwachstelle hier nicht ausnutzbar ist, und sie unterscheiden sich in ihrer Belastbarkeit. Die stärkste zuerst: Der verwundbare Code ist im Artefakt gar nicht enthalten — das lässt sich zeigen.

5:40 Zweitens: Er ist enthalten, wird aber von keinem Pfad der Anwendung erreicht; das erfordert eine Analyse, ist aber belegbar. Drittens: Die Ausnutzung setzt eine Konfiguration voraus, die hier nicht vorliegt — hier lohnt der Zusatz, wer verhindert, dass sie morgen vorliegt. Und viertens: Eine vorgelagerte Maßnahme verhindert die Ausnutzung. Dann gehört genau diese Maßnahme dokumentiert, denn sie darf nicht unbemerkt verschwinden.

6:06 Zwei Begründungen genügen, um das Prinzip zu lernen — und beide sollen einen Beleg tragen: einen Aufrufpfad, eine Konfiguration oder eine vorgelagerte Maßnahme. Der Hinweis auf der Folie ist der strengste Satz dieses Moduls, und er ist ernst gemeint: Begründungen mit „vermutlich" oder „üblicherweise" zählen nicht. Der Grund ist einfach — diese Sätze stehen später in einer Kundenauskunft, möglicherweise in einer vertraglichen Zusicherung.

6:32 Wer dort „vermutlich" schreibt, hat entweder nicht nachgesehen oder gibt eine Einschätzung als Tatsache aus. Der erste Punkt ist der, vor dem ich am meisten warne: „Nicht betroffen" wird gesetzt, weil ein Patch aufwendig wäre. Das ist keine Bewertung, das ist eine Umgehung — und im Schadensfall eine sehr unangenehme Aktenlage.

6:52 Der zweite ist ein Ablageproblem: Die Begründung steht in einem Ticket und nicht bei der Aussage, und beim nächsten Lauf fängt jemand von vorn an. Der dritte ist der Dauerzustand „in Prüfung". Und der vierte ist eine Ungenauigkeit mit Folgen — die Aussage gilt für das Produkt allgemein statt für eine bestimmte Version. Betroffenheit ist aber versionsabhängig.

Behebung und Kommunikation

7:14 Im dritten Kapitel geht es um das, was nach der Bewertung kommt. Und da gibt es mehr Möglichkeiten als die beiden, die meist diskutiert werden — nämlich patchen oder ignorieren. Dazwischen liegen zwei weitere Wege, die in vielen Fällen die richtigen sind. Der SSDF verlangt für jede Schwachstelle eine risikobasierte Entscheidung: beheben, oder das Risiko anders behandeln — etwa durch Akzeptanz oder Übertragung — und die Behandlung zu priorisieren.

7:40 Bemerkenswert ist, dass Risikoakzeptanz hier ausdrücklich als legitimer Weg genannt wird. Sie ist kein Versagen, solange sie bewusst und dokumentiert erfolgt. Und für den häufigen Fall, dass es noch keine dauerhafte Lösung gibt, nennt das Rahmenwerk die vorübergehende Maßnahme — also die Frage, wie sich die Schwachstelle vorläufig entschärfen lässt, bis eine Behebung verfügbar ist.

8:03 Vier Quadranten, vier legitime Wege. Beheben ist der offensichtliche — Version anheben oder Code ändern. Ersetzen wird zu wenig genutzt: Wenn ein Projekt keine Behebung liefert und auch keine liefern wird, ist der Austausch der Komponente die einzige dauerhafte Lösung, und je früher man das erkennt, desto billiger wird es.

8:22 Absichern heißt, eine vorübergehende Maßnahme mit Frist einzuziehen. Und Tragen heißt, das Risiko dokumentiert zu akzeptieren. Wichtig ist bei den letzten beiden das gleiche Wort wie immer in diesem Seminar: mit Frist. Fünf Schritte, und der erste ist der, den man vorher erledigen muss: Fristen je Risikoklasse festlegen, bevor der erste Fall eintritt.

8:43 Wer das im konkreten Fall diskutiert, diskutiert unter Druck. Dann die Entscheidung samt Begründung an einem wiederauffindbaren Ort. Anschließend die Sicherheitsmitteilung: was betroffen ist und wie man es erkennt. Die Fußzeile hebt einen Punkt hervor, der im Rahmenwerk ausdrücklich steht und häufig fehlt — Betroffenen zu sagen, wie sie die Schwachstelle bei sich finden.

9:05 Das ist der Unterschied zwischen einer Mitteilung und einer nützlichen Mitteilung. Der SSDF hat für die Ursachenanalyse einen eigenen Bereich, und der wird in der Praxis fast immer übersprungen. Verlangt wird, Ursachen zu erfassen und sie über die Zeit auf Muster zu prüfen. Dahinter steht eine einfache Beobachtung: Ein wiederkehrendes Muster deutet auf eine Praxis, die nicht durchgehalten wird — und die lässt sich abstellen.

9:29 Aus erkannten Ursachen werden dann Prüfungen in der Werkzeugkette. Und der vierte Punkt ist der proaktive: Ähnliche Stellen werden gesucht, statt auf den nächsten Bericht zu warten. Das ist die einzige Bewegung, die den Rückstand dauerhaft kleiner macht. Der erste Punkt beschreibt, warum Fristen im Ernstfall nicht halten: Sie werden erst im konkreten Fall diskutiert, und dann entscheidet der Termindruck.

9:52 Der zweite ist der Klassiker unter den Übergangslösungen — die vorübergehende Maßnahme bleibt dauerhaft, weil niemand eine Frist gesetzt hat; nach zwei Jahren weiß niemand mehr, wofür sie da war. Der dritte ist ein Kommunikationsfehler mit Vertrauensverlust: Kunden erfahren von der Behebung aus dem Änderungsprotokoll. Und der vierte ist die halbe Ursachenanalyse — Ursachen werden notiert, aber nie über mehrere Fälle hinweg betrachtet, und genau darin läge der Erkenntnisgewinn.

Übung

10:19 In der Übung bekommen Sie eine Trefferliste, die absichtlich länger ist, als ein Team sie abarbeiten kann. Genau das ist die Aufgabe: nicht alles zu bearbeiten, sondern begründet auszuwählen. Und die Begründung muss in vier Wochen noch tragen, wenn jemand fragt, warum ausgerechnet dieser Treffer liegen geblieben ist. Drei Ergebnisse: eine begründete Reihenfolge, zwei belegte Nichtbetroffenheiten und Fristen je Risikoklasse mit Verantwortlicher.

10:45 Der Hinweis nennt die didaktische Absicht offen — die Liste enthält mehr Treffer, als Sie schaffen. Das ist die realistische Lage in jedem Projekt, und wer sie nicht übt, trifft die Auswahl später unter Zeitdruck und ohne Methode. Achten Sie besonders auf die Fristen: Sie sind das Einzige an diesem Ergebnis, das auch dann noch wirkt, wenn die konkrete Liste längst abgearbeitet ist.

11:08 Der erste Schritt ist der, bei dem die meisten schon falsch abbiegen: Abgleich gegen die Stückliste des ausgelieferten Artefakts, nicht des Quellstands. Dann die Trennung von Produktions- und Testabhängigkeiten — dieser eine Schritt halbiert in vielen Projekten die Liste. Anschließend je Treffer Erreichbarkeit, bekannte Ausnutzung und Auswirkung notieren. Dann zwei Nichtbetroffenheiten belegt begründen.

11:31 Und zuletzt Fristen je Risikoklasse mit Verantwortlichen. Die Fußzeile beschreibt das Qualitätsmerkmal: eine Reihenfolge, die sich auch in vier Wochen noch begründen lässt. Der erste Punkt ist die Versuchung, der man unter Zeitdruck erliegt: Die Reihenfolge folgt dem Punktwert, weil das schneller geht als nachzudenken. Der zweite ist die ausgelassene Trennung nach Produktions- und Testcode, die den Aufwand verdoppelt. Der dritte ist der Fristenfehler — Fristen ohne Person sind Wünsche.

12:00 Und der vierte kostet Sie die Arbeit ein zweites Mal: Die Bewertung wird nicht festgehalten und muss beim nächsten Lauf neu gemacht werden. Genau dagegen ist VEX gebaut. Im nächsten Modul kümmern wir uns darum, dass diese ganze Kette auch nachweisbar wird.