Ohne Software Bill of Materials (SBOM) keine CE-Kennzeichnung – so lässt sich eine der zentralen Anforderungen des Cyber Resilience Act (CRA) zusammenfassen. Dieser Artikel zeigt, was eine SBOM ist, welche Anforderungen der CRA stellt und wie Unternehmen die Umsetzung mit konkreten Beispielen für Java (Maven), JavaScript (npm) und Kubernetes systematisch angehen.

Was ist eine SBOM?

Eine Software Bill of Materials (SBOM) ist ein maschinenlesbares Inventar aller Softwarekomponenten, die in einem Produkt enthalten sind. Das BSI beschreibt die SBOM treffend als „Zutatenliste für Software" – vergleichbar mit der Inhaltsangabe auf einer Lebensmittelverpackung.

Die SBOM dokumentiert systematisch, welche Bibliotheken, Frameworks, Module und Abhängigkeiten in einer Software verwendet werden. Sie erfasst dabei nicht nur direkt eingebundene Komponenten, sondern auch deren transitive Abhängigkeiten – also alle Softwarebestandteile, von denen ein Produkt direkt oder indirekt abhängt.

Eine vollständige SBOM enthält typischerweise folgende Informationen zu jeder Komponente: den Namen des Pakets, die genaue Version, den Lieferanten oder Hersteller, eindeutige Identifikatoren wie Package URLs (purl), Lizenzinformationen sowie Prüfsummen zur Integritätsverifizierung. Diese Transparenz ermöglicht es, bei Bekanntwerden einer Schwachstelle in einer Komponente sofort festzustellen, welche Produkte betroffen sind.

SBOM-Anforderungen im Cyber Resilience Act

Der Cyber Resilience Act macht die Erstellung einer SBOM zur Pflicht für alle Hersteller von Produkten mit digitalen Elementen. Die rechtliche Grundlage findet sich in Anhang I Teil II der Verordnung (EU) 2024/2847, der die Anforderungen an die Schwachstellenbehandlung definiert.

Ob Ihr Unternehmen von den CRA-Anforderungen betroffen ist, können Sie mit unserem CRA Self-Check-Tool prüfen. Das Tool hilft Ihnen dabei, schnell zu klären, ob und in welchem Umfang die SBOM-Pflicht für Ihre Produkte gilt.

Gemäß CRA müssen Hersteller eine SBOM erstellen, die mindestens die Top-Level-Abhängigkeiten des Produkts umfasst. Die SBOM muss in einem gebräuchlichen, maschinenlesbaren Format vorliegen und als Teil der technischen Dokumentation zehn Jahre lang aufbewahrt werden. Eine Veröffentlichung der SBOM ist nicht verpflichtend, jedoch müssen Hersteller sie auf Anfrage den Marktüberwachungsbehörden zur Verfügung stellen.

Die Europäische Kommission ist ermächtigt, durch delegierte Rechtsakte das genaue Format und die erforderlichen Elemente der SBOM zu spezifizieren. Bis dahin bietet die Technische Richtlinie TR-03183-2 des BSI eine praxisnahe Orientierung.

Fristen für die SBOM-Pflicht

Die SBOM-Anforderung ist Teil der allgemeinen CRA-Compliance und unterliegt damit den gestaffelten Übergangsfristen. Die vollständige Anwendbarkeit aller CRA-Anforderungen – einschließlich der SBOM-Pflicht – gilt ab dem 11. Dezember 2027. Unternehmen sollten jedoch frühzeitig mit der Implementierung beginnen, um Prozesse zu etablieren und Erfahrungen zu sammeln.

Eine detaillierte Übersicht aller Fristen und Anforderungen bietet unser CRA-Leitfaden mit Umsetzungsfahrplan.

BSI TR-03183-2: Die deutsche Referenz für SBOM-Anforderungen

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat mit der Technischen Richtlinie TR-03183 einen dreiteiligen Leitfaden für die CRA-Umsetzung veröffentlicht. Teil 2 widmet sich spezifisch den Anforderungen an Software Bills of Materials.

Die TR-03183-2 definiert formelle und fachliche Vorgaben für SBOMs und bietet damit eine konkrete Handlungsanleitung für Hersteller. Die aktualisierte Version 2.1.0 berücksichtigt die finalen CRA-Anforderungen und wurde zuletzt im Oktober 2025 angepasst.

Pflichtfelder nach TR-03183-2

Die Technische Richtlinie unterscheidet zwischen notwendigen und zusätzlichen Datenfeldern. Zu den Pflichtangaben für die SBOM selbst gehören der Name und die Version des dokumentierten Produkts, der Erstellungszeitpunkt der SBOM, der Name des SBOM-Erstellers sowie ein eindeutiger Identifier für das SBOM-Dokument.

Für jede enthaltene Komponente sind mindestens folgende Informationen erforderlich: der Komponentenname, die Version, der Lieferant oder Hersteller sowie eine eindeutige Komponentenidentifikation. Optional, aber empfohlen, sind Angaben zu Lizenzen, Prüfsummen (Hashes), Downloadquellen und der Beziehung zu anderen Komponenten.

Wichtig: Die TR-03183 hat keinen verbindlichen Charakter, sondern dient als Orientierungshilfe. Sie repräsentiert jedoch den aktuellen Stand der Technik und kann als Nachweis der Sorgfaltspflicht herangezogen werden.

SBOM-Formate: SPDX vs. CycloneDX

Für die Erstellung von SBOMs haben sich zwei Standardformate etabliert: SPDX (Software Package Data Exchange) und CycloneDX. Beide Formate erfüllen die Anforderungen des CRA und der TR-03183, unterscheiden sich jedoch in ihrer Ausrichtung und ihren Stärken.

SPDX: Der ISO-Standard

SPDX wurde von der Linux Foundation entwickelt und ist seit 2021 als ISO/IEC 5962:2021 international standardisiert. Das Format wurde ursprünglich für die Verwaltung von Open-Source-Lizenzen konzipiert und bietet daher besonders umfangreiche Möglichkeiten zur Dokumentation von Lizenzinformationen.

SPDX unterstützt verschiedene Dateiformate, darunter JSON, XML, RDF und YAML. Die breite Unterstützung durch große Technologieunternehmen wie Microsoft, Google und Intel macht SPDX zu einer soliden Wahl für Unternehmen, die mit diesen Partnern zusammenarbeiten oder deren Ökosysteme nutzen.

CycloneDX: Der Security-fokussierte Standard

CycloneDX ist ein Projekt der OWASP Foundation und wurde speziell für Sicherheitsanwendungen entwickelt. Das Format ist leichtgewichtig, maschinenlesbar und optimiert für die Integration in DevSecOps-Workflows.

Ein wesentlicher Vorteil von CycloneDX ist die native Unterstützung für Vulnerability Exploitability Exchange (VEX), ein Format zur Dokumentation der Ausnutzbarkeit von Schwachstellen. Diese Funktion ermöglicht es, SBOM-Daten direkt mit Schwachstelleninformationen zu verknüpfen und so ein effizientes Risikomanagement zu unterstützen.

CycloneDX unterstützt die Formate JSON, XML und Protocol Buffers. Die aktuelle Version 1.6 bietet erweiterte Funktionen für die Dokumentation von Abhängigkeitsbäumen, digitalen Signaturen und Komponentenherkunft (Provenance).

Entscheidungshilfe: Welches Format wählen?

Kriterium	SPDX	CycloneDX
Standardisierung	ISO-zertifiziert	OWASP-Standard
Schwerpunkt	Lizenzcompliance	Sicherheitsanalyse
VEX-Unterstützung	Über Erweiterungen	Nativ integriert
Verbreitung	Große Unternehmen	DevSecOps-Community
Lernkurve	Mittel	Niedrig

In der Praxis können beide Formate für die CRA-Compliance verwendet werden. Die BSI TR-03183-2 erkennt beide Formate explizit an und bietet Mapping-Tabellen für die Zuordnung der Pflichtfelder. Die Wahl sollte sich an den bestehenden Toolchains, Partneranforderungen und dem primären Verwendungszweck orientieren.

Detaillierungsgrad: Top-Level vs. vollständige Abhängigkeiten

Der CRA fordert mindestens die Dokumentation der Top-Level-Abhängigkeiten – also der direkt eingebundenen Komponenten. Die BSI TR-03183-2 empfiehlt jedoch eine Erfassung bis zur ersten externen Komponente und für effektives Schwachstellenmanagement die vollständige Dokumentation aller transitiven Abhängigkeiten.

Die Log4j-Schwachstelle (CVE-2021-44228) hat eindrücklich gezeigt, warum diese tiefere Erfassung wichtig ist: Die betroffene Bibliothek war in vielen Produkten nicht direkt, sondern als transitive Abhängigkeit eingebunden. Unternehmen ohne vollständige SBOM hatten erhebliche Schwierigkeiten festzustellen, ob und wo sie betroffen waren.

Für die praktische Umsetzung empfiehlt sich ein gestufter Ansatz: Zunächst alle direkten Abhängigkeiten erfassen (CRA-Mindestanforderung), dann schrittweise auf vollständige transitive Abhängigkeiten erweitern (Best Practice). Die automatisierte SBOM-Generierung durch entsprechende Tools macht diese erweiterte Erfassung ohne nennenswerten Mehraufwand möglich.

Tools für die SBOM-Erstellung

Die manuelle Erstellung von SBOMs ist bei modernen Softwareprojekten nicht praktikabel. Automatisierte Tools analysieren Quellcode, Build-Artefakte und Container-Images und generieren SBOMs in standardisierten Formaten.

Syft: Der Allrounder

Syft ist ein Open-Source-Kommandozeilenwerkzeug von Anchore, das SBOMs aus Container-Images, Dateisystemen und Archiven generiert. Das Tool unterstützt eine breite Palette von Paketmanagern und Programmiersprachen, darunter Alpine, Debian, RPM, Go, Python, Java, JavaScript, Ruby, Rust und PHP.

Syft erkennt automatisch die verwendete Linux-Distribution und kann SBOMs in den Formaten CycloneDX, SPDX und dem eigenen JSON-Format ausgeben. Die Integration in CI/CD-Pipelines ist unkompliziert, und das Tool wird von der US-Behörde CISA explizit als SBOM-Werkzeug empfohlen.

SBOM für Container-Image erstellen
syft alpine:latest -o cyclonedx-json > sbom.json

SBOM für lokales Verzeichnis
syft ./my-project -o spdx-json > sbom-spdx.json

Trivy: SBOM und Schwachstellenscanner in einem

Trivy von Aqua Security ist ein umfassender Sicherheitsscanner, der neben Schwachstellenanalysen auch SBOM-Generierung unterstützt. Das Tool kann SBOMs in den Formaten CycloneDX und SPDX erstellen und diese anschließend auf Schwachstellen prüfen.

Der Vorteil von Trivy liegt in der Kombination beider Funktionen: Eine SBOM kann erstellt, gespeichert und später ohne erneutes Scannen des Images auf neue Schwachstellen geprüft werden. Dies spart Zeit und Ressourcen, insbesondere bei großen Container-Images.

SBOM erstellen
trivy image --format cyclonedx --output sbom.json alpine:3.15

SBOM auf Schwachstellen prüfen
trivy sbom sbom.json

cdxgen: Der OWASP-Standard

Der CycloneDX Generator (cdxgen) ist das offizielle OWASP-Tool zur SBOM-Erstellung. Es unterstützt eine Vielzahl von Programmiersprachen und kann sowohl lokal als auch in CI/CD-Pipelines eingesetzt werden.

Für Unternehmen, die CycloneDX als primäres Format gewählt haben, bietet cdxgen die beste Kompatibilität und Formatunterstützung. Das Tool wird aktiv weiterentwickelt und unterstützt die neuesten CycloneDX-Spezifikationen.

Praxisbeispiel 1: SBOM für Java-Applikationen (Maven)

Java-Projekte mit Maven profitieren von der nahtlosen Integration des CycloneDX Maven Plugins. Die SBOM-Generierung wird direkt in den Build-Prozess integriert und bei jedem Release automatisch ausgeführt.

Plugin-Konfiguration in der pom.xml

<build>
    <plugins>
        <plugin>
            <groupId>org.cyclonedx</groupId>
            <artifactId>cyclonedx-maven-plugin</artifactId>
            <version>2.9.1</version>
            <configuration>
                <projectType>application</projectType>
                <schemaVersion>1.6</schemaVersion>
                <includeBomSerialNumber>true</includeBomSerialNumber>
                <includeCompileScope>true</includeCompileScope>
                <includeProvidedScope>true</includeProvidedScope>
                <includeRuntimeScope>true</includeRuntimeScope>
                <includeSystemScope>true</includeSystemScope>
                <includeTestScope>false</includeTestScope>
                <includeLicenseText>false</includeLicenseText>
                <outputReactorProjects>true</outputReactorProjects>
                <outputFormat>all</outputFormat>
                <outputName>bom</outputName>
                <outputDirectory>${project.build.directory}</outputDirectory>
            </configuration>
            <executions>
                <execution>
                    <phase>package</phase>
                    <goals>
                        <goal>makeAggregateBom</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

Build-Ausführung

SBOM während des Builds erstellen
mvn clean package

Ergebnis: target/bom.json und target/bom.xml

Die generierte SBOM enthält alle direkten und transitiven Abhängigkeiten des Projekts, einschließlich Metadaten wie Lizenzen, Hashes und Package URLs. Bei Multi-Modul-Projekten aggregiert das Plugin alle Abhängigkeiten in einer zentralen SBOM.

Tipp für Spring Boot: Ab Spring Boot 3.3 ist die CycloneDX-Integration vereinfacht. Das Plugin kann ohne zusätzliche Konfiguration verwendet werden, da Spring Boot die Versionsverwaltung übernimmt. Zusätzlich steht ein Actuator-Endpoint zur Verfügung, der die SBOM zur Laufzeit bereitstellt.

Alternative: CLI-basierte Generierung

Für Umgebungen, in denen die pom.xml nicht verändert werden soll, kann die SBOM auch über die Kommandozeile erstellt werden:

mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom

Praxisbeispiel 2: SBOM für JavaScript-Applikationen (npm)

Node.js- und npm-Projekte können SBOMs auf verschiedene Wege generieren. Die empfohlene Methode ist das offizielle CycloneDX npm-Tool, das auch von der npm-CLI nativ unterstützt wird.

Methode 1: Native npm-Unterstützung (ab npm 9.x)

Seit npm Version 9 ist die SBOM-Generierung direkt in die CLI integriert:

SBOM im CycloneDX-Format
npm sbom --sbom-format cyclonedx

SBOM im SPDX-Format
npm sbom --sbom-format spdx

SBOM in Datei speichern
npm sbom --sbom-format cyclonedx > sbom.json

Methode 2: CycloneDX npm-Tool

Das dedizierte CycloneDX-Tool bietet erweiterte Konfigurationsmöglichkeiten und erfüllt die Anforderungen der BSI TR-03183:

Installation (global oder als devDependency)
npm install -g @cyclonedx/cyclonedx-npm

SBOM generieren
cyclonedx-npm --output-file sbom.json

Mit erweiterten Optionen
cyclonedx-npm \
  --spec-version 1.6 \
  --output-format JSON \
  --output-file sbom.json \
  --include-license-text

Integration in package.json

Für die automatisierte SBOM-Generierung bei jedem Build:

{
  "name": "my-application",
  "version": "1.0.0",
  "scripts": {
    "build": "npm run build:app && npm run sbom",
    "sbom": "cyclonedx-npm --output-file dist/sbom.json",
    "prebuild": "npm ci"
  },
  "devDependencies": {
    "@cyclonedx/cyclonedx-npm": "^1.19.0"
  }
}

GitHub Actions Workflow für npm-Projekte

name: Build and Generate SBOM

on:
  push:
    branches: [main]
  release:
    types: [published]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      
      - name: Install dependencies
        run: npm ci
      
      - name: Build application
        run: npm run build
      
      - name: Generate SBOM
        run: |
          npm install -g @cyclonedx/cyclonedx-npm
          cyclonedx-npm --output-file sbom.json
      
      - name: Upload SBOM as artifact
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.json
          retention-days: 3650  # 10 Jahre Aufbewahrung

Praxisbeispiel 3: SBOM für Kubernetes-Deployments

Kubernetes-Umgebungen erfordern einen mehrschichtigen Ansatz: Neben den Anwendungsabhängigkeiten müssen auch Container-Images und deren Systemkomponenten erfasst werden. Trivy bietet hierfür umfassende Unterstützung.

Container-Image-Scanning mit Trivy

SBOM für ein Container-Image erstellen
trivy image --format cyclonedx --output sbom-image.json myapp:1.0.0

Mit Schwachstellenprüfung kombinieren
trivy image --scanners vuln --format cyclonedx --output sbom-with-vulns.json myapp:1.0.0

SPDX-Format für Compliance
trivy image --format spdx-json --output sbom-spdx.json myapp:1.0.0

Kubernetes-Cluster-Scanning

Trivy kann auch laufende Kubernetes-Cluster analysieren und SBOMs für alle deployten Container erstellen:

Gesamten Cluster scannen
trivy k8s --report summary cluster

SBOM für alle Images im Cluster
trivy k8s --format cyclonedx --output cluster-sbom.json cluster

Spezifischen Namespace scannen
trivy k8s --namespace production --format cyclonedx -o production-sbom.json cluster

GitLab CI/CD Pipeline für Container-Scanning

stages:
  - build
  - scan
  - deploy

variables:
  IMAGE_NAME: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

build:
  stage: build
  image: docker:24
  services:
    - docker:24-dind
  script:
    - docker build -t $IMAGE_NAME .
    - docker push $IMAGE_NAME

generate-sbom:
  stage: scan
  image: aquasec/trivy:latest
  script:
    - trivy image --format cyclonedx --output sbom.json $IMAGE_NAME
    - trivy image --format spdx-json --output sbom-spdx.json $IMAGE_NAME
  artifacts:
    paths:
      - sbom.json
      - sbom-spdx.json
    expire_in: 10 years

vulnerability-scan:
  stage: scan
  image: aquasec/trivy:latest
  script:
    - trivy sbom sbom.json --severity HIGH,CRITICAL --exit-code 1
  allow_failure: false
  dependencies:
    - generate-sbom

GitHub Actions für Kubernetes-Deployments

name: Container Security Pipeline

on:
  push:
    branches: [main]

jobs:
  build-and-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Build Docker image
        run: docker build -t myapp:$ .
      
      - name: Generate SBOM with Trivy
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: 'myapp:$'
          format: 'cyclonedx'
          output: 'sbom.json'
      
      - name: Scan SBOM for vulnerabilities
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'sbom'
          scan-ref: 'sbom.json'
          severity: 'CRITICAL,HIGH'
          exit-code: '1'
      
      - name: Upload SBOM
        uses: actions/upload-artifact@v4
        with:
          name: container-sbom
          path: sbom.json
          retention-days: 3650

Trivy Operator für kontinuierliches Monitoring

Für produktive Kubernetes-Cluster empfiehlt sich der Trivy Operator, der kontinuierlich alle deployten Container scannt:

Installation via Helm
helm repo add aqua https://aquasecurity.github.io/helm-charts/
helm repo update

helm install trivy-operator aqua/trivy-operator \
  --namespace trivy-system \
  --create-namespace \
  --set trivy.severity="HIGH,CRITICAL" \
  --set operator.scanJobTimeout="10m"

Der Operator erstellt automatisch VulnerabilityReports und ConfigAuditReports als Kubernetes Custom Resources, die in Monitoring-Systeme wie Grafana integriert werden können.

SBOM-Integration in CI/CD-Pipelines

Die automatisierte SBOM-Generierung bei jedem Build ist der Schlüssel zur nachhaltigen CRA-Compliance. Eine typische Pipeline-Integration umfasst folgende Schritte:

Build-Phase: SBOM aus Quellcode und Abhängigkeiten generieren, vorzugsweise mit einem Build-Plugin für maximale Genauigkeit.

Container-Phase: Falls das Produkt containerisiert wird, zusätzliche SBOM für das Container-Image erstellen, um auch Betriebssystemkomponenten zu erfassen.

Validierung: SBOM gegen die Anforderungen der TR-03183-2 prüfen und Vollständigkeit der Pflichtfelder sicherstellen.

Archivierung: SBOM versioniert ablegen und mit dem entsprechenden Produktrelease verknüpfen. Die zehnjährige Aufbewahrungspflicht erfordert eine robuste Archivierungsstrategie.

Schwachstellenprüfung: SBOM gegen aktuelle Schwachstellendatenbanken scannen und Ergebnisse in das Schwachstellenmanagement überführen.

SBOM und Schwachstellenmanagement

Die SBOM selbst enthält keine Informationen über Schwachstellen – sie ist ein Inventar, kein Sicherheitsbericht. Ihre Stärke liegt in der Kombination mit Schwachstellendatenbanken und Vulnerability Exploitability Exchange (VEX).

Der Workflow in der Praxis

Bei Bekanntwerden einer neuen Schwachstelle – etwa einer kritischen CVE in einer weit verbreiteten Bibliothek – ermöglicht die SBOM die sofortige Identifikation betroffener Produkte. Automatisierte Tools können alle archivierten SBOMs durchsuchen und innerhalb von Minuten eine Liste betroffener Produktversionen erstellen.

VEX-Dokumente ergänzen diesen Prozess, indem sie dokumentieren, ob eine Schwachstelle in einem konkreten Produkt tatsächlich ausnutzbar ist. Eine Schwachstelle kann in der verwendeten Komponente vorhanden, aber aufgrund der spezifischen Produktkonfiguration nicht ausnutzbar sein. VEX ermöglicht diese differenzierte Bewertung und reduziert damit den Aufwand für Patching und Kommunikation.

Verknüpfung mit dem Incident-Response-Prozess

Die SBOM-basierte Schwachstellenidentifikation sollte direkt in die Meldeprozesse nach CRA integriert werden. Ab dem 11. September 2026 gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen mit einer Frist von 24 Stunden. Eine funktionierende SBOM-Infrastruktur ist Voraussetzung, um diese Fristen einhalten zu können.

Die Kombination aus SBOM und einem strukturierten Schwachstellenmanagement ermöglicht es, bei Bekanntwerden einer neuen CVE innerhalb von Minuten festzustellen, welche Produkte betroffen sind – eine Fähigkeit, die ohne SBOM Stunden oder Tage manueller Analyse erfordern würde.

SBOM im Kontext von ISO 27001 und ISMS

Für Unternehmen mit einem Informationssicherheitsmanagementsystem (ISMS) nach ISO 27001 ist die SBOM-Anforderung eine der wesentlichen Erweiterungen für die CRA-Compliance. ISO 27001:2022 enthält keine direkte Anforderung an Software Bills of Materials, sodass diese als zusätzliche Maßnahme implementiert werden muss.

Die Integration in das bestehende ISMS erfolgt am besten über die Erweiterung der Dokumentationsstrukturen und die Verknüpfung mit bestehenden Controls. Relevant sind insbesondere A.8.8 (Management technischer Schwachstellen) und A.5.19-A.5.22 (Lieferkettenmanagement), die durch SBOM-Prozesse unterstützt und erweitert werden können.

Lieferketten und SBOM-Austausch

Die CRA-Anforderungen betreffen nicht nur eigene Entwicklungen, sondern auch zugekaufte Komponenten und Zulieferprodukte. Hersteller müssen sicherstellen, dass die Cybersicherheitsanforderungen auch für Komponenten von Dritten erfüllt werden.

In der Praxis bedeutet dies, dass Unternehmen SBOM-Anforderungen in ihre Lieferantenverträge aufnehmen sollten. Bei zugekauften Software-Komponenten sollte die Lieferung einer aktuellen SBOM vertraglich vereinbart werden. Dies ermöglicht die Integration der Zuliefererdaten in die eigene SBOM und gewährleistet durchgängige Transparenz.

Für die technische Umsetzung empfiehlt sich die Festlegung auf ein einheitliches Format (SPDX oder CycloneDX) im Lieferantennetzwerk. Die Konvertierung zwischen Formaten ist zwar möglich, kann jedoch zu Datenverlusten führen und erhöht den Verwaltungsaufwand.

Häufige Fehler bei der SBOM-Erstellung

Bei der Implementierung von SBOM-Prozessen treten regelmäßig vermeidbare Fehler auf. Die folgenden Punkte sollten beachtet werden:

Unvollständige Erfassung: Nur den Anwendungscode scannen und Systemabhängigkeiten im Container ignorieren. Lösung: Container-Scanner wie Trivy oder Syft einsetzen, die auch Betriebssystemkomponenten erfassen.

Fehlende Versionierung: SBOMs ohne Bezug zur konkreten Produktversion erstellen. Lösung: SBOM-Generierung in den Release-Prozess integrieren und mit Produktversionsnummern verknüpfen.

Unzureichende Pflichtfelder: Automatisch generierte SBOMs enthalten nicht immer alle nach TR-03183-2 geforderten Felder. Lösung: Validierung der generierten SBOM und manuelle Ergänzung fehlender Pflichtangaben.

Einmalige statt kontinuierliche Erstellung: SBOMs werden nur bei Audits oder auf Anfrage erstellt. Lösung: Automatisierte SBOM-Generierung bei jedem Build implementieren.

Keine Archivierungsstrategie: SBOMs werden erstellt, aber nicht langfristig aufbewahrt. Lösung: Archivierungssystem für die zehnjährige Aufbewahrungspflicht etablieren.

Praktische Umsetzung: Ein Fahrplan

Die SBOM-Implementierung sollte als Teil des umfassenden CRA-Umsetzungsprojekts erfolgen. Die folgenden Schritte bilden einen pragmatischen Einstieg:

Phase 1 – Analyse (2-4 Wochen): Bestandsaufnahme der Produktlandschaft und verwendeten Technologien. Identifikation der relevanten Build-Systeme und Deployment-Prozesse. Auswahl des SBOM-Formats basierend auf Partneranforderungen und Toolunterstützung.

Phase 2 – Pilotierung (4-8 Wochen): Auswahl eines geeigneten Tools und Pilotierung an einem repräsentativen Produkt. Validierung der generierten SBOM gegen TR-03183-2-Anforderungen. Definition von Prozessen für manuelle Ergänzungen.

Phase 3 – Integration (8-12 Wochen): Integration der SBOM-Generierung in CI/CD-Pipelines. Einrichtung der Archivierung und Versionsverwaltung. Etablierung des Schwachstellen-Monitorings auf Basis der SBOM-Daten.

Phase 4 – Rollout (fortlaufend): Ausweitung auf alle relevanten Produkte. Schulung der Entwicklungsteams. Integration in Lieferantenmanagement und Beschaffungsprozesse.

Für Unternehmen, die bereits ein ISMS nach ISO 27001 betreiben, können diese Aktivitäten in die bestehenden Prozesse integriert werden. Eine detaillierte Analyse der Synergien und zusätzlich erforderlichen Maßnahmen bietet unser Artikel ISO 27001 als Basis für den CRA.

SBOM als Fundament der Produktsicherheit

Die Software Bill of Materials ist mehr als eine regulatorische Pflichtübung – sie ist ein fundamentales Werkzeug für die Cybersicherheit digitaler Produkte. Die Transparenz über verwendete Komponenten ermöglicht schnelle Reaktionen auf Schwachstellen, fundierte Risikoentscheidungen und nachweisbare Compliance.

Der Cyber Resilience Act macht die SBOM zur Pflicht und gibt damit einer Best Practice, die in sicherheitsbewussten Organisationen längst etabliert ist, regulatorischen Nachdruck. Unternehmen, die frühzeitig in SBOM-Prozesse investieren, schaffen nicht nur die Grundlage für die CRA-Compliance bis 2027, sondern verbessern auch ihre Reaktionsfähigkeit bei Sicherheitsvorfällen und stärken das Vertrauen von Kunden und Partnern.

Die verfügbaren Open-Source-Tools machen den Einstieg niedrigschwellig. Mit Syft, Trivy oder cdxgen können erste SBOMs innerhalb weniger Stunden generiert werden. Die Herausforderung liegt weniger in der technischen Umsetzung als in der nachhaltigen Integration in Entwicklungsprozesse und der langfristigen Archivierung.

SBOM und Schwachstellenmanagement im CRA-Kontext

Die Implementierung einer SBOM-Infrastruktur ist ein strategisches Projekt, das technische Expertise und Prozessverständnis erfordert. Die SBOM-Anforderung ist ein zentraler Baustein der CRA-Compliance. Wir unterstützen Ihr Unternehmen bei der Umsetzung aller CRA-Anforderungen, insbesondere beim Aufbau von strukturiertem Schwachstellenmanagement und der Integration mit bestehenden ISMS-Strukturen nach ISO 27001.

Für Unternehmen, die bereits ein ISMS nach ISO 27001 betreiben, können SBOM-Prozesse in die bestehenden Dokumentationsstrukturen integriert werden. Eine detaillierte Analyse der Synergien bietet unser Fachartikel zu ISO 27001 als Basis für den CRA.

Professionelle Unterstützung

Cyber Resilience Act Beratung: Ganzheitliche CRA-Compliance mit Fokus auf SBOM-Management, Schwachstellenmanagement und sichere Produktentwicklung.

Externe Ressourcen: