Software-Stücklisten (SBOM): das Inventar der eigenen Lieferkette

Worum es geht

Eine Software-Stückliste (Software Bill of Materials, SBOM) ist die Teileliste eines Softwareprodukts: Pakete, Versionen, Lieferanten, Lizenzen, Prüfsummen und die Beziehungen zwischen ihnen («enthält», «hängt ab von»). Zwei Formate haben sich durchgesetzt. SPDX der Linux Foundation ist nach Angaben der Projektseite als ISO/IEC 5962:2021 ein frei verfügbarer internationaler Standard; seine Wurzeln liegen in der Lizenzverwaltung. CycloneDX ist ein OWASP-Projekt, laut Projektseite als ECMA-424 standardisiert, das neben der SBOM auch Stücklisten für Dienste, Hardware und Kryptografie sowie den Vulnerability Exploitability eXchange (VEX) beschreibt – ein Dokument, mit dem ein Hersteller mitteilt, ob eine gemeldete Schwachstelle in seinem Produkt tatsächlich ausnutzbar ist. Ergänzend beschreibt das SLSA-Rahmenwerk Stufen für den Herkunftsnachweis (provenance): eine Aussage darüber, welcher Build aus welcher Quelle das Artefakt erzeugt hat.

Warum es wichtig ist

Wird eine Schwachstelle in einer verbreiteten Bibliothek bekannt, lautet die erste Frage: Wo läuft diese Version? Ohne Stückliste heisst die Antwort «alle Projekte neu bauen und durchsuchen», mit Stückliste ist es eine Abfrage über abgelegte Dateien. Dasselbe Inventar beantwortet Lizenzfragen (Namensnennung, Copyleft) und wird nach verbreiteten Berichten zunehmend als Liefergegenstand verlangt. Eine Stückliste allein sagt aber nicht, ob eine Komponente unverändert und aus der erwarteten Quelle stammt; dafür braucht es den Herkunftsnachweis.

So wird es angewendet

• Die Stückliste im Release-Lauf erzeugen, und zwar aus dem gebauten Artefakt (Container-Image, Wheel, JAR), nicht nur aus der Manifestdatei: Nur so erscheinen Basisimage, Systempakete und Bündelungen, die das Manifest nicht kennt.
• Ein Format intern festlegen und das andere bei Bedarf exportieren; beide Projekte pflegen Werkzeuglisten und Konverter.
• Die Datei neben dem Artefakt ablegen, mit derselben Versionskennung, und signieren, wenn Artefakte signiert werden.
• Die Stücklisten aller ausgelieferten Versionen regelmässig gegen Schwachstellendatenbanken abgleichen; Treffer, die nach Prüfung nicht ausnutzbar sind, als VEX-Aussage festhalten, damit derselbe Treffer nicht jede Woche neu bewertet wird.
• Lizenzregeln als automatische Prüfung über die Stückliste formulieren (erlaubte, zu prüfende, verbotene Lizenzen).
• Lockfiles und hashgeprüfte Installationen beibehalten; die Stückliste dokumentiert, sie erzwingt nichts.

Stolpersteine

Eine aus dem Quellmanifest erzeugte Stückliste weicht vom Inhalt des Images ab. Stücklisten altern: Sie gelten für genau einen Build, nicht für «die Anwendung». Werkzeuge erkennen einkopierte oder umbenannte Bibliotheken oft nicht. Ein Treffer im Abgleich ist eine Frage, keine Diagnose – erst die Prüfung, ob der verwundbare Pfad im eigenen Produkt erreichbar ist, entscheidet über die Dringlichkeit, und genau dafür ist VEX gedacht.