Grundlagen der Software Bill of Materials

Grundlagen der Software Bill of Materials

0:00 Die Stückliste ist in den letzten Jahren zum Symbol für Lieferkettensicherheit geworden — und damit auch ein Stück weit überfrachtet. Deshalb beginne ich dieses Modul mit einer Einschränkung, die Sie im Hinterkopf behalten sollten: Eine Stückliste beantwortet keine einzige Sicherheitsfrage. Sie macht die Frage überhaupt erst stellbar. Wenn morgen eine Schwachstelle in einer verbreiteten Bibliothek gemeldet wird, lautet die erste Frage: Betrifft uns das?

0:26 Ohne Stückliste beginnt dann eine Suche. Mit Stückliste beginnt eine Bewertung. Das ist der ganze Unterschied — und er ist beträchtlich.

Grundlagen der Software Bill of Materials

0:35 In diesem Modul geht es um die Grundlagen, im nächsten um die praktische Arbeit mit den beiden Formaten. Drei Fragen klären wir hier: Was gehört überhaupt in eine Stückliste und welche Angaben tragen ihre Aussagekraft? Wie ehrlich ist sie — also wie geht sie mit dem um, was sie nicht weiß? Und die praktisch wichtigste: An welcher Stelle im Ablauf erzeugt man sie, und wer bekommt sie anschließend?

Zweck und Inhalt einer SBOM

0:58 Fangen wir mit dem Inhalt an. Eine Stückliste ist mehr als eine Namensliste, und ihr Wert hängt fast vollständig daran, welche Angaben je Komponente enthalten sind. Die Unterschiede zwischen einer nützlichen und einer nutzlosen Liste sind im Detail erstaunlich klein — und in der Wirkung erstaunlich groß. SPDX bildet die Stückliste als Modell aus Elementen ab, und die Struktur ist gut durchdacht. Es gibt Artefakte — Pakete, Dateien und sogar Ausschnitte daraus.

1:25 Es gibt Beziehungen zwischen ihnen. Es gibt Akteure, die als Person, Organisation oder Werkzeug auftreten können. Dazu kommen Prüfsummen und externe Bezeichner. Das Bild aus der Industrie trägt auch hier: Eine Stückliste im Maschinenbau nennt nicht nur die Teile, sondern auch, welches Teil in welche Baugruppe gehört und von welchem Zulieferer es stammt.

1:47 Genau diese drei Ebenen finden Sie hier wieder. Fünf Angaben, und die rechte Spalte zeigt, was ohne sie verloren geht. Ohne Name und Version gibt es keine Zuordnung — die Liste ist dann Dekoration. Ohne Lieferant und Urheber wissen Sie im Ernstfall nicht, an wen Sie sich wenden. Ohne Bezugsquelle lässt sich die Herkunft nicht prüfen.

2:07 Ohne Prüfsumme bleibt der Austausch unbemerkt — das ist der Fall „gleiche Version, anderer Inhalt" aus Modul fünf. Und die Lizenzangaben sind kein Nebenthema: Eine Stückliste, die nur als Sicherheitswerkzeug gedacht wurde, lässt die Rechtsabteilung zurück. Die Fußzeile nennt die Verbindung zu den Schwachstellendatenbanken — die externen Bezeichner.

2:29 Drei Schichten, und die mittlere ist die, die den Unterschied macht. Elemente sind die benannten Artefakte — das erwartet man. Beziehungen sagen, wie sie zusammenhängen: enthält, hängt ab von, wurde erzeugt aus. Und die Erzeugungsangaben halten fest, wer die Liste wann womit erstellt hat. Diese dritte Schicht wird gern übersehen und beantwortet später die Frage, warum zwei Werkzeuge verschiedene Ergebnisse liefern.

2:53 Wenn Sie eine fremde Stückliste bekommen, schauen Sie zuerst hier hin — das erzeugende Werkzeug und der Zeitpunkt sagen Ihnen mehr über ihre Aussagekraft als die Länge der Liste. Eine flache Liste sagt Ihnen, dass etwas da ist. Sie sagt Ihnen nicht, warum. Und genau diese Frage entscheidet über Ihre Handlungsmöglichkeiten: Wenn eine Komponente als transitive Abhängigkeit dritter Ebene hereinkam, können Sie sie nicht einfach austauschen — Sie müssen an die direkte Abhängigkeit heran, die sie mitbringt.

3:23 Die Beziehungen trennen also das, was Sie selbst entscheiden können, von dem, was Sie beim Zulieferer adressieren müssen. Dazu kommt eine Feinheit des Modells: Beziehungen können eine Angabe zur Vollständigkeit tragen. Sie können also ausdrücken, dass eine Liste an dieser Stelle nicht abschließend ist. Der erste Punkt beschreibt die Stückliste, die man in der Praxis am häufigsten vorgelegt bekommt: eine Namensliste ohne Versionen, ohne Prüfsummen, ohne Beziehungen.

3:50 Sie erfüllt eine Anforderung und beantwortet keine Frage. Der zweite ist ein technisches Detail mit großer Wirkung — ohne eindeutigen Bezeichner lässt sich eine Komponente nicht zuverlässig einer Schwachstelle zuordnen; dann suchen Sie über Namensähnlichkeit. Der dritte ist die vergessene Lizenzsicht. Und der vierte ist der Ursprung der meisten Mängel: Niemand hat je festgelegt, was in die Liste gehört und was nicht.

Aussagekraft und Aktualität

4:14 Im zweiten Kapitel geht es um Ehrlichkeit. Jede Stückliste hat Lücken — die Frage ist nur, ob man sie sieht. Und sie hat ein Ablaufdatum, auch wenn keines darauf steht. Beides entscheidet darüber, wie viel eine Liste im Ernstfall wert ist. Das Modell kennt ausdrückliche Werte für zwei verschiedene Fälle: für eine Aussage, die nicht getroffen wurde, und für eine Angabe, die nicht zutrifft.

4:39 Das ist mehr als Formalität — es ist der Unterschied zwischen „wir wissen es nicht" und „gibt es hier nicht". Dazu kommen die Erzeugungsangaben mit dem Zeitpunkt. Beides zusammen entscheidet über die Aussagekraft, und ich formuliere es bewusst zugespitzt: Eine Lücke, die als Lücke markiert ist, ist etwas grundlegend anderes als eine verschwiegene.

4:59 Die erste können Sie bewerten. Die zweite merken Sie erst, wenn es zu spät ist. Drei Kästen, und der Weg von links nach rechts beschreibt abnehmende Sicherheit. Erfasste Komponenten sind der einfache Fall. Als unbekannt markierte sind der ehrliche Fall — Sie wissen, dass hier etwas ist, und wissen nicht genau was. Und gar nicht erfasste sind der gefährliche Fall, weil die Liste vollständig aussieht und es nicht ist.

5:23 In der Praxis entsteht die dritte Gruppe meist nicht durch Absicht, sondern durch die Grenzen des erzeugenden Werkzeugs. Deshalb der Rat von vorhin: Schauen Sie nach, womit eine Liste erzeugt wurde. Der erste Punkt ist der, der im Alltag am meisten schiefgeht: Die Liste gilt für den Stand, aus dem sie erzeugt wurde — nicht für den von heute.

5:43 Eine Stückliste ist damit eher ein Foto als ein Live-Bild. Der zweite Punkt macht daraus eine harte Anforderung: Ohne Erzeugungszeitpunkt lässt sie sich keinem Release zuordnen, und dann ist sie praktisch wertlos. Die letzten beiden Punkte grenzen ab, was sie nicht leistet: Sie sagt nichts über Schwachstellen — sie erlaubt nur, danach zu fragen.

6:03 Und sie sagt nichts darüber, ob eine Komponente im Betrieb überhaupt erreichbar ist. Diese Übung dreht die Perspektive um: Sie sind einmal der Empfänger. Das lohnt sich, weil Sie in Modul sechzehn Stücklisten an Kunden herausgeben werden — und weil man die eigenen Mängel an fremden Listen schneller erkennt. Der Hinweis gibt Ihnen die Abkürzung: Schauen Sie zuerst nach dem Erzeugungszeitpunkt und nach den Bezeichnern.

6:27 An diesen beiden Punkten scheitern die meisten Listen, die im Umlauf sind. Und formulieren Sie zu jedem Mangel, welche Frage dadurch unbeantwortbar bleibt — das ist die Übersetzung von Formfehler in Geschäftsrisiko. Der erste Punkt ist die verbreitetste Fehlvorstellung: Die Liste wird einmal zum Release erzeugt und gilt danach als dauerhaft gültig.

6:47 Der zweite ist die stille Unehrlichkeit — Unbekanntes wird weggelassen statt markiert, weil eine vollständige Liste besser aussieht. Der dritte ist eine Verwechslung, die in Ausschreibungen vorkommt: Die Stückliste wird als Sicherheitsnachweis vorgelegt, obwohl sie nur Bestand beschreibt. Und der vierte ist der schlichte Formfehler mit der größten Wirkung: Der Erzeugungszeitpunkt fehlt, und niemand kann die Liste einem Artefakt zuordnen.

Erzeugungspunkte und Weitergabe

7:12 Kommen wir zum praktisch wichtigsten Kapitel. Die Frage, an welcher Stelle eine Stückliste entsteht, wird meist nebenbei entschieden — nämlich dort, wo das Werkzeug gerade lief. Dabei bestimmt genau diese Entscheidung, welche Frage die Liste später beantworten kann. Drei Erzeugungspunkte kommen in Frage: der Quellstand, das Build-Artefakt und das fertige Container-Image. Die drei beantworten verschiedene Fragen und stimmen nie ganz überein.

7:38 Und jetzt kommt der Satz, der diesem Modul seinen Wert gibt: Die Unterschiede sind kein Fehler, sondern die Information. Wenn die Image-Stückliste Komponenten enthält, die in der Quellstand-Stückliste fehlen, dann sagt Ihnen das etwas über das, was der Build und das Basis-Image hinzufügen. Wer nur eine Liste erzeugt, verschenkt diese Erkenntnis.

7:59 Die Tabelle zeigt, was jede Sicht enthält und was ihr fehlt. Der Quellstand kennt die erklärten Abhängigkeiten, nicht aber das, was der Build hinzufügt. Das Build-Artefakt kennt den tatsächlich eingebundenen Code, aber keine Betriebssystempakete. Das Container-Image kennt alles bis hinunter zum Basis-Image — dafür fehlt ihm der Bezug zum Quellstand, also die Verbindung zu einem Commit.

8:21 Die Fußzeile zieht die praktische Folgerung: Für den Betreiber zählt das Image, für die Ursachensuche der Quellstand. Deshalb lohnen sich beide, und deshalb gehören sie über den Digest miteinander verbunden. Machen wir uns klar, was wir da herausgeben: Eine Stückliste legt die inneren Bestandteile eines Produkts offen. Das ist gewollt — es ist der ganze Zweck — aber es ist eben auch eine Offenlegung.

8:46 Deshalb gehört der Umfang je Empfänger festgelegt: Betrieb, Kunde und Prüfstelle fragen Verschiedenes. Der dritte Punkt ist ein praktischer Rat, der viel Ärger erspart: Die Liste gehört neben das Artefakt, damit Version und Liste zusammenbleiben. Und der vierte greift auf Modul zwölf vor — eine signierte Stückliste ist gegen Veränderung auf dem Weg geschützt.

9:07 Der erste Punkt ist die Folge der Nebenbei-Entscheidung: Es gibt eine Stückliste, und niemand weiß, welche Sicht sie zeigt. Der zweite ist der Ablagefehler aus Modul acht, diesmal für Stücklisten: Sie liegt im Build-Lauf und ist mit dessen Verfall verschwunden. Der dritte ist ein Klassiker der Weitergabe — sie wird per Mail verteilt und existiert danach in vier Fassungen, von denen niemand sagen kann, welche aktuell ist.

9:31 Und der vierte ist die Überreaktion: Die Weitergabe wird pauschal verboten, statt den Umfang je Empfänger zu regeln. Damit ist die Arbeit gemacht und der Nutzen null.

Übung

9:41 In der Übung erzeugen Sie alle drei Sichten für die Deichwacht und vergleichen sie. Die Zahlen werden auseinandergehen — das ist erwartet. Interessant wird es, wenn Sie erklären, warum. Und am Ende steht eine Entscheidung, die in der Praxis oft niemand trifft: Welche Sicht bekommt eigentlich der Betreiber? Drei Läufe, drei Zahlen, und dann die Erklärung der Differenzen. Das Erfolgskriterium ist bewusst scharf formuliert: Die Abweichungen sind erklärt, nicht nur festgestellt.

10:10 Wenn Sie sagen können „hier kommen dreihundert Betriebssystempakete aus dem Basis-Image dazu" und „hier fehlen die Testabhängigkeiten, weil sie nicht ins Artefakt gelangen", dann haben Sie das Prinzip verstanden. Und die Entscheidung, welche Sicht der Betreiber der Deichwacht bekommt, gehört ausdrücklich zum Ergebnis — mit einer Begründung, die auch in einem Kundengespräch trägt.

10:32 Drei Erzeugungsläufe, jeweils mit Zählung — die Zahlen notieren Sie, sie sind Ihr Vergleichsmaß. Dann die Differenzen benennen und ihre Ursache erklären. Und zum Schluss die Weitergabeentscheidung. Die Fußzeile enthält einen nützlichen Selbsttest: Wer die Differenz nicht erklären kann, hat eine der drei Stücklisten falsch erzeugt.

10:51 Das klingt hart, ist aber meist zutreffend — typischerweise wurde dann aus dem Quellstand statt aus dem Artefakt erzeugt oder ein Bereich ausgeschlossen, ohne dass es jemandem auffiel. Der erste Punkt ist die Abkürzung, die den Lerneffekt kostet: Die Zahlen werden verglichen, ohne in die Listen zu sehen. Der zweite ist ein naheliegender Trugschluss — die Image-Stückliste wirkt am vollständigsten, also verwirft man die anderen.

11:16 Dabei fehlt ihr genau die Verbindung zum Quellstand, die Sie in der Untersuchung brauchen. Der dritte betrifft die Weitergabe: Sie fällt implizit, weil eine Datei zufällig öffentlich liegt. Und der vierte ist ein Versuchsaufbaufehler — die drei Läufe erfolgen zu verschiedenen Ständen und sind damit nicht vergleichbar. Im nächsten Modul werden diese Listen dann konkret.