Supply-Chain-Angriffe gehören heute zu den gefährlichsten Bedrohungen für Unternehmen – und sie treffen längst nicht mehr nur Konzerne. Gerade kleine und mittelständische Unternehmen unterschätzen, wie exponiert ihre Software-Lieferkette tatsächlich ist. Wer seine Software-Lieferkette schützen will, muss verstehen, wo die Risiken entstehen, wie Angreifer vorgehen und welche konkreten Schutzmaßnahmen sich auch mit begrenzten Ressourcen umsetzen lassen.
Dieser Leitfaden zeigt Ihnen, worauf es 2026 ankommt – praxisnah, ohne unnötigen Fachjargon und mit direkten Handlungsempfehlungen.
Was bedeutet es, die Software-Lieferkette zu schützen?
Die Software-Lieferkette umfasst alle Komponenten, Prozesse und Akteure, die an der Erstellung, Bereitstellung und Wartung Ihrer Software beteiligt sind. Dazu gehören:
- Open-Source-Bibliotheken und Frameworks, die in Ihrer Anwendung eingesetzt werden
- Entwicklungstools, Build-Systeme und CI/CD-Pipelines
- Externe Entwickler, Agenturen und Softwaredienstleister
- Cloud-Dienste und APIs von Drittanbietern
- Paketmanager wie npm, pip, Maven oder NuGet
Ein Supply-Chain-Angriff liegt vor, wenn ein Angreifer nicht direkt Ihr System attackiert, sondern eine Schwachstelle in einer dieser vorgelagerten Komponenten ausnutzt. Das Ergebnis: Schadcode gelangt über vertrauenswürdige Kanäle in Ihre Produktionssysteme – oft ohne dass Sie es bemerken.
Das bekannteste Beispiel ist der SolarWinds-Angriff, bei dem kompromittierte Software-Updates an Tausende von Organisationen weltweit verteilt wurden. Doch auch kleinere Attacken wie das Einschleusen von schadhaften npm-Paketen treffen täglich Unternehmen jeder Größe.
Warum KMU ihre Software-Lieferkette schützen müssen
Viele Geschäftsführer glauben, dass Supply-Chain-Angriffe ein Problem großer Konzerne sind. Diese Annahme ist gefährlich falsch. Laut einer Studie des Bundesamts für Sicherheit in der Informationstechnik (BSI) war 2024 jedes dritte KMU in Deutschland von einer sicherheitsrelevanten Vorfällen durch Drittanbieter-Software betroffen.
Die Gründe, warum KMU besonders gefährdet sind:
1. Geringere Sicherheitsressourcen: Kein dediziertes Security-Team, das Abhängigkeiten kontinuierlich überwacht
2. Hoher Open-Source-Anteil: Moderne Anwendungen bestehen zu 70–90 % aus Drittanbieter-Code
3. Fehlende Transparenz: Unternehmen wissen oft nicht, welche Bibliotheken in welcher Version tatsächlich im Einsatz sind
4. Vertrauensblindheit: Updates von bekannten Quellen werden selten hinterfragt
5. Regulatorischer Druck: NIS2-Richtlinie und andere EU-Vorgaben verpflichten auch KMU zur Absicherung ihrer Lieferkette
Wer jetzt handelt, schützt nicht nur seine eigene Infrastruktur, sondern auch seine Kunden und Partner.
Die größten Angriffsvektoren in der Software-Lieferkette
Kompromittierte Open-Source-Pakete
Open-Source-Software ist ein Segen für die Entwicklung – und ein Risiko, wenn Pakete schlecht gepflegt oder aktiv manipuliert werden. Angreifer registrieren bewusst ähnlich klingende Paketnamen (Typosquatting), um Entwickler zur versehentlichen Installation von Schadsoftware zu verleiten.
Bekannte Angriffe dieser Art:
- event-stream: Ein npm-Paket mit 2 Millionen Downloads pro Woche wurde mit schadhaftem Code versehen
- colors.js: Ein populäres Paket wurde vom eigenen Autor sabotiert, um Nutzer auf Endlosschleifen hinzuweisen
- PyPI-Angriffe: Regelmäßig entdecken Sicherheitsforscher schadhafte Python-Pakete mit irreführenden Namen
Kompromittierte Build- und CI/CD-Pipelines
Ihre Deployment-Pipeline ist ein kritischer Angriffsvektor. Wenn ein Angreifer Zugang zur Build-Umgebung erhält, kann er Code einschleusen, der erst im Produktionssystem aktiviert wird. Secrets in Git-Repositories, unsichere Umgebungsvariablen oder unkontrollierte Container-Images sind typische Einfallstore.
Unsichere Drittanbieter und Entwicklungspartner
Wenn Sie externe Agenturen oder Freelancer einsetzen, erweitern Sie Ihre Angriffsfläche. Ein kompromittierter Laptop eines externen Entwicklers kann ausreichen, um Schadcode in Ihre Codebasis einzuschleusen.
So schützen Sie Ihre Software-Lieferkette: 7 konkrete Maßnahmen
1. Software Bill of Materials (SBOM) erstellen und pflegen
Eine SBOM (Software Bill of Materials) ist das Fundament jeder Supply-Chain-Sicherheitsstrategie. Sie listet alle Komponenten, Bibliotheken und Abhängigkeiten Ihrer Software vollständig auf – vergleichbar mit einer Zutatenliste bei Lebensmitteln.
Mit einer SBOM können Sie:
- Schnell prüfen, ob eine bekannte Schwachstelle Ihre Software betrifft
- Lizenzrisiken bei Open-Source-Komponenten identifizieren
- Regulatorische Anforderungen (z. B. nach NIS2 oder dem US Executive Order on Cybersecurity) nachweislich erfüllen
Tools zur SBOM-Erstellung: Syft, CycloneDX, SPDX-Tools
2. Automatisiertes Dependency-Scanning einführen
Manuelle Überprüfungen von Abhängigkeiten sind bei modernen Anwendungen mit Hunderten von Libraries schlicht nicht praktikabel. Automatisiertes Scanning erkennt bekannte Schwachstellen (CVEs) sofort und warnt Ihr Team, bevor kompromittierter Code in Produktion geht.
Empfehlenswerte Tools:
- Dependabot (in GitHub integriert, kostenlos)
- Snyk (mit kostenlosem Einstiegstarif)
- OWASP Dependency-Check (Open Source)
- Trivy (für Container-Images)
Integrieren Sie diese Tools direkt in Ihre CI/CD-Pipeline, sodass jeder Build automatisch geprüft wird.
3. Pinning und Integritätsprüfung von Abhängigkeiten
Statt immer die neueste Version einer Bibliothek zu installieren, sollten Sie exakte Versionen pinnen und kryptografische Hashes (Checksums) prüfen. So stellen Sie sicher, dass genau das Paket installiert wird, das Sie getestet haben – und nicht eine manipulierte Version.
Praktische Umsetzung:
- `package-lock.json` (npm) und `yarn.lock` immer in die Versionskontrolle einpflegen
- `pip freeze` für Python-Abhängigkeiten nutzen
- Bei Container-Images: SHA256-Digests statt Tags referenzieren
4. Least-Privilege-Prinzip für Build-Systeme
Ihre CI/CD-Pipeline sollte nur die Berechtigungen erhalten, die sie tatsächlich benötigt. Minimale Rechte für Build-Prozesse reduzieren den Schaden, den ein Angreifer im Falle eines kompromittierten Build-Systems anrichten kann.
Konkrete Maßnahmen:
- Separate Service-Accounts für Build- und Deployment-Prozesse
- Kurze Token-Laufzeiten für API-Zugriffe
- Secrets ausschließlich über sichere Vault-Systeme (z. B. HashiCorp Vault) bereitstellen
- Niemals Passwörter oder API-Keys im Quellcode oder in Git-Repositories speichern
5. Zulieferer und Partner aktiv prüfen
Wenn externe Entwickler oder Agenturen an Ihrem Code arbeiten, gilt: Vertrauen ist gut, Kontrolle ist besser. Legen Sie vertragliche Sicherheitsanforderungen fest und prüfen Sie regelmäßig, ob diese eingehalten werden.
Checkliste für den Umgang mit Softwarepartnern:
- [ ] Sicherheitsanforderungen im Vertrag verankern
- [ ] Zugriffsrechte auf das Notwendigste beschränken
- [ ] Zugänge nach Projektende sofort widerrufen
- [ ] Code-Reviews für externe Beiträge einführen
- [ ] Nachweis über aktuelle Sicherheitszertifizierungen (z. B. ISO 27001) anfordern
6. Signierung von Code und Artefakten
Code-Signing stellt sicher, dass ein Software-Artefakt tatsächlich von einer vertrauenswürdigen Quelle stammt und seit der Signierung nicht verändert wurde. Mit Standards wie Sigstore oder in-toto können Sie die gesamte Build-Kette kryptografisch absichern.
Das BSI empfiehlt ausdrücklich die Einführung von Artefakt-Signaturen als Teil einer modernen DevSecOps-Strategie. Auch für KMU ist dies mit modernen Open-Source-Tools ohne großen Aufwand umsetzbar.
7. Incident-Response-Plan für Supply-Chain-Vorfälle
Kein Schutz ist hundertprozentig. Deshalb gehört ein Notfallplan zur vollständigen Supply-Chain-Sicherheitsstrategie. Definieren Sie im Vorfeld:
- Wer ist bei einem Vorfall verantwortlich?
- Wie schnell können Sie eine kompromittierte Abhängigkeit aus der Produktion entfernen?
- Wie informieren Sie betroffene Kunden?
- Wie dokumentieren Sie den Vorfall für behördliche Meldepflichten (z. B. nach NIS2)?
Testen Sie diesen Plan mindestens einmal jährlich in einer simulierten Übung.
Software-Lieferkette schützen: Prioritäten für KMU
Nicht jedes KMU kann alle Maßnahmen gleichzeitig umsetzen. Eine pragmatische Priorisierung hilft, mit den verfügbaren Ressourcen den größten Sicherheitsgewinn zu erzielen.
Sofortmaßnahmen (Woche 1–2):
- Dependabot oder Snyk für bestehende Projekte aktivieren
- Alle Entwicklerzugänge auf MFA umstellen
- Secrets-Scanning in Git-Repositories einschalten (GitHub Advanced Security oder GitLeaks)
Kurzfristige Maßnahmen (Monat 1–3):
- SBOM für kritische Anwendungen erstellen
- Lock-Files in alle Repositories einpflegen und erzwingen
- Externe Entwicklerzugänge prüfen und bereinigen
Mittelfristige Maßnahmen (Quartal 2–3):
- CI/CD-Pipelines auf Least-Privilege umstellen
- Code-Signing einführen
- Vertragliche Sicherheitsanforderungen an Lieferanten definieren
Langfristige Maßnahmen (laufend):
- SBOM-Prozesse automatisieren
- Regelmäßige Third-Party-Audits durchführen
- Incident-Response-Plan für Lieferkettenvorfälle testen
Regulatorischer Rahmen: NIS2 und die Pflichten für KMU
Die NIS2-Richtlinie der EU (Network and Information Security Directive 2) ist seit Oktober 2024 in deutsches Recht umgesetzt und verpflichtet auch viele KMU zur aktiven Absicherung ihrer Lieferkette. Unternehmen in kritischen Sektoren müssen nachweisen, dass sie Risiken durch Drittanbieter systematisch managen.
Konkret bedeutet das:
- Risikoanalyse für eingesetzte Software-Komponenten durchführen
- Sicherheitsanforderungen an Lieferanten vertraglich fixieren
- Vorfälle innerhalb von 24 Stunden (bei erheblichem Einfluss) melden
Wer diese Anforderungen ignoriert, riskiert nicht nur Sicherheitsvorfälle, sondern auch empfindliche Bußgelder. Eine sorgfältige Dokumentation – etwa durch eine aktuelle SBOM – ist hier Ihr wichtigster Schutzschild.
Der Zusammenhang mit Ihrer gesamten IT-Sicherheitsstrategie
Die Software-Lieferkette zu schützen ist kein isoliertes Thema. Es fügt sich ein in eine umfassende Sicherheitsstrategie, die auch Netzwerksicherheit, Zugriffsmanagement und Datenschutz umfasst. Wer seine Entwicklungsprozesse absichert, legt damit das Fundament für ein belastbares, vertrauenswürdiges Produkt.
Erfahren Sie in unseren weiteren Beiträgen im Pilecode Blog mehr über verwandte Themen wie sichere Entwicklungspraktiken und IT-Sicherheitsstrategien für den Mittelstand.
Wenn Sie unsicher sind, wo Sie in Ihrem Unternehmen ansetzen sollen, hilft ein unabhängiger Blick von außen. Unser Team bei Pilecode unterstützt Sie bei der Analyse Ihrer aktuellen Supply-Chain-Sicherheit und der Entwicklung eines maßgeschneiderten Schutzkonzepts.
Fazit: Jetzt handeln, bevor es zu spät ist
Software-Lieferkette schützen ist keine optionale Kür – es ist 2026 eine betriebliche Notwendigkeit. Angriffe auf die Lieferkette nehmen weltweit zu, die Angreifer werden professioneller, und die regulatorischen Anforderungen steigen. Gleichzeitig stehen heute leistungsfähige, teils kostenlose Tools bereit, die auch KMU ohne riesige IT-Abteilung effektiv einsetzen können.
Die wichtigsten Erkenntnisse auf einen Blick:
- Transparenz schafft Kontrolle: Eine SBOM ist der erste Schritt
- Automatisierung ist Pflicht: Manuelles Monitoring skaliert nicht
- Externe Partner sind ein Risiko: Regeln Sie Sicherheitsanforderungen vertraglich
- Ein Plan für den Ernstfall ist genauso wichtig wie Prävention
- NIS2 macht es verbindlich: Handeln Sie jetzt, nicht nach dem ersten Vorfall
Warten Sie nicht auf den nächsten großen Supply-Chain-Angriff. Starten Sie noch heute mit den Sofortmaßnahmen aus diesem Leitfaden – und sprechen Sie mit einem Experten, wenn Sie professionelle Unterstützung benötigen.
Jetzt kostenloses Erstgespräch vereinbaren →
Haben Sie Fragen zu diesem Thema? Jetzt Kontakt aufnehmen.