Software-Lieferkette absichern: Wie KMU sich vor kompromittierten Open-Source-Paketen schützen

Anfang August 2026 sorgte der Schadcode-Wurm “Shai-Hulud” für Aufsehen: Er kompromittierte mehr als 440 Pakete im npm-Ökosystem, darunter das weitverbreitete Paket keyv. Betroffen waren nicht nur Softwarefirmen, sondern jedes Unternehmen, dessen Website, interne Tools oder Kundenportale auf solchen Bibliotheken aufbauen. Für die Software-Lieferkette vieler KMU ist das ein Weckruf – denn kaum ein Unternehmen weiß genau, welche Open-Source-Komponenten in der eigenen Software stecken.

Was ist die Software-Lieferkette – und warum betrifft sie auch KMU ohne eigene Entwicklung?

Jede moderne Anwendung – ob eine selbst entwickelte Firmenwebsite, ein Nextcloud-Plugin oder eine von einem Dienstleister gebaute Kundenplattform – besteht zu einem Großteil aus fremdem Code. Entwickler binden Bibliotheken über Paketmanager wie npm (JavaScript), pip (Python) oder Composer (PHP) ein, statt jede Funktion selbst zu programmieren. Eine typische Webanwendung bringt so schnell mehrere hundert bis tausend indirekte Abhängigkeiten mit.

Die Software-Lieferkette umfasst all diese Komponenten – inklusive der Abhängigkeiten von Abhängigkeiten. Wird eine einzige davon kompromittiert, wie beim Shai-Hulud-Wurm geschehen, kann Schadcode automatisch in tausende Projekte gelangen, ohne dass die betroffenen Unternehmen aktiv etwas falsch gemacht haben. Auch KMU ohne eigenes Entwicklerteam sind betroffen, sobald sie Software von externen Dienstleistern beziehen oder Open-Source-Anwendungen im eigenen Betrieb einsetzen.

Wie laufen solche Angriffe konkret ab?

Bei npm-Supply-Chain-Angriffen übernehmen Angreifer typischerweise die Zugangsdaten eines Paket-Maintainers – oft über Phishing – und veröffentlichen dann eine manipulierte Version eines beliebten Pakets. Entwickler, die per npm install oder automatisiertem Build die neueste Version ziehen, holen sich den Schadcode ungeprüft ins Projekt. Der Shai-Hulud-Wurm ging noch weiter: Er suchte in kompromittierten Systemen nach weiteren npm-Zugangsdaten und verbreitete sich selbstständig in andere Pakete – ein sich selbst fortpflanzender Angriff auf die gesamte Lieferkette.

Warum ist das Risiko für KMU besonders hoch?

Größere Softwarehäuser betreiben oft dedizierte Security-Teams, die Abhängigkeiten kontinuierlich scannen. KMU und mittelständische Betriebe in Sachsen und Ostdeutschland haben dafür in der Regel weder Personal noch Prozesse. Häufig gilt: Eine Website wurde vor Jahren von einer Agentur gebaut, läuft seitdem unverändert und wird nie wieder auf veraltete oder kompromittierte Abhängigkeiten geprüft. Genau das macht die Software-Lieferkette zu einem blinden Fleck in vielen IT-Sicherheitskonzepten.

Praxisteil: Software-Lieferkette in 6 Schritten absichern

1. Software-Inventar erstellen (SBOM)

Der erste Schritt ist Transparenz: Welche Software läuft im Unternehmen, und welche Komponenten stecken darin? Eine Software Bill of Materials (SBOM) listet alle Abhängigkeiten einer Anwendung auf. Tools wie npm audit, pip-audit oder syft generieren solche Listen automatisiert – auch nachträglich für bestehende Projekte.

2. Abhängigkeiten regelmäßig auf bekannte Schwachstellen prüfen

Dienste wie GitHub Dependabot, Snyk oder OSV-Scanner gleichen die eingesetzten Paketversionen automatisch mit Schwachstellendatenbanken ab und melden, wenn eine Komponente betroffen ist. Für Unternehmen mit externen Dienstleistern gilt: Fragen Sie aktiv nach, ob und wie regelmäßig deren Software auf verwundbare Abhängigkeiten geprüft wird.

3. Versionen fixieren statt automatisch aktualisieren

Ein Grund, warum sich Angriffe wie Shai-Hulud so schnell verbreiten: Viele Build-Prozesse ziehen automatisch die jeweils neueste Paketversion. Lockfiles (package-lock.json, poetry.lock) fixieren stattdessen geprüfte Versionsstände. Updates sollten bewusst und geprüft eingespielt werden, nicht automatisch bei jedem Build.

4. Paketquellen und Signaturen verifizieren

Wo möglich, sollten nur Pakete aus vertrauenswürdigen, offiziellen Registries bezogen werden. Paketmanager mit Signaturprüfung oder Provenienznachweisen (z. B. npm Provenance) erschweren es Angreifern, unbemerkt manipulierte Versionen unterzubringen.

5. Least Privilege für Build- und CI/CD-Systeme

Build-Server und CI/CD-Pipelines sollten nur die Zugriffsrechte besitzen, die sie tatsächlich benötigen. Gestohlene Zugangsdaten aus einer kompromittierten Pipeline sind ein häufiger Ausgangspunkt für Lieferketten-Angriffe – Netzwerksegmentierung und getrennte Zugänge begrenzen den Schaden.

6. Notfallplan für kompromittierte Abhängigkeiten

Wenn eine im Unternehmen genutzte Bibliothek als kompromittiert gemeldet wird: Wer prüft, ob und wo sie eingesetzt wird? Wer informiert betroffene Kunden, falls eigene Software ausgeliefert wird? Ein kurzer, dokumentierter Ablauf spart im Ernstfall wertvolle Stunden.

Was tun, wenn ein Dienstleister betroffene Software einsetzt?

Nicht jedes KMU entwickelt selbst – viele beziehen Webseiten, Portale oder interne Tools von externen Agenturen und Dienstleistern. Auch dann bleibt die Verantwortung nicht komplett extern: Fragen Sie Ihre Dienstleister aktiv, ob sie von aktuellen Vorfällen wie Shai-Hulud betroffen sind, wie sie Abhängigkeiten pflegen und ob es einen Prozess für Sicherheitsupdates gibt. Diese Fragen gehören in jeden Wartungsvertrag.

Rexoma unterstützt Unternehmen in Dresden bei der Software-Lieferkette

Sie wissen nicht, welche Open-Source-Komponenten in Ihrer Unternehmenssoftware stecken oder ob Ihre Website von aktuellen Supply-Chain-Vorfällen betroffen ist? Rexoma unterstützt KMU in Dresden, Sachsen und Ostdeutschland dabei, die eigene Software-Lieferkette transparent zu machen, Abhängigkeiten zu prüfen und Prozesse für kontinuierliche Sicherheitsupdates aufzubauen – von der ersten Bestandsaufnahme bis zur laufenden Überwachung.

FAQ

Was unterscheidet Software-Lieferketten-Sicherheit von klassischer Lieferanten-Sicherheit?

Klassische Lieferanten-Sicherheit betrifft Geschäftspartner und Dienstleister als Organisationen. Software-Lieferketten-Sicherheit betrifft die technischen Bausteine selbst – also Programmcode und Bibliotheken, die in eigener oder fremder Software verbaut sind, unabhängig davon, wer sie liefert.

Betrifft das Thema auch Unternehmen ohne eigene Softwareentwicklung?

Ja. Sobald eine Firma eine Website, ein Kundenportal oder Software von einem Dienstleister nutzt, ist sie Teil von dessen Software-Lieferkette und indirekt von deren Abhängigkeiten betroffen.

Wie erkenne ich, ob meine Software von einem konkreten Vorfall wie Shai-Hulud betroffen ist?

Eine aktuelle SBOM zeigt, welche Pakete in welcher Version im Einsatz sind. Diese lässt sich mit veröffentlichten Listen kompromittierter Paketversionen abgleichen. Ohne SBOM ist meist eine gezielte Prüfung durch den Entwickler oder Dienstleister nötig.

Reicht ein einmaliger Check der Abhängigkeiten aus?

Nein. Neue Schwachstellen und kompromittierte Pakete werden laufend entdeckt. Kontinuierliches, automatisiertes Scannen ist notwendig, um zeitnah auf neue Vorfälle reagieren zu können.

Wie oft sollten Software-Abhängigkeiten aktualisiert werden?

Sicherheitsrelevante Updates sollten zeitnah nach Prüfung eingespielt werden. Reine Versions-Updates ohne Sicherheitsbezug können gebündelt und in regelmäßigen, geplanten Zyklen getestet werden, um Stabilität und Sicherheit auszubalancieren.