Cyber Resilience Act · 2026/2027

SBOM im CRA: Die Datei ist der Anfang des Prozesses, nicht sein Abschluss

Autor: Piotr AdamskiOperative und Sicherheitsprüfung: Brillnet C-Team

Informationsmaterial. Es ersetzt weder individuelle Rechtsberatung noch eine Konformitätsbewertung.

CRA-Anwendungsbereich prüfen und Produktbewertung herunterladen

Der Cyber Resilience Act verlangt von Herstellern, Schwachstellen und Komponenten in Produkten mit digitalen Elementen zu ermitteln und zu dokumentieren. Dazu gehört die Erstellung einer Software-Stückliste (Software Bill of Materials, SBOM) in einem gängigen, maschinenlesbaren Format, das mindestens die Abhängigkeiten auf oberster Ebene abdeckt.

Die Erstellung der Datei schließt die Arbeit nicht ab. Eine SBOM wird operativ nützlich, wenn das Team von einer Komponente zu einem tatsächlichen Produktrelease, einer Schwachstelle, einer Entscheidung über Auswirkungen, der Behebung und Prüfnachweisen gelangen kann.

Was der CRA über SBOMs bestimmt

Teil II von Anhang I verlangt von Herstellern, Schwachstellen und Produktkomponenten zu ermitteln und zu dokumentieren, einschließlich durch Erstellung einer SBOM.

Anhang VII verbindet die SBOM mit der technischen Dokumentation der Schwachstellenbehandlungsprozesse. Eine Marktüberwachungsbehörde kann die einschlägige SBOM auch anfordern, wenn sie zur Überprüfung der Erfüllung wesentlicher Cybersicherheitsanforderungen erforderlich ist.

Eine wichtige Unterscheidung: Die Verordnung verlangt nicht, dass jeder Hersteller die vollständige SBOM für jeden Nutzer veröffentlicht. Anhang II verlangt Angaben dazu, wo eine SBOM zugänglich ist, wenn der Hersteller beschließt, sie dem Nutzer bereitzustellen.

Das Dateiformat ist nur die erste Entscheidung

CycloneDX und SPDX sind verbreitete SBOM-Formate. Die Auswahl eines Formats löst nicht das Lebenszyklusmanagement.

Erfassen Sie für jedes SBOM-Artefakt mindestens:

  • Produkt;
  • Release/Fassung;
  • Erstellungszeitpunkt;
  • Werkzeug und Erstellungsprozess;
  • Scanumfang;
  • Formatversion;
  • Speicherort;
  • Artefaktkennung oder Hash;
  • Validierungsstatus.

Ohne Verknüpfung zu einem Release lässt sich später möglicherweise nicht mehr feststellen, ob eine Komponente tatsächlich an einen Kunden ausgeliefert wurde.

Der Ablauf, der Nutzen schafft

Komponente → Komponentenfassung → Produktrelease → Schwachstelle → Folgenbewertung → Entscheidung → Maßnahme → Behebung → Test → Nachweis → Kommunikation

Beispiel:

  1. Werkzeuge identifizieren die Bibliothek X in Release 4.8.1.
  2. Eine Schwachstelle wird für bestimmte Fassungen von X offengelegt.
  3. Das Team bestätigt, ob der betroffene Code im Produkt vorhanden und relevant ist.
  4. Eine Folgenbewertung und eine Priorisierungsentscheidung werden dokumentiert.
  5. Die Behebung wird mit einer konkreten Änderung und einem Produktrelease verknüpft.
  6. Ein Test überprüft das Ergebnis.
  7. Prüfnachweise werden dem Fall beigefügt.
  8. Sind die Kriterien des Artikels 14 erfüllt, beginnt der separate CRA-Meldeablauf.

Weder ein CVE-Eintrag noch die SBOM selbst entscheidet für das Team über die Auswirkungen auf das Produkt.

SBOMs und Lieferanten

Eine Komponente kann aus Open Source, von einem kommerziellen Lieferanten oder einem anderen internen Team stammen. Ein ausgereifter Prozess verbindet die Abhängigkeit deshalb mit:

  • Lieferant oder Quelle;
  • Wartungsstatus;
  • Quelle der Schwachstelleninformationen;
  • für die Aktualisierung verantwortlicher Person;
  • Ersatzweg, falls die Komponente nicht mehr unterstützt wird.

Das ist auch für Entscheidungen zum Unterstützungszeitraum wichtig. Der CRA erlaubt Herstellern, Unterstützungszeiträume integrierter Drittanbieterkomponenten zu berücksichtigen, die Kernfunktionen bereitstellen.

Das tatsächlich ausgelieferte Produkt beschreiben

Wir empfehlen, beim veröffentlichten Produkt und nicht beim Arbeitsplatz der Entwicklung zu beginnen. Eine Abhängigkeitsdatei im Quellrepository kann Testwerkzeuge, Build-Hilfen und optionale Module enthalten, die nicht ausgeliefert wurden. Umgekehrt kann ein Produktabbild Binärdateien oder gebündelte Komponenten enthalten, die diese Liste nicht beschreibt. Halten Sie fest, welchen Gegenstand das Erstellungsverfahren tatsächlich untersucht. Dieser Umfang gehört zur SBOM-Aufzeichnung, damit spätere Nutzer der Datei ihre Aussage verstehen und Grenzen nicht übersehen.

Bei einem hypothetischen vernetzten Gerät kann das ausgelieferte Produkt aus Firmware, Betriebssystemabbild und Anwendungspaket bestehen. Ein zusätzliches Verwaltungsprogramm für den Desktop hat möglicherweise eine eigene Release-Aufzeichnung. Legen Sie die Beziehungen fest und zeigen Sie die Grenzen in der Dokumentation. Eine Datei mit dem Titel „vollständige SBOM“ ist wenig hilfreich, wenn niemand erklären kann, ob sie alle Elemente oder nur das Anwendungsrepository umfasst. Die Bezeichnung der Datei darf ihren tatsächlichen Prüfumfang nicht übertreiben.

Der CRA nennt eine Mindestanforderung hinsichtlich der Abhängigkeiten auf oberster Ebene. Ein Hersteller kann eine tiefere Erfassung wählen, wenn sie Risikobewertung und Schwachstellenbehandlung unterstützt. Das ist eine technische Entscheidung. Dadurch wird nicht jede mögliche Erweiterung zur zusätzlichen gesetzlichen Pflicht. Dokumentieren Sie bekannte Grenzen und das Vorgehen zur Untersuchung weiterer Komponenten. Praktisch muss das Team relevante Produktabhängigkeiten finden können, wenn neue Schwachstelleninformationen eingehen. Eine Mindestabdeckung allein beantwortet noch nicht jede Frage eines konkreten Produkts.

Erstellung wiederholbar machen und das Artefakt bewahren

Eine praktische Erstellungsaufzeichnung nennt Release-Eingabe, Werkzeug, Konfiguration und Ergebnis. Wird die Datei später mit geänderten Paketquellen oder anderer Build-Konfiguration neu erzeugt, kann sie vom damaligen Lieferzustand abweichen. Bewahren Sie deshalb das erstellte Artefakt auf. Die Möglichkeit, einen Scanner erneut zu starten, genügt nicht als Ersatz. Verbinden Sie die Datei mit einer stabilen Release-Kennung und dokumentieren Sie die Prüfungen, die ihre Nutzbarkeit bestätigen. Dadurch wird auch ein späterer Vergleich verschiedener Lieferzustände möglich.

Prüfen Sie Komponentenkennungen, Fassungen und offensichtliche Lücken. Eine maschinenlesbare Datei kann fehlende Versionsangaben oder so allgemeine Namen enthalten, dass eine zuverlässige Zuordnung nicht gelingt. Wählen Sie ein unterstütztes Format und prüfen Sie die Datei mit geeigneten Werkzeugen. CycloneDX und SPDX veröffentlichen offizielle Spezifikationen. Ihre Namen beweisen nicht, dass eine bestimmte Datei die gewählte Spezifikation erfüllt. Halten Sie tatsächlich erzeugtes Format, Formatfassung und Validierungsergebnis gemeinsam fest, statt nur das Dateikürzel im Register zu speichern.

Verändert ein erneuter Build die ausgelieferten Komponenten, handelt es sich um ein geändertes Artefakt, auch wenn der kaufmännische Produktname gleich bleibt. Vergleichen Sie die Unterschiede und prüfen Sie mögliche Auswirkungen auf die Sicherheitsbewertung. Diese empfohlene Kontrolle behandelt einen häufigen blinden Fleck: Anwendungscode bleibt gleich, aber Basisabbild oder Bibliothek ändern sich. Die Produktaufzeichnung sollte zeigen, welche Lieferungen oder Installationen diesen Build erhalten haben, soweit diese Information verfügbar ist. Unbekannte Verteilung bleibt ausdrücklich als unbekannt erfasst.

Ein Schwachstellentreffer eröffnet eine Bewertung

Ein hypothetisches Advisory nennt eine Bibliotheksfassung, die in der SBOM für Release 4.8.1 steht. Das Team bestätigt zuerst die Identität. Ähnlich benannte Pakete sind nicht zwangsläufig dieselbe Komponente. Anschließend prüft es, ob betroffener Code oder betroffene Konfiguration vorhanden ist und ob die beschriebenen Bedingungen im Produkt auftreten können. Bewahren Sie die stützenden Tatsachen auf. Nur das letzte Scanneretikett erklärt nicht, wie die Bewertung zustande kam oder auf welchen technischen Annahmen sie beruht.

Trennen Sie Komponentenvorhandensein, technische Produktauswirkung und regulatorische Meldepflicht. Eine Komponente kann vorhanden sein, ohne dass die verwundbare Funktion genutzt wird. Eine erreichbare Schwachstelle kann dringende Behebung verlangen, ohne automatisch die Kriterien des Artikels 14 zu erfüllen. Glaubwürdige Informationen über aktive Ausnutzung können die Meldebewertung verändern. Jede Schlussfolgerung hat eigene Nachweise und Zuständigkeit. Ein gemeinsamer Status „betroffen“ verliert diese Unterschiede. Spätere Entscheidungen und Nutzerinformationen werden dadurch unnötig schwer erklärbar oder sogar widersprüchlich.

Bleibt die Auswirkung unklar, benennen Sie Untersuchung und vorläufigen Umgang mit dem Risiko. Verwenden Sie „nicht ausnutzbar“ nicht als bequemen Abschluss ohne Begründung. Versprechen Sie Nutzern ebenso wenig, sämtliche Komponenten seien schwachstellenfrei, weil ein Scan keine Treffer ergab. Ein Scan hat Umfang und Datum. Neue Veröffentlichungen oder eine bessere Komponentenidentifikation können das Ergebnis nach dem Release ändern. Die Aufzeichnung braucht deshalb einen überprüfbaren Zusammenhang mit dem jeweiligen Wissensstand und gegebenenfalls einen erneuten Prüfauslöser.

Behebung allen relevanten unterstützten Releases zuordnen

Ein Hersteller kann mehrere Entwicklungszweige, kundenspezifische Builds oder Hardwarevarianten betreuen. Eine Korrektur im neuesten Zweig belegt nicht die Behandlung einer älteren unterstützten Fassung. Nutzen Sie die Verbindung von Komponente und Release, um weitere erforderliche Bewertungen festzustellen. Dokumentieren Sie für jede relevante Familie ein Ergebnis. Soll eine gemeinsame Entscheidung gelten, muss die Gruppe genau beschrieben und die gemeinsame technische Grundlage genannt werden. Sonst kann ein älteres Produkt unbemerkt außerhalb der Behebung bleiben.

Jede Korrektur erhält vorgeschlagene Komponentenfassung, Produktänderung und Prüfnachweis. Kontrollieren Sie Kompatibilität und Funktion des Updatewegs. Eine Abhängigkeitsaktualisierung kann eine Schwäche entfernen und gleichzeitig eine Funktion beeinträchtigen. Tests müssen daher Sicherheitsziel und relevantes Produktverhalten abdecken. Die GRC-Aufzeichnung verweist auf diese Ergebnisse. Ein geschlossenes Entwicklungsticket allein ist kein ausreichender Nachweis des korrigierten Verhaltens. Das Ticket beschreibt die erledigte Arbeit, während der Test deren tatsächliche Wirkung unter bestimmten Bedingungen untersucht und dokumentiert.

Bewahren Sie nach Verteilung die neue SBOM oder Komponentenaufzeichnung und ihre Beziehung zur vorherigen Fassung auf. Ein späteres Advisory lässt sich dann dem tatsächlich ausgelieferten Zustand zuordnen. Kann ein Kunde nicht sofort aktualisieren, dokumentieren Sie mögliche Minderungsmaßnahmen und verbleibendes Risiko genau. Dies sind praktische Lebenszykluskontrollen. Sie schaffen keine allgemeine Ausnahme für alte Fassungen und erlauben nicht, geltende Unterstützungspflichten zu ignorieren. Die Entscheidung bleibt produktbezogen und muss die einschlägigen Pflichten sowie technischen Einschränkungen berücksichtigen.

Lieferanteninformationen auf konkrete Fragen ausrichten

Fordern Sie die Informationen an, die zur Identifikation und Wartung der gekauften Komponente benötigt werden. Dazu können Fassung, enthaltene Unterkomponenten, Unterstützung, Schwachstellenkontakt und Updatekanal gehören. Die Anfrage muss zum bezogenen Produkt und Vertrag passen. Eine allgemeine Versicherung, der Lieferant nehme Sicherheit ernst, nennt weder die eingebettete Bibliothek noch den Weg zur Nachricht über ein Unterstützungsende. Konkrete Antworten lassen sich dagegen in die Produktaufzeichnung übernehmen und bei einer Änderung gezielt erneut prüfen.

Bei einer nicht transparenten kommerziellen Komponente dokumentieren Sie bekannte Tatsachen, fehlende Angaben und Zuständigkeit für deren Beschaffung. Bewerten Sie das Risiko einer Abhängigkeit, deren Sicherheitsstand sich nicht ausreichend beurteilen lässt. Der Herstellerprozess muss die Lücke bearbeiten. Erfundenes Ausfüllen von Komponentenkennungen ist keine Lösung. Wird Ersatz erwogen, halten Sie Aufwand, Kompatibilitätsgrenzen und Entscheidung fest. Ein Austausch ist nicht automatisch sofort möglich. Der Plan muss zeigen, wie das Produkt bis zur bestätigten Ersatzlösung sicher weiterbetreut werden kann.

Bei Open Source unterscheiden Sie tatsächliche Wartung von Bekanntheit. Dokumentieren Sie Quellen für Releases und Schwachstellenhinweise sowie die Person, die relevante Änderungen verfolgt. Ein kommerzieller Unterstützungsvertrag besteht möglicherweise nicht. Trotzdem bleibt die Wartung des Herstellerprodukts notwendig. Gemeinschaftsaktivität ist keine vertragliche Unterstützungszusage für die gesamte Produktlebensdauer. Prüfen Sie deshalb auch, wie das Team bei ausbleibender Wartung weiter vorgeht und welche Kompetenz oder Ersatzoption es dafür tatsächlich benötigt. Die Entscheidung muss mehr als einen Link zur Projektseite enthalten.

Die Weitergabe der Datei bewusst entscheiden

Eine SBOM kann Architekturdetails oder wirtschaftlich vertrauliche Angaben zeigen. Legen Sie internen Zugriff, externe Weitergabe und Zuständigkeit für Behördenanfragen fest. Geheimhaltung beseitigt keine Offenlegungspflicht. Der CRA unterscheidet erforderliche Dokumentation und Behördenzugriff von der optionalen Bereitstellung an Nutzer. Kundenverträge können zusätzliche Fragen zur Weitergabe schaffen. Bewerten Sie jeden Weg anhand seiner Grundlage. Erfassen Sie, welches Artefakt wann an wen übermittelt wurde, damit bei späteren Änderungen auch die zuvor geteilte Produktfassung bekannt bleibt.

Prüfen Sie vor der Weitergabe Produkt, Release und unbeabsichtigte Inhalte wie interne Pfade oder fremde Entwicklungsdaten. Geben Sie genug Kontext, um den Umfang zu verstehen. Ein Empfänger sollte nicht erraten müssen, ob eine Komponente zur Laufzeitsoftware, zum Build-Werkzeug oder zu einer gesonderten Anwendung gehört. Diese empfohlenen Qualitätskontrollen verbessern die Verständlichkeit. Sie begründen keine Pflicht, jede interne Abhängigkeitsaufzeichnung allgemein zu veröffentlichen. Eine gezielte Weitergabe kann auch eine klare Erklärung der bekannten Erfassungsgrenzen benötigen.

Die Nutzbarkeit anhand einer Produktfrage prüfen

Wählen Sie für eine interne Übung ein unterstütztes Release und ein hypothetisches Advisory. Das Team sucht das Artefakt, bestätigt die Komponentenidentität, bewertet Produktauswirkungen, nennt die Entscheidungsverantwortung und zeigt einen möglichen Korrekturweg. Erfassen Sie benötigte Arbeit und fehlende Informationen. Ein vorgegebenes positives Ergebnis ist unnötig. Die Übung soll Schwächen der Identifikation, Release-Zuordnung und Nachverfolgung sichtbar machen, bevor ein echter Fall davon abhängt. Ihre Befunde brauchen anschließend benannte Verantwortliche und einen realistischen Prüftermin.

Wir empfehlen Kennzahlen zu unterstützten Releases mit nutzbaren Artefakten, offenen Identifikationslücken und überfälligen Folgenbewertungen. Definieren Sie „nutzbar“ für das konkrete Produkt, statt nur erzeugte Dateien zu zählen. Wenige verlässliche, mit Releases verbundene Aufzeichnungen können wertvoller sein als Tausende ungeprüfte Ausgaben. Das Ergebnis der Übung ist eine ausführbare Verbesserungsliste. Technische Bewertungen und regulatorische Entscheidungen bleiben bei den zuständigen Menschen und ihren Freigaben. Ein hoher Dateizähler ist weder ein Ersatz dafür noch ein eigenständiger Konformitätsnachweis.

Machen Sie GRC nicht zu einem weiteren Scanner

Pulsar sollte nicht mit Werkzeugen zur Softwarekompositionsanalyse, Abhängigkeitsscannern und SBOM-Generatoren konkurrieren. Diese Werkzeuge identifizieren und beschreiben Komponenten.

GRC schafft Nutzen, wenn es deren Ergebnisse zur Unterstützung kontrollierter Entscheidungen verwendet:

  • ein Artefakt Produkt und Release zuordnen;
  • Risiko und Maßnahme verbinden;
  • eine verantwortliche Person und eine Fälligkeit zuweisen;
  • die Entscheidung bewahren;
  • Nachweise der Behebung und der Tests beifügen;
  • die Historie bei einer Prüfung bereitstellen.

Verwenden Sie Pulsar, um Risiken, Maßnahmen, Lieferanten, Dokumente, Nachweise und Berichte zur Komponentenbehandlung zu ordnen. Vereinbaren Sie die Unterstützung für CycloneDX-/SPDX-Formate innerhalb Ihres Leistungsumfangs, bevor Sie einen SBOM-Import planen.

Prüfen Sie Ihren aktuellen Prozess

  • Können Sie die SBOM für ein bestimmtes Release identifizieren?
  • Ist ihre Erstellung reproduzierbar?
  • Hat jede kritische Komponente eine verantwortliche Person oder eine Quelle?
  • Lässt sich eine Schwachstelle mit einem betroffenen Produktrelease verbinden?
  • Hat eine Entscheidung zur Risikoakzeptanz eine genehmigende Person und einen Prüftermin?
  • Gibt es Prüfnachweise für die Behebung?
  • Gibt es eine klare Regel für den Übergang von der Schwachstellenbehandlung zur Bewertung einer CRA-Meldung?

Pulsar GRC an einem Nachweisablauf ansehen

Verwandte Leitfäden

Quellen

Quellen geprüft: 2. Oktober 2026.