Wer Software einsetzt, vertraut täglich auf Hunderte von Komponenten, die er selbst nie geschrieben hat. Bibliotheken, Frameworks, Open-Source-Pakete – all das bildet die Software-Lieferkette eines Unternehmens. Und genau hier entstehen Sicherheitslücken, die Angreifer systematisch ausnutzen. Der Log4Shell-Angriff Ende 2021 hat gezeigt, wie eine einzelne Java-Bibliothek zehntausende Systeme weltweit gefährden kann – darunter zahlreiche KMU, die nicht einmal wussten, dass sie die betroffene Komponente einsetzen. Mit einem SBOM Software-Lieferkette-Ansatz lässt sich genau dieses Blindflug-Problem lösen.
Dieser Leitfaden erklärt, was ein SBOM ist, warum es für KMU relevant ist und wie Sie es Schritt für Schritt in Ihrem Unternehmen einführen.
Was ein SBOM mit Ihrer Software-Lieferkette zu tun hat
SBOM steht für Software Bill of Materials – auf Deutsch: Software-Stückliste. Der Begriff stammt aus der Fertigungsindustrie: Jede Maschine hat eine Stückliste, die exakt auflistet, welche Teile verbaut sind. Dasselbe Prinzip lässt sich auf Software übertragen.
Ein SBOM ist ein maschinenlesbares Dokument, das alle Komponenten einer Softwareanwendung auflistet:
- Bibliotheken und Pakete (z. B. npm, Maven, PyPI)
- Versionsnummern jeder Komponente
- Lizenzinformationen
- Herkunft und Bezugsquelle der Pakete
- Abhängigkeiten zwischen Komponenten (transitive Dependencies)
Die zwei wichtigsten offenen Standards für SBOM-Formate sind SPDX – vom Linux-Foundation-Projekt gepflegt – und CycloneDX, das besonders im Security-Umfeld populär ist. Beide werden von gängigen Entwicklungswerkzeugen unterstützt.
Warum die SBOM Software-Lieferkette für KMU geschäftskritisch wird
Viele Geschäftsführer und CTOs in kleinen und mittelständischen Unternehmen gehen davon aus, dass Supply-Chain-Sicherheit ein Enterprise-Thema sei. Das ist ein gefährlicher Irrtum. Gerade KMU sind attraktive Ziele, weil sie oft weniger Schutzmaßnahmen haben als Großkonzerne – aber als Zulieferer oder Dienstleister Zugang zu deren Systemen besitzen.
Aktuelle Zahlen belegen die Dringlichkeit:
- Laut Gartner werden bis 2025 rund 45 % aller Organisationen weltweit einen Software-Supply-Chain-Angriff erlebt haben.
- Der Angriff auf SolarWinds (2020) kompromittierte über 18.000 Organisationen über ein einziges Software-Update.
- Das BSI (Bundesamt für Sicherheit in der Informationstechnik) stuft die Bedrohungslage für die Software-Lieferkette als „hoch" ein.
Hinzu kommt der regulatorische Druck: Der europäische Cyber Resilience Act (CRA), der schrittweise in Kraft tritt, verlangt von Herstellern digitaler Produkte explizit ein SBOM für sicherheitsrelevante Software. Unternehmen, die heute beginnen, sparen morgen Aufwand bei der Compliance.
Die häufigsten Risiken in der Software-Lieferkette
Bevor Sie Schutzmaßnahmen einführen, müssen Sie die typischen Angriffsvektoren kennen. Eine kompromittierte Software-Lieferkette kann auf verschiedenen Wegen entstehen:
Typosquatting und Paket-Manipulation
Angreifer veröffentlichen Pakete mit ähnlich klingenden Namen wie populäre Bibliotheken – z. B. `lodahs` statt `lodash`. Entwickler, die sich vertippt haben, installieren unwissentlich Schadsoftware. Automatisiertes SBOM-Scanning erkennt solche Anomalien zuverlässig.
Veraltete Abhängigkeiten mit bekannten CVEs
Jedes Softwareprojekt baut auf Abhängigkeiten auf, die wiederum Abhängigkeiten haben – sogenannte transitive Dependencies. Eine einzige veraltete Bibliothek tief in der Abhängigkeitskette kann eine kritische Schwachstelle (CVE) öffnen, ohne dass die direkten Entwickler etwas davon merken.
Kompromittierte Build-Pipelines
Der Build-Prozess selbst ist ein Angriffsziel. Wird in der CI/CD-Pipeline Schadsoftware eingeschleust, landet sie in allen daraus erzeugten Releases – ohne dass der Quellcode angetastet wird. Dieses Muster nutzten die Angreifer beim SolarWinds-Hack.
Lizenz-Risiken als unterschätztes Problem
Nicht jedes Risiko ist ein Cyberangriff. Copyleft-Lizenzen wie die GPL können dazu verpflichten, eigenen proprietären Code offenzulegen, wenn eine entsprechend lizenzierte Bibliothek verwendet wird. Ein SBOM zeigt sofort, welche Lizenzen im Einsatz sind.
SBOM Software-Lieferkette: So starten Sie als KMU
Ein vollständiges SBOM-Programm klingt komplex, lässt sich aber in überschaubare Phasen einteilen. Hier ist ein praxiserprobter Einstiegsplan für KMU mit begrenztem IT-Personal.
Phase 1: Bestandsaufnahme – Inventar Ihrer Softwarekomponenten
Beginnen Sie nicht mit Tools, sondern mit Klarheit. Beantworten Sie zunächst:
1. Welche Softwareprojekte und Anwendungen betreiben oder entwickeln Sie?
2. Welche Paketverwaltungssysteme nutzen Ihre Entwickler (npm, pip, Maven, NuGet)?
3. Setzen Sie Software von Drittanbietern ein, ohne Zugang zum Quellcode zu haben?
Erstellen Sie ein einfaches Inventar in einer Tabelle. Dieser erste Schritt kostet keine Lizenzgebühren und schafft unmittelbaren Überblick.
Phase 2: SBOM-Generierung automatisieren
Im zweiten Schritt integrieren Sie SBOM-Generierung in Ihre Entwicklungspipeline. Bewährte Open-Source-Tools dafür sind:
- Syft (von Anchore): Generiert SBOMs aus Container-Images, Verzeichnissen und Paketen; unterstützt SPDX und CycloneDX
- cdxgen: Spezialisiert auf CycloneDX, unterstützt über 20 Programmiersprachen
- Trivy: Kombiniert SBOM-Erstellung mit Schwachstellen-Scanning
Ein einfaches Beispiel mit Syft in einer GitHub-Actions-Pipeline:
yaml
- name: Generate SBOM
uses: anchore/sbom-action@v0
with:
format: spdx-json
output-file: sbom.spdx.jsonMit wenigen Zeilen Konfiguration erzeugt jeder Build automatisch ein aktuelles SBOM – ohne manuellen Aufwand.
Phase 3: Schwachstellen-Scanning auf Basis des SBOM
Ein SBOM allein schützt nicht – es ist die Grundlage für das Scanning. Tools wie Grype oder OWASP Dependency-Check vergleichen Ihre Komponentenliste mit bekannten CVE-Datenbanken und priorisieren Risiken nach CVSS-Score.
Empfehlenswerte Priorisierung:
- CVSS ≥ 9.0 (Critical): Sofortiger Patch, keine Ausnahmen
- CVSS 7.0–8.9 (High): Patch innerhalb von 7 Tagen
- CVSS 4.0–6.9 (Medium): Im nächsten Release-Zyklus adressieren
- CVSS < 4.0 (Low): Dokumentieren, Risiko akzeptieren oder langfristig beheben
SBOM-Pflege im Tagesgeschäft: Prozesse für KMU
Ein SBOM ist kein Projekt, das man abschließt – es ist ein kontinuierlicher Prozess. Diese drei Maßnahmen sichern den dauerhaften Nutzen:
1. SBOM bei jedem Release aktualisieren
Verankern Sie die SBOM-Generierung als Pflichtschritt in Ihrer CI/CD-Pipeline. Kein Release ohne aktuelles SBOM. Das erzeugt keinerlei Mehraufwand, wenn die Automatisierung erst einmal steht.
2. Abhängigkeiten regelmäßig aktualisieren
Werkzeuge wie Dependabot (GitHub) oder Renovate Bot erstellen automatisch Pull Requests, wenn neue Versionen verfügbar sind. In Kombination mit dem SBOM-Scanner erkennen Sie sofort, welche Updates sicherheitsrelevant sind.
3. SBOM als Teil des Vendor-Managements einfordern
Wenn Sie Software von externen Dienstleistern oder Anbietern beziehen, fordern Sie zukünftig ein SBOM als Vertragsbestandteil. Das ist heute bereits Marktstandard in der Luft- und Raumfahrt sowie im US-amerikanischen Behördenbereich – und wird im europäischen Markt durch den Cyber Resilience Act zur Pflicht.
SBOM und Compliance: Was KMU jetzt wissen müssen
Der Cyber Resilience Act (CRA) der EU ist das wichtigste regulatorische Signal. Er gilt für alle Produkte mit digitalen Elementen, die in der EU in Verkehr gebracht werden – und das schließt viele mittelständische Softwareanbieter ein. Wesentliche Anforderungen:
- Hersteller müssen Schwachstellen über den gesamten Produktlebenszyklus aktiv managen
- Ein SBOM ist explizit als Instrument zur Erreichung dieser Anforderung genannt
- Verstöße können mit Bußgeldern bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes geahndet werden
Auch die NIS-2-Richtlinie, die seit Oktober 2024 in deutsches Recht umgesetzt wird, adressiert die Sicherheit der Lieferkette als Pflichtbereich für betroffene Unternehmen. Supply-Chain-Sicherheit ist damit keine freiwillige Best Practice mehr, sondern gesetzliche Anforderung für eine wachsende Zahl von KMU.
Gut zu wissen: Wer ein funktionierendes SBOM-Programm betreibt, erfüllt gleichzeitig wesentliche Anforderungen beider Regelwerke – und spart damit doppelt: an Risiko und an Compliance-Aufwand.
Weitere Informationen zu Sicherheitsthemen rund um Container und moderne Deployments finden Sie auch im Pilecode Blog.
Typische Fehler bei der SBOM-Einführung – und wie Sie sie vermeiden
KMU, die SBOM-Programme starten, machen häufig dieselben Fehler. Kennen Sie diese, können Sie sie von Anfang an umgehen:
- SBOM nur einmalig erstellen: Ein statisches SBOM veraltet schnell und gibt falsches Sicherheitsgefühl. Automatisieren Sie die Erstellung.
- Transitive Dependencies ignorieren: Direkte Abhängigkeiten machen oft weniger als 30 % des tatsächlichen Komponentenbestands aus. Tools müssen auch indirekte Abhängigkeiten erfassen.
- SBOM ohne Prozess einführen: Das Dokument nutzt nichts, wenn niemand weiß, wer bei einem kritischen CVE-Fund handeln muss. Definieren Sie klare Verantwortlichkeiten.
- Lizenz-Analyse vernachlässigen: Sicherheit und Lizenz-Compliance sind zwei Seiten derselben Medaille. Nutzen Sie Tools, die beides abdecken.
- Kein Vendor-SBOM einfordern: Ihre eigene Software ist nur ein Teil der Lieferkette. Auch zugekaufte Komponenten müssen transparent sein.
Schnell starten: Ihre SBOM-Checkliste für KMU
Wenn Sie heute beginnen wollen, nutzen Sie diese priorisierte Liste:
1. Inventar erstellen: Alle Anwendungen und Projekte dokumentieren
2. Paketverwaltung kartieren: Welche Ökosysteme (npm, pip, Maven etc.) sind im Einsatz?
3. Tool auswählen: Syft oder cdxgen für den Start – kostenlos, Open Source
4. CI/CD-Integration: SBOM-Generierung im Build-Prozess verankern
5. Schwachstellen-Scan aktivieren: Grype oder Trivy täglich laufen lassen
6. Alert-Prozess definieren: Wer handelt bei CVSS ≥ 7.0?
7. Vendor-Kommunikation starten: SBOMs von kritischen Lieferanten anfragen
8. Dokumentation und Audit-Trail: SBOMs versioniert speichern, mindestens 3 Jahre
Mit diesem Plan können die meisten KMU innerhalb von zwei bis vier Wochen ein funktionsfähiges SBOM-Programm aufbauen – ohne externes Beratungsbudget in sechsstelliger Höhe.
Fazit: SBOM als strategische Investition in Ihre Software-Lieferkette
Die SBOM Software-Lieferkette-Transparenz ist keine Kür mehr, sondern zunehmend Pflicht – regulatorisch, sicherheitstechnisch und wirtschaftlich. KMU, die heute investieren, profitieren dreifach: Sie reduzieren das Angriffsrisiko, erfüllen kommende gesetzliche Anforderungen proaktiv und schaffen Vertrauen bei Kunden und Partnern, die zunehmend Nachweise zur Lieferkettensicherheit verlangen.
Der Einstieg kostet keine großen Budgets – sondern vor allem die Bereitschaft, Software nicht mehr als Black Box zu behandeln. Mit den richtigen Tools, klaren Prozessen und einer Automatisierungsstrategie ist ein solides SBOM-Programm auch für kleine IT-Teams realisierbar.
Wenn Sie Unterstützung benötigen – sei es bei der technischen Implementierung, der Integration in bestehende CI/CD-Pipelines oder der Vorbereitung auf den Cyber Resilience Act – stehen wir Ihnen gerne zur Seite.
Jetzt kostenloses Erstgespräch vereinbaren →
Haben Sie bereits konkrete Fragen zu Ihrer Sicherheitsstrategie? Sprechen Sie uns direkt an – wir beraten Sie unverbindlich und praxisnah.
Haben Sie Fragen zu diesem Thema? Jetzt Kontakt aufnehmen.