Seminar CRA – SBOM, Komponentenbewertung und Software-Lieferkette

Eine Software-Stückliste wird erst dann nützlich, wenn sie den tatsächlich ausgelieferten Produktstand beschreibt und in Entscheidungen einfließt. Das Seminar führt von der Erzeugung einer SBOM über ihre fachliche Prüfung bis zur Bewertung einer neu bekannt gewordenen Komponentenschwachstelle. Anwendungen, Container und enthaltene Bibliotheken werden gemeinsam betrachtet.

Die Arbeit verbindet technische Inventarisierung mit Lieferanteninformationen, Freigaben und laufender Pflege. Unterschiedliche Datenformate und Erfassungsmethoden werden anhand ihrer Aussagekraft verglichen. Der Fokus liegt auf wiederholbaren Abläufen, klaren Verantwortlichkeiten und nachvollziehbaren Aussagen zur Betroffenheit konkreter Produktversionen.

Die Beispiele zeigen auch Grenzen automatisierter Erkennung. Nicht jede gefundene Bibliothek ist im ausgelieferten Produkt enthalten, und nicht jeder eingebaute Bestandteil wird von einem einzelnen Werkzeug erkannt. Deshalb werden Scannerergebnis, Buildbeschreibung und Produktwissen gemeinsam genutzt. Lizenzinformationen werden als nützliche Komponentendaten eingeordnet und von der eigentlichen Sicherheitsbewertung getrennt behandelt.

Inhaltsübersicht

• Komponentenbestand und Produktversion
• SBOM erzeugen und Formate verstehen
• Datenqualität und Lieferanteneingänge
• Schwachstellenzuordnung und Betroffenheit
• VEX und nachvollziehbare Kommunikation
• Betrieb, Zugriff und Fortschreibung

Komponentenbestand und Produktversion

Quellcode, Paketdefinition, Buildumgebung und ausgeliefertes Artefakt werden als unterschiedliche Erfassungspunkte untersucht. Direkte und transitive Abhängigkeiten, Betriebssystempakete sowie eingebettete Bibliotheken erhalten einen nachvollziehbaren Produktbezug. Erfassungsgrenzen und nicht automatisch erkennbare Bestandteile werden ausdrücklich dokumentiert.

SBOM erzeugen und Formate verstehen

An einem vorbereiteten Projekt werden maschinenlesbare Stücklisten erzeugt und typische Strukturen von CycloneDX und SPDX verglichen. Komponentenidentität, Version, Herkunft und Abhängigkeitsbeziehungen werden überprüft. Werkzeugspezifische Ergebnisse werden als Ausgangsdaten behandelt, deren Vollständigkeit am Produkt nachzuweisen ist.

Datenqualität und Lieferanteneingänge

Fehlende Versionen, doppelte Komponenten, unklare Kennungen und widersprüchliche Lieferantendaten werden bereinigt. Eine Qualitätsprüfung definiert Annahme- und Rückfragekriterien für eingehende Stücklisten. Auslieferungsstand und SBOM werden eindeutig miteinander verknüpft, damit Rückfragen zu älteren Produktständen beantwortet werden können.

Schwachstellenzuordnung und Betroffenheit

Sicherheitsmeldungen werden auf konkrete Komponenten- und Produktversionen bezogen. Versionsbereiche, Produktkonfiguration und tatsächliche Nutzung einer betroffenen Funktion fließen in die Analyse ein. Ein hoher Schweregrad allein ersetzt keine produktspezifische Bewertung; unklare Zuordnungen werden mit Begründung und Prüftermin dokumentiert.

VEX und nachvollziehbare Kommunikation

Aussagen zur Ausnutzbarkeit werden mit Produktversion, Befund, Status und technischer Begründung verbunden. VEX wird als strukturierte Kommunikation einer Bewertung eingesetzt. Eine Aussage über fehlende Betroffenheit erhält überprüfbare Belege und einen Änderungsanlass, damit veraltete Bewertungen nicht unverändert weiterverwendet werden.

Betrieb, Zugriff und Fortschreibung

Die Pflege wird in Build, Release und Schwachstellenbearbeitung eingebunden. Zugriffsrechte, Weitergabe an Partner und Aktualisierung werden organisatorisch festgelegt. Die Erstellung einer SBOM wird von ihrer Veröffentlichung unterschieden: Aus dem CRA folgt keine allgemeine Pflicht, sämtliche Stücklisten öffentlich bereitzustellen.

Praxisworkshop

1. Eine Stückliste aus einem vorbereiteten Projekt und einem Containerartefakt erzeugen.
2. Komponentenkennungen, Versionsstände und Abhängigkeitsbeziehungen mit den Builddaten abgleichen.
3. Eine unvollständige Lieferanten-SBOM prüfen und konkrete Rückfragen formulieren.
4. Eine simulierte Sicherheitsmeldung auf zwei Produktversionen anwenden und die Betroffenheit begründen.
5. Eine strukturierte VEX-Aussage erstellen und SBOM sowie Bewertung dem Release zuordnen.

Schulungsumgebung

Bereitstehen müssen eine isolierte Linux-VM, Container-Laufzeit, Git sowie vorbereitete SBOM- und Scanwerkzeuge. Die Übungen arbeiten mit eingefrorenen Beispieldaten für reproduzierbare Bewertungen.

Weitere CRA-Seminare und empfohlene Besuchsreihenfolge