Fast jedes kleine Softwareteam hat eine Liste seiner Abhängigkeiten. Sie steht in einer Excel-Tabelle, in einer README oder im Kopf des Entwicklers, der am längsten dabei ist. Diese Liste ist der Anfang einer Software-Stückliste. Der Schritt zum echten SBOM ist kleiner, als die Abkürzung vermuten lässt. Er lohnt sich, sobald der erste Kunde nach einer Aufstellung fragt oder ein Sicherheitsvorfall bei einer bekannten Bibliothek durch die Nachrichten geht.
Was in vielen Teams heute die Stückliste ist
Ein SBOM, kurz für Software Bill of Materials, ist nichts anderes als eine vollständige Aufstellung dessen, was in einer Software steckt. Welche Bibliotheken, in welcher Version, mit welcher Lizenz, aus welcher Quelle. Viele Teams führen davon eine handgepflegte Variante. Die Datei heißt dann Abhängigkeiten.xlsx und wird aktualisiert, wenn jemand daran denkt. Das Problem ist nicht die Idee, sondern die Pflege. Eine Liste, die von Hand entsteht, ist am Tag ihrer Erstellung schon veraltet.
Warum die Excel-Liste irgendwann kippt
Moderne Software besteht selten aus zwanzig Bibliotheken. Wer ein durchschnittliches Node- oder Python-Projekt aufmacht, findet nach dem Auflösen aller transitiven Abhängigkeiten schnell mehrere hundert Pakete. Die direkten Abhängigkeiten kennt das Team. Die indirekten, also die Abhängigkeiten der Abhängigkeiten, kennt niemand vollständig. Genau dort sitzen die meisten Überraschungen. Eine Excel-Liste erfasst die Spitze des Eisbergs. Ein automatisch erzeugtes SBOM erfasst den ganzen Berg.
Der zweite Bruch kommt bei der Aktualität. Jede neue Version, jeder Austausch einer Bibliothek, jedes Update verändert die Stückliste. Von Hand hält niemand damit Schritt. Das ist keine Frage der Disziplin, sondern der Frequenz. Was sich mit jedem Commit ändern kann, muss mit jedem Commit erzeugt werden.
Der erste automatische SBOM ist kleiner als gedacht
Der Einstieg braucht kein großes Werkzeug und kein Budget. Für die verbreiteten Ökosysteme gibt es freie Generatoren, die aus dem vorhandenen Projekt eine Stückliste im Standardformat erzeugen. Syft ist ein solches Werkzeug, es liest ein Verzeichnis oder ein Container-Image und schreibt ein SBOM im Format CycloneDX oder SPDX. Beide Formate sind maschinenlesbar und werden von Prüfwerkzeugen und Kunden akzeptiert. Ein erster Lauf dauert Sekunden und produziert eine Datei, die den handgepflegten Stand sofort überholt.
Wichtig ist die Wahl eines Standardformats von Anfang an. Ein eigenes Format in Excel bindet die Liste an ein Programm und an einen Menschen. CycloneDX und SPDX sind offen, versioniert und lassen sich weiterverarbeiten. Wer heute in einem Standard startet, muss später nichts übersetzen.
Was ein SBOM können muss, damit es trägt
Eine Stückliste hat nur dann Wert, wenn sie zu einem konkreten Stand der Software gehört. Ein SBOM, das nicht sagt, zu welcher Version und zu welchem Build es passt, ist eine Momentaufnahme ohne Bezug. Deshalb gehört die Erzeugung in die Pipeline und nicht auf einen Rechner. Bei jedem Build entsteht ein SBOM, das an genau dieses Artefakt gebunden ist. So lässt sich später jede Frage nach dem Inhalt einer ausgelieferten Version ohne Rätselraten beantworten.
Der zweite Prüfstein ist die Nutzbarkeit. Ein SBOM ist kein Selbstzweck. Sein Sinn zeigt sich in dem Moment, in dem eine Schwachstelle in einer weit verbreiteten Bibliothek bekannt wird. Dann ist die einzige relevante Frage: sind wir betroffen und wo. Wer sein SBOM automatisch erzeugt und ablegt, beantwortet das mit einer Suche. Wer es nicht hat, beginnt mit Archäologie.
Der pragmatische Einstieg in drei Schritten
Erstens: einmal von Hand einen Generator über das Projekt laufen lassen und das Ergebnis mit der Excel-Liste vergleichen. Die Lücke zwischen beiden ist der eigentliche Erkenntnisgewinn. Zweitens: die Erzeugung in die Pipeline hängen, sodass bei jedem Build ein SBOM entsteht und als Artefakt gespeichert wird. Drittens: das gespeicherte SBOM regelmäßig gegen eine Schwachstellendatenbank prüfen, damit aus der Liste eine Warnung wird, bevor der Kunde anruft.
Keiner dieser Schritte ist groß. Zusammen ersetzen sie eine Datei, die nie aktuell war, durch einen Nachweis, der sich selbst pflegt. Das ist der Unterschied zwischen einer Liste, die man führt, und einer Stückliste, die entsteht.
Sie wollen wissen, wie belastbar Ihre Abhängigkeiten und Ihr Build-Prozess wirklich sind? Der GitSecOps QuickCheck prüft Ihre Pipeline auf die häufigsten Lücken und liefert einen konkreten Befund. 1.990 Euro netto, Ergebnis in 3 Werktagen. Kontakt: mm@crank.zone.
Dein Blog zum Thema digitales Business 
Hinterlasse einen Kommentar