Die Zahl der Cyberangriffe auf Software-Lieferketten ist in den letzten drei Jahren um über 300 Prozent gestiegen. Supply Chain Security ist dabei längst kein Thema mehr, das nur Konzerne betrifft. Gerade kleine und mittelständische Unternehmen sind zunehmend im Visier, weil Angreifer sie als Einstiegspunkt in größere Netzwerke nutzen. Wer heute Software entwickelt oder einsetzt, trägt Verantwortung – für jede Bibliothek, jeden Drittanbieter und jede Automatisierung im eigenen Build-Prozess.
Dieser Leitfaden zeigt praxisnah, was Supply Chain Security für KMU konkret bedeutet, welche Angriffsvektoren Sie kennen müssen und wie Sie Schritt für Schritt ein robustes Sicherheitskonzept aufbauen.
Was Supply Chain Security für KMU bedeutet
Supply Chain Security bezeichnet alle Maßnahmen, die sicherstellen, dass Software auf dem Weg von der Entwicklung bis zur Auslieferung an den Nutzer nicht kompromittiert wird. Die „Lieferkette" umfasst dabei:
- Quellcode und Versionsverwaltung (z. B. Git-Repositories)
- Abhängigkeiten (npm-Pakete, Maven-Bibliotheken, Python-Module)
- Build- und CI/CD-Systeme
- Container-Images und Infrastruktur-Skripte
- Drittanbieter-Plugins und SaaS-Integrationen
Ein Angriff muss nicht direkt Ihre Anwendung treffen. Es reicht, eine einzige abhängige Bibliothek zu kompromittieren – und der schadhafter Code landet automatisch in Ihrem Produkt. Das macht Supply Chain Security so komplex und gleichzeitig so kritisch.
Warum KMU besonders gefährdet sind
Viele Mittelständler gehen davon aus, dass Hacker vor allem auf große Konzerne abzielen. Das stimmt nicht mehr. Angreifer nutzen KMU gezielt als Sprungbrett, weil dort oft weniger Ressourcen für Sicherheitsmaßnahmen vorhanden sind. Laut einer Studie des Bundesamts für Sicherheit in der Informationstechnik (BSI Lagebericht 2024) waren im Jahr 2024 über 60 Prozent der Ransomware-Vorfälle in Deutschland auf Unternehmen mit weniger als 250 Mitarbeitern zurückzuführen.
Hinzu kommt: Wer als Zulieferer oder Dienstleister für größere Unternehmen tätig ist, wird zum attraktiven Ziel – denn über die Schnittstelle zum Kunden lassen sich weitreichendere Angriffe starten.
Die häufigsten Angriffsvektoren in der Software-Lieferkette
Um Supply Chain Security wirksam umzusetzen, müssen Sie die Angriffswege kennen. Die folgenden Vektoren sind in der Praxis am häufigsten anzutreffen:
1. Dependency Confusion und Typosquatting
Angreifer veröffentlichen schadhafter Pakete unter Namen, die bekannten Bibliotheken täuschend ähnlich sehen – zum Beispiel `lodahs` statt `lodash`. Automatisierte Package-Manager installieren das falsche Paket, ohne dass ein Entwickler es bemerkt.
Konkrete Maßnahme: Verwenden Sie private Package-Registries (z. B. Nexus Repository oder GitHub Packages) und konfigurieren Sie Ihre Build-Tools so, dass öffentliche Registries nur als Fallback genutzt werden.
2. Kompromittierte CI/CD-Pipelines
Build-Server und Deployment-Pipelines sind hochprivilegierte Systeme. Wer Zugriff auf GitHub Actions, Jenkins oder GitLab CI hat, kann theoretisch Schadsoftware in jedes Deployment einschleusen. Secrets wie API-Keys oder Deployment-Token sind oft nicht ausreichend geschützt.
Konkrete Maßnahme: Trennen Sie Build- und Produktionsumgebungen konsequent. Rotieren Sie Secrets regelmäßig und beschränken Sie Zugriffsrechte auf das notwendige Minimum (Principle of Least Privilege).
3. Kompromittierte Open-Source-Bibliotheken
Der SolarWinds-Angriff 2020 und der XZ Utils Backdoor-Vorfall 2024 haben gezeigt: Selbst weit verbreitete und vertrauenswürdige Bibliotheken können gezielt manipuliert werden. Bei Open-Source-Projekten mit kleinem Maintainer-Team besteht ein erhöhtes Risiko, dass ein Angreifer dauerhaften Zugang erlangt.
Konkrete Maßnahme: Prüfen Sie regelmäßig den Aktivitätsstatus Ihrer Abhängigkeiten. Bibliotheken, die seit mehr als 12 Monaten nicht mehr aktualisiert wurden, sollten auf Alternativen geprüft werden.
4. Manipulierte Container-Images
Wer Docker-Images aus öffentlichen Registries wie Docker Hub bezieht, kann nicht immer sicher sein, dass das Image nicht nachträglich verändert wurde. Base-Images können Schadsoftware enthalten, die erst im Produktionsbetrieb aktiv wird.
Konkrete Maßnahme: Signieren Sie alle eigenen Images mit Docker Content Trust oder Sigstore. Nutzen Sie ausschließlich verifizierte Base-Images von offiziellen Quellen und scannen Sie Images automatisiert vor dem Deployment.
Supply Chain Security: Konkrete Maßnahmen für KMU
Jetzt wird es praktisch. Die folgenden Maßnahmen lassen sich auch ohne dediziertes Security-Team Schritt für Schritt einführen.
Schritt 1: Inventar Ihrer Software-Abhängigkeiten erstellen
Bevor Sie absichern können, müssen Sie wissen, was vorhanden ist. Erstellen Sie eine Software Bill of Materials (SBOM) – eine vollständige Liste aller verwendeten Komponenten, Versionen und Lizenzen. Tools wie Syft oder CycloneDX generieren SBOMs automatisch aus Ihren Projekten.
- Welche Bibliotheken verwenden Sie direkt?
- Welche Transitivabhängigkeiten werden mitinstalliert?
- Welche Versionen sind aktuell im Einsatz?
Mit einer gepflegten SBOM können Sie bei neu entdeckten Schwachstellen sofort prüfen, ob Sie betroffen sind.
Schritt 2: Automatisiertes Vulnerability Scanning einrichten
Manuelle Sicherheitsprüfungen sind nicht skalierbar. Integrieren Sie automatisierte Scanner direkt in Ihre CI/CD-Pipeline:
- OWASP Dependency-Check: Prüft bekannte CVEs in Java, .NET und anderen Ökosystemen
- Trivy: Scannt Container-Images, Dateisysteme und Git-Repositories
- Snyk: Bietet eine entwicklerfreundliche Oberfläche mit direkten Fix-Vorschlägen
- GitHub Dependabot: Erstellt automatisch Pull Requests für veraltete Abhängigkeiten
Ziel: Jeder neue Build sollte automatisch auf bekannte Schwachstellen geprüft werden – und bei kritischen Findings fehlschlagen, bevor schadhafter Code produktiv geht.
Schritt 3: Code-Signing und Artefakt-Integrität
Wie stellen Sie sicher, dass der Code, der deployed wird, wirklich derselbe ist, der entwickelt wurde? Code-Signing löst dieses Problem: Jedes Build-Artefakt wird mit einem kryptografischen Schlüssel signiert. Beim Deployment wird die Signatur verifiziert.
Mit dem Open-Source-Framework Sigstore (unterstützt von Google, Red Hat und Purdue University) können Sie:
1. Build-Artefakte signieren (mit `cosign`)
2. Signaturen transparent in einem öffentlichen Log verankern (Rekor)
3. Signaturen beim Deployment automatisch verifizieren
Das ist kein aufwändiges Enterprise-Tool mehr – Sigstore ist für moderne KMU-Projekte auch ohne Security-Team bedienbar.
Schritt 4: Branch-Schutz und Vier-Augen-Prinzip im Code-Review
Supply Chain Security beginnt beim Quellcode selbst. Konfigurieren Sie Ihr Repository so, dass:
- Direkte Pushes auf den `main`-Branch verboten sind
- Jede Änderung mindestens einen Code-Review erfordert
- Automatisierte Tests und Security-Scans bestehen müssen, bevor ein Merge erlaubt ist
Das kostet wenig Aufwand, schließt aber eine der häufigsten Schwachstellen – böswillige oder fehlerhafte Direktänderungen am Produktionscode.
Schritt 5: Zugriffsmanagement für CI/CD-Systeme
Ihre Build-Pipeline hat Zugriff auf Deployment-Tokens, Cloud-Credentials und Produktionsdatenbanken. Entsprechend hoch ist das Risiko. Setzen Sie konsequent auf:
- Kurzlebige Tokens statt dauerhafter API-Keys
- OIDC-basierte Authentifizierung zwischen CI/CD-System und Cloud-Providern (ohne statische Secrets)
- Separate Service-Accounts mit minimalen Berechtigungen für jeden Deployment-Schritt
- Regelmäßige Rotation aller Zugangsdaten (mindestens alle 90 Tage)
Supply Chain Security in der Praxis: Ein KMU-Beispiel
Ein mittelständisches Softwarehaus aus München mit 35 Mitarbeitern setzte eine Node.js-Webanwendung ein, die auf über 400 npm-Pakete zurückgriff. Nach einem Security-Audit zeigte sich: Sechs Pakete enthielten bekannte kritische Schwachstellen – darunter eine, die seit 14 Monaten gepatcht, aber nie aktualisiert worden war.
Maßnahmen, die innerhalb von vier Wochen umgesetzt wurden:
1. SBOM-Generierung mit CycloneDX automatisiert
2. Trivy in die GitHub-Actions-Pipeline integriert
3. Dependabot aktiviert und wöchentliche Dependency-Updates eingeplant
4. Branch-Schutz mit obligatorischem Code-Review eingeführt
5. Alle CI/CD-Secrets in GitHub Secrets verschoben und rotiert
Ergebnis: Bei der nächsten Schwachstelle in einem verwendeten Paket (log4j-ähnlicher Vorfall in einem internen Tool) wurde das Team automatisch innerhalb von zwei Stunden benachrichtigt – und konnte noch am selben Tag reagieren, bevor produktive Systeme betroffen waren.
Supply Chain Security und regulatorische Anforderungen
Wer in Deutschland oder der EU Software entwickelt oder betreibt, kommt an regulatorischen Anforderungen nicht mehr vorbei. Supply Chain Security ist dabei zunehmend explizit gefordert:
- NIS2-Richtlinie: Verpflichtet betroffene Unternehmen zur Absicherung ihrer Lieferkette und zur Meldung von Sicherheitsvorfällen
- Cyber Resilience Act (CRA): Schreibt für Produkte mit digitalen Elementen konkrete Sicherheitsanforderungen vor – inklusive Schwachstellenmanagement
- BSI IT-Grundschutz: Enthält dedizierte Bausteine zur Absicherung von Software-Lieferketten
KMU, die als Zulieferer für größere Unternehmen tätig sind, werden zunehmend vertraglich verpflichtet, Nachweise über ihre Supply Chain Security-Maßnahmen zu erbringen. Wer frühzeitig handelt, verschafft sich hier einen echten Wettbewerbsvorteil.
Die wichtigsten Tools im Überblick
| Tool | Zweck | Kosten |
|---|---|---|
| Trivy | Container- und Code-Scanning | Open Source |
| Syft | SBOM-Generierung | Open Source |
| Snyk | Dependency-Scanning mit Fix-Vorschlägen | Freemium |
| Sigstore/cosign | Code-Signing und Verifikation | Open Source |
| OWASP Dep-Check | CVE-Prüfung für Bibliotheken | Open Source |
| GitHub Dependabot | Automatische Dependency-Updates | Im GitHub-Abo |
Für die meisten KMU reicht eine Kombination aus Trivy + Syft + Dependabot, um einen soliden Grundschutz aufzubauen – ohne zusätzliche Lizenzkosten.
Häufige Fehler bei der Umsetzung
Auch gut gemeinte Sicherheitsmaßnahmen scheitern, wenn bestimmte Fehler gemacht werden:
- Nur auf direkte Abhängigkeiten schauen: Transitivabhängigkeiten (die Abhängigkeiten Ihrer Abhängigkeiten) sind ebenso gefährlich
- Security-Findings ignorieren: Wenn Scanner-Warnungen dauerhaft unbeachtet bleiben, verlieren sie ihre Wirkung
- Sicherheit als einmalige Aufgabe verstehen: Supply Chain Security erfordert kontinuierliche Pflege, nicht nur ein einmaliges Audit
- Zu wenig Automatisierung: Manuelle Prozesse werden unter Zeitdruck übersprungen – Automatisierung in der Pipeline ist robuster
- Fehlende Verantwortlichkeit: Wenn niemand explizit für das Thema zuständig ist, fällt es im Tagesgeschäft hinten runter
Mehr über das strukturierte Management von Software-Abhängigkeiten erfahren Sie auch im Pilecode Blog, wo wir regelmäßig praxisnahe Guides für KMU veröffentlichen.
Nächste Schritte: So starten Sie heute
Supply Chain Security muss kein großes Projekt sein. Starten Sie mit diesen drei Sofortmaßnahmen:
1. SBOM erstellen: Führen Sie `syft . -o cyclonedx-json` in Ihrem wichtigsten Projekt aus und verschaffen Sie sich einen Überblick über alle Abhängigkeiten.
2. Trivy einrichten: Integrieren Sie einen einfachen `trivy fs .`-Schritt in Ihre bestehende CI/CD-Pipeline.
3. Dependabot aktivieren: Klicken Sie in GitHub unter „Settings → Security → Dependabot" auf Aktivieren – das dauert unter fünf Minuten.
Diese drei Schritte kosten Sie zusammen weniger als einen halben Arbeitstag und erhöhen Ihr Sicherheitsniveau signifikant. Haben Sie Fragen zur konkreten Umsetzung in Ihrem Unternehmen oder möchten Sie Ihre bestehende Software-Lieferkette professionell absichern lassen? Das Pilecode-Team unterstützt Sie dabei – vom ersten Audit bis zur vollständig integrierten Security-Pipeline.
Jetzt kostenloses Erstgespräch vereinbaren →
Haben Sie Fragen zu diesem Thema? Jetzt Kontakt aufnehmen.