SPDX und CycloneDX praktisch einsetzen

SPDX und CycloneDX praktisch einsetzen

0:00 Wir haben im letzten Modul geklärt, was in eine Stückliste gehört. Jetzt wird es konkret: Es gibt zwei etablierte Formate, und die erste Frage jedes Teams lautet, welches davon das richtige ist. Ich nehme die Antwort vorweg, weil sie Zeit spart: Die Frage stellt sich in der Praxis seltener, als man denkt. Meist gibt der Empfänger das Format vor — und wer mehrere Empfänger hat, braucht beide.

0:24 Interessanter ist deshalb die zweite Frage, und um die geht es hier: Wie wird eine Stückliste erzeugt, die auch etwas taugt?

SPDX und CycloneDX praktisch einsetzen

0:32 Drei Schritte. Zuerst die beiden Formate im Vergleich, samt ihrer Normung — die wird in Ausschreibungen zitiert und lohnt deshalb einen Blick. Dann die Erzeugung im Build und, mindestens ebenso wichtig, die Prüfung des Ergebnisses gegen das Schema. Und schließlich der Teil, in dem die Arbeit sich auszahlt: der Vergleich zweier Releases. Denn die erste Stückliste kostet nur Aufwand. Ihren Nutzen entfaltet sie beim zweiten Mal.

Die beiden Formate

0:58 Beginnen wir mit einem Blick auf die Formate selbst. Beide sind internationale Standards, beide beschreiben deutlich mehr als nur Software — und in ihren Schwerpunkten unterscheiden sie sich so, dass die Wahl je nach Zweck tatsächlich einen Unterschied macht. SPDX ist als internationaler offener Standard unter ISO/IEC 5962 normiert; die aktuelle Linie ist Version 3 mit Profilen für Kern, Software, Sicherheit, Lizenzierung, Build, Datensätze und KI.

1:25 Diese Profilstruktur ist der Kern der dritten Version — sie erlaubt, dieselbe Grundstruktur für sehr verschiedene Gegenstände zu nutzen. CycloneDX liegt in Version 1.7 vor und ist als ECMA-424 standardisiert, entwickelt von der OWASP Foundation gemeinsam mit Ecma International. Zwei ernsthaft gepflegte Standards also, hinter denen jeweils eine Normungsorganisation steht.

1:49 Das ist keine Selbstverständlichkeit und macht beide für vertragliche Zusagen brauchbar. Die Zeilen zeigen, wo die Schwerpunkte liegen. SPDX baut Profile über einem Kernmodell, CycloneDX gliedert eine Stückliste in Abschnitte. SPDX reicht über Software hinaus bis zu Datensätzen und KI-Modellen, CycloneDX deckt Software, Hardware, maschinelles Lernen und Dienste ab.

2:13 Beim Thema Schwachstellen ist CycloneDX besonders ausgeprägt: Es hat einen eigenen Abschnitt, der auch VEX abbildet — das Thema des nächsten Moduls. Die Fußzeile enthält den praktischen Rat: Die Wahl fällt selten frei. Meist gibt der Empfänger das Format vor, und dann werden beide gebraucht. Vier Schichten, und die oberste ist die, die am häufigsten leer bleibt.

2:35 Die Metadaten nennen Hersteller, Zielkomponente und die erzeugenden Werkzeuge — ohne sie schwebt die Liste ohne Bezug. Darunter das Inventar aus Komponenten und Diensten samt Herkunft und Lizenz. Dann die Abhängigkeiten mit direkten und transitiven Beziehungen — die Schicht, über die wir im letzten Modul gesprochen haben.

2:54 Und ganz unten Schwachstellen und Angaben zur Vollständigkeit. Beachten Sie, dass eine Stückliste hier ausdrücklich ausdrücken kann, wie vollständig sie ist. Das ist gelebte Ehrlichkeit im Datenmodell. Der erste Punkt ist der praktisch wichtigste: Eine Stückliste benennt in ihren Metadaten die Komponente, die sie beschreibt. Ohne diese Angabe passt sie zu jedem und zu keinem.

3:17 Über Prüfsummen wird sie dann an genau ein Artefakt gebunden — das ist der Unterschied zwischen „eine Liste zu diesem Produkt" und „die Liste zu diesem Digest". Der dritte Punkt greift auf Modul zwölf vor: CycloneDX ist ein anerkannter Aussagetyp für Attestierungen. Und der vierte zieht die Linie, die dieses Seminar trägt — erst diese Bindung erlaubt es, Stückliste, Provenance und Signatur zusammenzuführen.

3:42 Der erste Punkt beschreibt, wie die Formatwahl meist wirklich getroffen wird: Das Werkzeug kann es, also nimmt man es — und hinterher passt es nicht zu dem, was der Kunde liest. Der zweite ist der Metadatenfehler von eben, und er ist überraschend häufig. Der dritte betrifft die Beziehungen: Der Abschnitt bleibt leer, die Liste wird flach, und damit verlieren Sie genau die Aussage, die Sie in Modul elf brauchen.

4:05 Und der vierte ist ein Prozessfehler mit garantierter Verwirrung — beide Formate werden erzeugt, aber aus verschiedenen Ständen.

SBOMs im Build erzeugen und prüfen

4:13 Jetzt zur Praxis. Das Erzeugen ist in den meisten Ökosystemen eine Zeile, und genau das ist die Gefahr: Es fühlt sich erledigt an. Die eigentliche Arbeit liegt in der Prüfung — und in der Frage, was das Werkzeug eigentlich nicht gesehen hat. Drei Befehle, die drei verschiedene Dinge tun. Der erste erzeugt aus dem Projekt heraus eine Stückliste — der Build kennt die aufgelösten Abhängigkeiten, also ist das die genaueste Quelle für diese Sicht.

4:39 Der zweite nimmt sich das fertige Image vor und liefert damit die Betriebssystempakete mit; man beachte, dass hier ein anderes Werkzeug und eine andere Sicht im Spiel sind. Und der dritte validiert gegen das Schema. Die Fußzeile nennt den Grund, warum der dritte Befehl in denselben Schritt gehört: Eine ungeprüfte Stückliste fällt sonst erst beim Empfänger auf.

5:00 Drei Fragen und ein Zusatz. Vollständigkeit: Sind alle Komponenten erfasst, auch die mitgezogenen? Genauigkeit: Tragen sie eindeutige Bezeichner, Versionen und Prüfsummen? Aktualität: Stammt die Liste aus genau dem Stand, der ausgeliefert wird? Diese drei sind das Maß, an dem auch ein Kunde Ihre Liste messen wird. Der Zusatz ist der, den wir aus dem letzten Modul kennen und der die Liste erst ehrlich macht: Was nicht ermittelbar war, steht als unbekannt darin, statt einfach zu fehlen.

5:30 Eine Liste mit markierten Lücken ist wertvoller als eine scheinbar lückenlose. Fünf Prüfschritte, die Sie einmal manuell durchgehen sollten, bevor Sie sie automatisieren. Tragen alle Komponenten einen eindeutigen Bezeichner? Fehlen Lieferanten- und Lizenzangaben, und lassen sie sich nachziehen oder wenigstens als unbekannt markieren? Trennen die Beziehungen direkte von transitiven Einträgen?

5:54 Steht die erzeugende Werkzeugversion in den Metadaten? Und validiert die Liste gegen ihr Schema? Die Fußzeile nennt die Grenze, die bleibt: Werkzeuge sehen nur, was ihre Erkennung abdeckt. Alles andere fehlt still — und deshalb ist der erste Durchgang von Hand so lehrreich. Der erste Punkt ist die Reihenfolgefalle: Die Liste entsteht nach dem Release aus dem Quellstand, weil jemand sie angefordert hat.

6:19 Dann beschreibt sie etwas anderes als das Ausgelieferte. Der zweite ist die ausgelassene Validierung — Schemafehler fallen erst beim Kunden auf, und das ist ein unnötig peinlicher Moment. Der dritte klingt nach Kleinigkeit und ist es nicht: Ohne die erzeugende Werkzeugversion lassen sich Abweichungen zwischen zwei Listen nicht erklären.

6:37 Und der vierte ist die stille Lücke — statisch eingebundene Bestandteile fehlen, weil das Werkzeug sie nicht erkennt.

SBOMs vergleichen und verteilen

6:44 Jetzt kommt der Teil, für den sich die ganze Arbeit lohnt. Eine einzelne Stückliste ist eine Bestandsaufnahme. Zwei aufeinanderfolgende Stücklisten sind ein Überwachungsinstrument — und zwar eines, das Dinge sichtbar macht, die in keinem Änderungsprotokoll stehen. Der Vergleich zweier Stücklisten benachbarter Releases zeigt, was sich im Inneren des Produkts verändert hat — und zwar unabhängig davon, ob jemand diese Änderung beabsichtigt hat.

7:10 Genau das ist der Punkt. Eine neue Komponente ohne zugehörige Codeänderung ist exakt die Beobachtung, um die es in diesem Seminar geht. Sie kann harmlos sein: ein Patch einer Bibliothek bringt eine neue Abhängigkeit mit. Sie kann aber auch der erste sichtbare Hinweis auf etwas sein, das niemand bestellt hat. In beiden Fällen wollen Sie es wissen.

7:31 Vier Quadranten, vier Beobachtungen. Neu: Eine Komponente ist dazugekommen, mit oder ohne Absicht. Entfallen: Eine ist verschwunden — auch das will erklärt sein, denn es kann heißen, dass ein Werkzeug sie nicht mehr erkennt. Version geändert: Sprungweite und Änderungsprotokoll ansehen. Und der vierte Quadrant, der interessanteste: gleiche Version, andere Prüfsumme.

7:54 Halten Sie kurz inne bei diesem Fall — er bedeutet, dass unter derselben Bezeichnung ein anderer Inhalt liegt als beim letzten Mal. Gleiche Version bei anderer Prüfsumme heißt: Der Inhalt wurde ausgetauscht. Das kann legitime Gründe haben — manche Ökosysteme erlauben es, ein Paket unter derselben Version neu zu veröffentlichen.

8:14 Aber es ist eben auch genau das Muster, das ein untergeschobenes Paket hinterlässt. Und es steht in keinem Änderungsprotokoll, weil sich die Versionsnummer nicht geändert hat. Der zweite Punkt relativiert sinnvoll: Eine neue transitive Komponente kann aus einem völlig harmlosen Patch stammen. Der dritte ist ein Werkzeugthema.

8:33 Und der vierte nennt die Alternative zum Vergleich: Man erfährt es, wenn eine Schwachstelle gemeldet wird. Das Erfolgskriterium ist bewusst so formuliert, dass nichts unbearbeitet bleibt: Jede Abweichung ist entweder auf eine bewusste Änderung zurückgeführt oder als offener Punkt mit Verantwortlicher notiert. Es gibt keinen dritten Zustand — „ist wohl nichts" zählt nicht. Der Hinweis lenkt den Blick auf den vierten Quadranten: gleiche Versionen mit abweichender Prüfsumme.

9:01 Diese Fälle finden Sie nur, wenn Sie gezielt danach suchen, denn sie fallen in keiner Sortierung nach Namen oder Versionen auf. Der erste Punkt ist die bequemste Art, den Vergleich zu entwerten: Verglichen wird die Zahl der Komponenten statt der Liste. Zwei Listen können gleich lang und trotzdem verschieden sein. Der zweite ist ein Ablageproblem mit Folgen — die Vorgänger-Stückliste ist nicht auffindbar, weil sie im Build-Lauf lag.

9:25 Der dritte ist eine Denkfalle, die im Alltag oft greift: Abweichungen werden abgehakt, weil der Build grün war; nur prüft der Build nicht, ob eine Komponente dazukommen durfte. Und der vierte greift auf Modul zwölf vor — unsigniert weitergegeben ist die Liste auf dem Weg veränderbar.

Übung

9:42 In der Übung erzeugen Sie beide Formate, validieren sie und vergleichen gegen den Vorgängerstand. Achten Sie besonders auf eine Sache: Beide Läufe müssen denselben Stand beschreiben. Sonst vergleichen die nächsten Übungen Äpfel mit Birnen, und das fällt erst in Modul zwölf auf, wenn die Digests nicht zusammenpassen. Drei Tätigkeiten, ein Ergebnis: Je eine validierte Stückliste in beiden Formaten liegt neben dem Artefakt — nicht im Build-Lauf, nicht im Repository, sondern neben dem Artefakt.

10:10 Das ist die Stelle, an der sie auch in einem Jahr noch jemand findet. Und jede Abweichung zum Vorgängerstand ist begründet oder als offen markiert. Wenn Sie diese Übung abgeschlossen haben, sind Sie in der Lage, die häufigste Kundenfrage dieses Jahrzehnts zu beantworten: Ist diese Bibliothek bei Ihnen im Einsatz? Beide Formate als Schritt des Builds erzeugen — nicht von Hand, sonst passiert es beim nächsten Release nicht. Beide validieren und Befunde beheben. Neben dem Artefakt ablegen.

10:39 Gegen den Vorgängerstand vergleichen. Und jede Abweichung begründen oder als offenen Punkt notieren. Die Fußzeile zieht die Linie zum nächsten Modul: Am Ende trägt jedes Artefakt seine Stückliste — und genau das ist die Voraussetzung dafür, dass wir gleich Schwachstellen zuordnen und später Stücklisten mitsignieren können.

10:59 Der erste Punkt ist der Versuchsaufbaufehler, der die ganze Kette durcheinanderbringt: Die beiden Formate entstehen in verschiedenen Schritten aus verschiedenen Ständen. Der zweite ist ein verbreiteter Trugschluss — die Validierung wird übersprungen, weil das Werkzeug keinen Fehler gemeldet hat; ein Erzeugungswerkzeug prüft aber nicht gegen das Schema, es schreibt nur.

11:19 Der dritte ist eine Gewohnheitsfalle: Der Vergleich unterbleibt beim ersten Release, weil es nichts zu vergleichen gibt, und wird danach nie eingeführt. Und der vierte ist der Ablageort — im Repository statt neben dem Artefakt in der Registry.