SBOM erstellen: Software-Stückliste nach CRA mit CycloneDX und SPDX

Wenn in einer weit verbreiteten Bibliothek eine kritische Lücke auftaucht, beginnt in vielen Firmen dieselbe Suche: Wo steckt die Komponente drin, in welcher Version, in welchem Produkt? Eine Software-Stückliste (Software Bill of Materials, kurz SBOM) beantwortet diese Frage in Minuten statt in Tagen. Mit dem Cyber Resilience Act wird sie für Hersteller von Software, Firmware und vernetzten Geräten zur Pflicht, und Betreiber sollten wissen, was sie von ihren Lieferanten verlangen können.

Was ist eine SBOM und warum lohnt sie sich auch ohne Gesetz?

Eine SBOM ist ein maschinenlesbares Verzeichnis aller Bestandteile einer Software: Bibliotheken, Frameworks, Betriebssystempakete, eingebettete Komponenten, jeweils mit Name, Version und Herkunft. Der CRA definiert sie in Artikel 3 Nummer 39 als "formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements". Also ein formaler Nachweis, was in deiner Software steckt und wie die Teile zusammenhängen.

Der praktische Nutzen ist größer als die Pflicht. Du erkennst bei einer neuen Schwachstelle sofort, welche Produkte betroffen sind. Du siehst, welche Lizenzen du einsammelst. Du kannst Kunden und Auditoren belegen, was in einem Release enthalten war. Und du erkennst Komponenten, die niemand mehr pflegt. Das ist dieselbe Logik wie bei der Asset-Inventarisierung, nur eine Ebene tiefer: Statt Server und Anwendungen zählst du deren Bausteine.

Wichtig ist die Abgrenzung zum Scan. Ein Dependency Scan liefert dir eine Momentaufnahme mit Befunden. Die SBOM ist die Inventarliste dahinter, die du pro Version festhältst und archivierst. Der Scan liest die Liste und bewertet sie, die SBOM bleibt davon unberührt.

Was verlangt der CRA von deiner SBOM?

Der CRA spricht an zwei Stellen von der SBOM, und beide solltest du kennen, bevor du ein Werkzeug auswählst.

Mindestumfang: Anhang I Teil II

Hersteller müssen Schwachstellen und Komponenten ihrer Produkte identifizieren und dokumentieren, "including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products". Drei Anforderungen stecken darin:

• Gängiges, maschinenlesbares Format. Ein PDF oder eine Excel-Tabelle genügt nicht. Im Alltag heißt das CycloneDX oder SPDX.
• Mindestens die oberste Abhängigkeitsebene. Das ist die Untergrenze. Wer nur direkte Abhängigkeiten auflistet, erfüllt den Wortlaut, findet aber später die Schwachstelle in der Bibliothek der Bibliothek nicht. Die BSI-Richtlinie geht deshalb weiter, dazu gleich mehr.
• Teil des Schwachstellenmanagements. Die SBOM steht im selben Absatz wie das Beheben von Lücken und die Sicherheitsupdates. Sie ist ein Arbeitsmittel, kein Archivstück.

Artikel 13 Absatz 5 ergänzt eine Sorgfaltspflicht: Hersteller müssen bei Komponenten Dritter, ausdrücklich auch bei Open-Source-Komponenten ohne kommerzielle Bereitstellung, darauf achten, dass diese die Sicherheit des Produkts nicht gefährden. Findest du eine Lücke in einer Komponente, melde sie nach Absatz 6 an die Stelle, die sie pflegt.

Teil der technischen Dokumentation und Aufbewahrung

In Anhang VII listet der CRA die technische Dokumentation auf. Die SBOM erscheint dort bei den Angaben zu den Prozessen der Schwachstellenbehandlung. Eine Marktüberwachungsbehörde kann sie mit begründetem Antrag anfordern, soweit sie für die Prüfung der Anforderungen aus Anhang I nötig ist. Die Aufbewahrung regelt Artikel 13 Absatz 13: Du hältst technische Dokumentation und Konformitätserklärung mindestens zehn Jahre nach dem Inverkehrbringen bereit, oder für den Supportzeitraum, je nachdem, was länger ist. Der Supportzeitraum beträgt nach Artikel 13 Absatz 8 grundsätzlich mindestens fünf Jahre.

Für dich bedeutet das: Jede ausgelieferte Version braucht ihre eigene archivierte SBOM, und die muss noch lesbar sein, wenn das Produkt längst abgekündigt ist. Das gilt für Versionen, die du als Update auslieferst, ebenso wie für die erste Auslieferung.

Muss die SBOM veröffentlicht werden? Nein. Das BSI stellt klar, dass sie nicht veröffentlicht werden muss. Anhang II verlangt von dir nur, den Nutzern mitzuteilen, wo sie die SBOM abrufen können, falls du sie bereitstellst. Ob du sie bereitstellst, entscheidest du.

Bis wann musst du fertig sein?

Der CRA gilt nach Artikel 71 Absatz 2 ab dem 11. Dezember 2027. Die Meldepflichten aus Artikel 14 gelten schon seit dem 11. September 2026 und treffen jeden Hersteller, dem eine aktiv ausgenutzte Schwachstelle in seinem Produkt bekannt wird. Wie dieser Prozess aussieht, beschreibt der Artikel zur CRA-Meldepflicht in der Praxis. Eine gute SBOM verkürzt dabei die Zeit, bis du weißt, welche deiner Produkte betroffen sind.

Produkte, die du vor dem 11. Dezember 2027 in Verkehr gebracht hast, fallen nach Artikel 69 Absatz 2 nur dann unter die Anforderungen, wenn sie danach wesentlich verändert werden. Für laufende Entwicklungslinien mit regelmäßigen Releases ist das in der Praxis kaum ein Trost, denn spätestens das nächste größere Release liegt danach. Das ist keine Rechtsberatung, klär Zweifelsfälle zur Einstufung mit deiner Rechtsabteilung oder Kanzlei.

Wie viel Vorlauf brauchst du? Ein Anbieter-Leitfaden (ing-ism) rechnet für Analyse, Pilotierung an einem Produkt und Integration in die Pipeline mit zwei bis vier, vier bis acht und acht bis zwölf Wochen, zusammen also grob 14 bis 24 Wochen. Das ist ein Erfahrungswert, keine Vorgabe, und er gilt für ein überschaubares Produktportfolio. Bis zum Stichtag bleiben dir von heute an gut 14 Monate. Wer jetzt anfängt, hat Luft, wer im Herbst 2027 anfängt, nicht mehr.

Was verlangt die BSI TR-03183 Teil 2?

Der CRA nennt kein Format und keine Pflichtfelder. Artikel 13 Absatz 24 erlaubt der Kommission, Format und Elemente per Durchführungsrechtsakt festzulegen. Nach unserem Kenntnisstand von Oktober 2026 gibt es dazu keinen verabschiedeten Rechtsakt. Als Orientierung dient deshalb die Technische Richtlinie BSI TR-03183 Teil 2, aktuell in Version 2.1.0 vom 20. August 2025. Sie ist ausdrücklich nicht verbindlich und kann nicht als Konformitätsvermutung genutzt werden. Wer sie erfüllt, hat aber eine tragfähige Antwort, wenn ein Kunde oder eine Behörde fragt.

Die wichtigsten Vorgaben im Überblick:

Zwei Punkte überraschen viele Teams. Erstens liegt die Latte höher als im CRA-Wortlaut: Die TR will nicht nur die oberste Ebene, sondern die vollständige Kette bis zur Grenze des Lieferumfangs, und sie verlangt je Komponente einen SHA-512-Hash der auslieferbaren Datei. Zweitens bleibt die SBOM statisch. Schwachstellen ändern sich täglich, die Zusammensetzung eines Release nicht. Deshalb gehören Schwachstellendaten in ein separates Dokument. Eine SBOM, die beides mischt, ist nach der TR nicht konform.

Eine Folge davon: Eine neue SBOM-Fassung für dieselbe Softwareversion erzeugst du nur, wenn sich Angaben zu den Komponenten ergänzen oder Fehler korrigiert werden. Ändert sich eine Komponente, bekommt sie eine neue Version, und alle übergeordneten Komponenten ebenfalls.

Achte außerdem auf die Übergangsregel: Du musst für neue SBOMs die jeweils aktuelle TR-Version nutzen. Die unmittelbar vorherige Fassung darf noch sechs Monate nach dem Erscheinen einer neuen verwendet werden. Bereits ausgelieferte SBOMs bleiben konform. Neben Teil 2 gibt es Teil 1 (allgemeine Anforderungen), Teil 3 (Umgang mit Schwachstellenmeldungen) und das Modul H, mit dem sich die CRA-Konformität über ein ISO-27001-konformes ISMS belegen lassen soll.

CycloneDX oder SPDX: Welches Format passt zu dir?

Beide Formate erfüllen die TR, und beide sind etabliert. Die Wahl hängt weniger von der Technik ab als davon, welche Werkzeuge du schon nutzt und wer deine SBOM liest.

Die Faustregel: Willst du in erster Linie Schwachstellen verfolgen, nimm CycloneDX. Es lässt sich direkt in Dependency-Track laden, und dort lebt auch das VEX. Kommen deine Kunden aus Branchen, die traditionell SPDX fordern, oder steht Lizenzprüfung im Vordergrund, kann SPDX die bessere Wahl sein. Du musst dich nicht endgültig festlegen. Werkzeuge wie Syft schreiben beide Formate, in einer Pipeline kannst du also eine SBOM im Hauptformat pflegen und für einzelne Kunden ein zweites Format ausgeben. Beim Konvertieren gehen Felder verloren, prüfe das Ergebnis deshalb jedes Mal gegen die Pflichtfelder der TR.

Eine Falle bei den Versionen: Manche Werkzeuge erzeugen laut ihrer Dokumentation noch ältere Fassungen. Trivy gibt in seiner Dokumentation CycloneDX 1.5 und SPDX 2.3 an, beides unter den Mindestversionen der TR. Lies darum die Versionsangabe in der erzeugten Datei (bei CycloneDX das Feld specVersion) und verlass dich nicht auf die Werkzeugbeschreibung.

Wer sich fragt, warum in der CycloneDX-Spalte kryptografische Assets auftauchen: Das Format kann auch Verfahren, Schlüssel und Zertifikate beschreiben (CBOM). Das ist für ein Krypto-Inventar im Rahmen der Post-Quanten-Vorbereitung interessant, für die CRA-SBOM aber keine Pflicht.

SBOM in der Build-Pipeline erzeugen

Die zuverlässigste SBOM entsteht beim Bauen, nicht danach. Im Build kennst du die aufgelösten Abhängigkeiten, die Versionen aus dem Lockfile und die tatsächlich eingebundenen Artefakte. Die TR nennt diese Klasse Build-SBOM und weist darauf hin, dass der Hash einer Komponente nur dann eindeutig ist, wenn der Build reproduzierbar läuft. Eine nachträgliche Analyse fertiger Binärdateien (die TR spricht von "Analysed SBOM") bleibt der Notnagel, etwa für Komponenten, die du fertig zukaufst.

Ein Beispiel für ein Team mit 100 Mitarbeitenden

Nehmen wir einen Maschinenbauer mit rund 100 Mitarbeitenden, der Steuerungssoftware, die Firmware eines Gateways und ein Web-Portal für seine Kunden ausliefert. Drei Produkte, drei Repositories, je einmal im Quartal ein Release. Das Team will pro Release automatisch eine CycloneDX-SBOM erzeugen, ablegen und an einen Dependency-Track-Server übergeben.

Das folgende Beispiel für GitHub Actions nutzt die Action von Anchore, die Syft aufruft, und lädt die SBOM per REST-API zu Dependency-Track hoch. Die Parameter stammen aus der Dokumentation der Action und der Dependency-Track-API. Projektname, Secrets und Branch-Schema passt du an.

name: sbom
on:
  push:
    tags: ["v*"]

permissions:
  contents: write   # laut Doku der Action für Artefakt-Upload nötig
  actions: read

jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: SBOM erzeugen (CycloneDX, JSON)
        uses: anchore/sbom-action@v0
        with:
          path: .
          format: cyclonedx-json
          output-file: sbom.cdx.json
          upload-artifact: true

      - name: SBOM an Dependency-Track übergeben
        env:
          DT_URL: ${{ secrets.DT_URL }}
          DT_API_KEY: ${{ secrets.DT_API_KEY }}
          RELEASE: ${{ github.ref_name }}
        run: |
          curl -sS --fail -X POST "$DT_URL/api/v1/bom" \
            -H "X-Api-Key: $DT_API_KEY" \
            -F "autoCreate=true" \
            -F "projectName=gateway-firmware" \
            -F "projectVersion=$RELEASE" \
            -F "bom=@sbom.cdx.json"

Was hier passiert, in Kürze: Das Tag v1.4.0 löst den Job aus, Syft liest die Paketmanager-Dateien im Repository und schreibt eine CycloneDX-SBOM. Dependency-Track legt über autoCreate bei Bedarf ein Projekt an und führt die Version des Releases als eigene Projektversion. Der API-Schlüssel liegt als Secret im Repository, nicht im Workflow.

Ein paar Hinweise dazu. Ohne Versionsangabe erzeugt Syft laut Dokumentation die neueste unterstützte Version des Formats. Möchtest du fest auf eine Version setzen, geht das auf der Kommandozeile mit syft . -o cyclonedx-json@1.6. Pinne die Actions in einer echten Pipeline auf einen Commit-Hash statt auf v0, sonst baust du in eine Lieferketten-Absicherung genau das Risiko ein, das du eigentlich abdecken willst, wie es der Artikel zu Supply-Chain-Angriffen beschreibt. Und prüf das Ergebnis einmal gegen die TR: Das Werkzeug sbomqs bringt dafür laut README einen Befehl mit (sbomqs compliance --bsi-v2 sbom.cdx.json). Rechne damit, dass ein erster Lauf Lücken zeigt, etwa fehlende Ersteller-Angaben oder Hashes, die du in der Konfiguration oder per Nachbearbeitung ergänzt.

Container, Firmware und Closed-Source-Zukauf

Für Container-Images arbeitest du auf demselben Weg, nur dass du das Image statt des Verzeichnisses scannst. Bei Firmware wird es schwieriger: Ein fertiges Firmware-Image ist nach der TR ein unstrukturiertes Archiv, aus dem sich die Bestandteile nicht verlässlich zurückgewinnen lassen. Erzeuge die SBOM deshalb im Build-System, das die Pakete zusammenstellt, und nicht aus dem fertigen Abbild. Zugekaufte Closed-Source-Komponenten dokumentierst du über die SBOM oder die Herstellerangabe des Lieferanten. Die TR erlaubt, SBOMs von Komponenten zu referenzieren statt sie einzubetten, du bleibst dann aber dafür verantwortlich, dass die referenzierte SBOM verfügbar ist.

SBOM pro Release pflegen und aufbewahren

Eine SBOM veraltet nicht in der Schublade, sondern mit jedem Commit, der eine Abhängigkeit ändert. Das ist zugleich ihre Stärke: Sie lässt sich automatisch bei jedem Release nachziehen. Damit das sauber läuft, brauchst du wenige feste Regeln:

1. Eine SBOM pro ausgelieferter Version. Der Release-Job erzeugt sie, gibt ihr Name und Versionsnummer des Produkts und legt sie neben dem Release-Artefakt ab.
2. Unveränderlich archivieren. Speichere SBOM, Hash und, wenn du signierst, die Signatur in einem Ablageort, in dem niemand nachträglich Dateien überschreibt. Das ist derselbe Gedanke wie bei unveränderlichen Backups, nur für Entwicklungsartefakte.
3. Aufbewahrungsfrist festhalten. Notiere pro Produktlinie, bis wann die SBOMs vorgehalten werden: zehn Jahre nach dem Inverkehrbringen oder bis zum Ende des Supportzeitraums, je nachdem, was länger ist.
4. Korrekturen nur mit Begründung. Findest du einen Fehler in einer ausgelieferten SBOM, erzeugst du nach der TR eine neue Fassung für dieselbe Version und dokumentierst, was sich geändert hat.
5. Verantwortlichkeit benennen. Jemand im Team verantwortet die Pipeline, jemand in der Produktleitung entscheidet, ob und wo die SBOM Kunden zugänglich gemacht wird.

Die Verknüpfung zum Rest deines Sicherheitsmanagements ist dabei einfach: Die SBOM gehört in den Secure Development Lifecycle als festes Artefakt des Release-Prozesses, so wie Testergebnisse und Freigabe.

Schwachstellenabgleich: Von der SBOM zu VEX und Dependency-Track

Die SBOM sagt dir, was drinsteckt. Ob etwas davon verwundbar ist, sagt sie nicht. Dafür gleichst du die Komponenten mit Schwachstellendatenbanken ab, dauerhaft und nicht nur beim Release. Genau das leistet Dependency-Track, ein quelloffenes Projekt der OWASP. Es nimmt CycloneDX-SBOMs entgegen und gleicht sie laut Projektbeschreibung mit NVD, GitHub Advisories und OSV ab, optional auch mit OSS Index, Snyk, Trivy und VulnDB. Neue Lücken in alten Releases tauchen so auf, ohne dass jemand die SBOM erneut hochlädt.

Das erzeugt Treffer, und nicht jeder Treffer ist ein Problem. Eine Bibliothek kann verwundbar sein, während dein Code die betroffene Funktion nie aufruft. Hier kommt VEX ins Spiel, das Vulnerability Exploitability eXchange. Ein VEX-Dokument hält pro Schwachstelle und Produkt fest, wie du sie bewertest: etwa not_affected mit Begründung, exploitable, in_triage oder resolved. Dependency-Track erzeugt solche Aussagen aus deinen Triage-Entscheidungen und kann sie als CycloneDX-VEX exportieren. Das BSI empfiehlt für den Austausch von Schwachstelleninformationen CSAF, wobei VEX als Profil darin enthalten ist.

Für den Alltag ergibt sich ein Ablauf, den du in dein Schwachstellenmanagement übernehmen kannst:

1. Dependency-Track meldet einen neuen Treffer für ein ausgeliefertes Release.
2. Ein Entwickler bewertet, ob die Lücke im Produkt erreichbar ist, und trägt die Entscheidung samt Begründung ein.
3. Ist sie relevant, entsteht ein Ticket für das Update, und die Priorität richtet sich nach dem Risiko, nicht nur nach dem CVSS-Wert.
4. Wird die Lücke aktiv ausgenutzt, läuft parallel die Meldung nach Artikel 14, und die Nutzer erhalten die Information und ein Sicherheitsupdate.
5. Die Bewertung wandert als VEX-Aussage zu den Kunden, die danach fragen.

Die Maßnahmen und Risiken dazu führst du nicht in der Entwicklungsumgebung, sondern im Sicherheitsmanagement. In ISMS Lite legst du für ein Produkt mit kritischer Abhängigkeit ein Risiko an, verknüpfst es mit dem betroffenen Software-Asset und führst die Maßnahme mit Verantwortlichem und Termin bis zum Abschluss. Das Management Review sieht dann, wie viele solcher Fälle offen sind.

Lizenz-Compliance als Nebeneffekt

Die TR verlangt für jede Komponente die Lizenz als SPDX-Lizenzkennung, etwa MIT oder Apache-2.0, und unterscheidet ursprüngliche und Distributionslizenzen. Sie begründet das ausdrücklich damit, dass Lizenzen auch beim Beheben von Schwachstellen eine Rolle spielen: Wenn die Lizenz das Ändern des Codes nicht erlaubt, kannst du eine Lücke nicht selbst patchen.

Damit bekommst du Lizenzprüfung fast geschenkt. Dependency-Track kennt dafür die Analyseart "License Evaluation": Du definierst Regeln, etwa "keine Komponente unter AGPL in ausgelieferter Firmware", und das System schlägt bei Verstößen an. Besonders bei Firmware, die du an Kunden weitergibst, lohnt sich das, denn Copyleft-Lizenzen knüpfen Pflichten an die Weitergabe. Ob eine konkrete Konstellation zulässig ist, beurteilt am Ende die Rechtsabteilung, die SBOM liefert aber die Faktenbasis.

SBOMs von Lieferanten fordern und auswerten: Was Betreiber verlangen sollten

Bisher ging es um Hersteller. Aber auch wenn du selbst nichts auslieferst, kaufst du Software, Geräte und Firmware ein. Im Rahmen von NIS2 gehört die Sicherheit der Lieferkette zu den Risikomanagementmaßnahmen, und eine SBOM ist ein praktisches Mittel, um sie für Software greifbar zu machen.

Bedenke dabei: Der CRA gibt dir keinen Anspruch, die SBOM zu erhalten. Er verpflichtet den Hersteller zur Erstellung und zur Vorlage bei Behörden, nicht zur Weitergabe an Kunden. Du musst sie deshalb vertraglich oder über die Beschaffungsrichtlinie fordern. Marktmacht hilft, aber auch ein kleiner Betreiber kann es in die Ausschreibung schreiben.

Was solltest du konkret verlangen?

Formuliere diese Punkte als Vertragsklauseln und nimm die SBOM-Fragen zusätzlich in den Sicherheitsfragebogen auf, mit dem du neue Lieferanten bewertest.

Ausgewertet wird die erhaltene SBOM wie die eigene: in ein Werkzeug laden, laufend gegen Schwachstellendaten abgleichen, bei Treffern mit dem Lieferanten sprechen. Für ein Unternehmen mit etwa 100 Mitarbeitenden und vielleicht 40 Softwarelieferanten ist das nicht für alle nötig. Beginne mit den Produkten, die an kritischen Prozessen hängen oder aus dem Internet erreichbar sind, und mit den Lieferanten, die du ohnehin als kritisch eingestuft hast. In ISMS Lite hinterlegst du bei diesen Dienstleistern, welche Nachweise sie liefern müssen, setzt eine Wiedervorlage für die Bewertung und verknüpfst sie mit den genutzten Assets.

Checkliste: SBOM-Prozess für Hersteller und Betreiber

Für Hersteller: Grundlagen

• Alle Produkte und Repositories mit auslieferbarer Software erfasst
• Zielformat festgelegt (CycloneDX ab 1.6 oder SPDX ab 3.0.1)
• Pflichtfelder der TR-03183-2 gegen das Werkzeug abgeglichen, Lücken dokumentiert
• Verantwortliche Person für die SBOM-Pipeline benannt

Für Hersteller: Pipeline

• SBOM-Erzeugung als fester Schritt im Release-Job
• Eine SBOM pro Softwareversion, benannt nach Produkt und Version
• Hash (SHA-512) der auslieferbaren Artefakte enthalten
• Lizenzen als SPDX-Kennungen erfasst
• Keine Schwachstellendaten in der SBOM selbst
• Build-Actions auf Commit-Hash gepinnt, API-Schlüssel als Secret hinterlegt
• Ergebnis automatisch gegen die TR validiert

Für Hersteller: Pflege und Aufbewahrung

• SBOM, Hash und Signatur unveränderlich archiviert
• Aufbewahrungsfrist pro Produktlinie dokumentiert (zehn Jahre oder Supportzeitraum, je nachdem, was länger ist)
• Supportzeitraum festgelegt und kommuniziert (mindestens fünf Jahre, außer die erwartete Nutzungsdauer ist kürzer)
• Korrekturprozess für fehlerhafte SBOMs beschrieben

Für Hersteller: Schwachstellen

• Dauerhafter Abgleich mit Schwachstellendatenbanken eingerichtet, etwa in Dependency-Track
• Triage-Prozess mit Begründung und VEX-Aussage definiert
• Meldeprozess für aktiv ausgenutzte Schwachstellen an die SBOM-Ergebnisse angebunden
• Lizenzregeln für ausgelieferte Produkte hinterlegt

Für Betreiber

• Software mit kritischer Bedeutung oder Internetanbindung identifiziert
• SBOM-Anforderungen in Einkaufsrichtlinie und Verträge aufgenommen
• Lieferanten nach Format, Rhythmus und Supportzeitraum gefragt
• Erhaltene SBOMs in ein Auswertungswerkzeug geladen und mit dem Asset-Inventar verknüpft
• Vorgehen bei Treffern festgelegt: Rückfrage beim Lieferanten, Maßnahme, Frist

Häufige Fehler bei der SBOM-Erstellung

Einmal erzeugt und nie wieder angefasst. Eine SBOM, die beim ersten Release entstand und danach in einem Ordner liegt, beschreibt irgendwann ein Produkt, das es nicht mehr gibt. Bau die Erzeugung in den Release-Job ein, dann pflegt sie sich selbst.

Nur die oberste Ebene dokumentiert. Der CRA-Wortlaut genügt damit formal, aber die Schwachstellen stecken oft tiefer. Löse die Abhängigkeiten vollständig auf, so wie es die TR vorsieht.

Schwachstellen in die SBOM geschrieben. Manche Formate lassen es zu, die TR schließt es aus. Halte Bestand und Bewertung getrennt, sonst musst du die SBOM bei jeder neuen Lücke neu ausliefern.

Werkzeugausgabe ungeprüft übernommen. Ein Scanner kennt nicht alle Pflichtfelder der TR, und er erzeugt je nach Werkzeug eine ältere Formatversion. Prüf das Ergebnis, bevor du es als Nachweis ablegst.

Treffer ohne Bewertung weitergereicht. Wer jede Meldung der Datenbank an Kunden oder Auditoren gibt, erzeugt Fehlalarme. Triagiere, begründe und halte die Entscheidung als VEX fest.

Fazit: Die SBOM ist eine Pipeline-Aufgabe, kein Dokument

Eine SBOM nach CRA entsteht nicht in einem Workshop, sondern im Build. Wenn der Release-Job sie erzeugt, die TR-Pflichtfelder prüft und sie zusammen mit dem Release unveränderlich ablegt, erfüllst du die Pflicht und gewinnst nebenbei Antworten auf Lieferkettenfragen. Starte diese Woche mit einem Produkt: Syft oder ein gleichwertiges Werkzeug in die Pipeline einbauen, Ergebnis gegen die TR prüfen, Dependency-Track anbinden. Wer als Betreiber einkauft, nimmt die SBOM-Forderung in die nächste Ausschreibung auf.

Weiterführende Artikel

• Secure Development Lifecycle (SDL): Sicherheit in den Entwicklungsprozess einbauen
• IT-Sicherheitsklauseln in Verträgen: Was du von Dienstleistern fordern solltest
• Lieferantenbewertung mit Sicherheitsfragebogen: Vorlage und Vorgehen
• NIS2 für den Mittelstand: Was du wissen musst und was jetzt zu tun ist
• Patch-Management im Mittelstand: Prozess, Priorisierung und Automatisierung