Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Wichtigste Erkenntnisse
- Schwachstellen in der Lieferkette gehen auf die Pakete, Registries und Build-Systeme zurück, auf die Sie angewiesen sind.
- ChainDrop hat im August 2026 mindestens 444 npm-Pakete befallen, ohne dabei eine Schwachstelle in einem dieser Pakete auszunutzen.
- OWASP beruft sich auf eine Studie von Endor Labs, wonach etwa 95 % der Sicherheitslücken in transitiven Abhängigkeiten.
Die meisten Teams können aus dem Stegreif die Frameworks und wichtigsten Bibliotheken aufzählen, auf denen ihre Anwendungen basieren. Weitaus weniger können dies jedoch auch für die Pakete tun, die diese Bibliotheken im Hintergrund unbemerkt einbinden – und genau diese Lücke ist einer der größten blinden Flecken in der Sicherheit der Software-Lieferkette. Dieser Leitfaden erläutert, wo sich das Risiko verbirgt, welche Kosten damit verbunden sind und wie man es aufspüren kann, bevor es jemand anderes tut.
Was sind Schwachstellen in der Lieferkette?
Eine Schwachstelle in der Lieferkette ist jede Schwäche im Netzwerk aus Lieferanten, Anbietern, Software und Logistik, auf das Ihr Unternehmen angewiesen ist und die zu Störungen, Verlusten oder einer Sicherheitsverletzung führen könnte. Diese Schwachstelle kann bei einem Anbieter, bei einem Wartungsdienstleister, mit dem Sie noch nie gesprochen haben, oder auf Ihrem eigenen Build-Server liegen. So oder so sind Sie es, der mit den Folgen zu kämpfen hat.
In der Softwarebranche ist dieses Netzwerk umfangreicher, als die meisten Abhängigkeitsgraphen vermuten lassen. Es umfasst Pakete von Drittanbietern, Build-Tools, Quellcode-Repositorys, Paketregister, CI/CD-Pipelines, Signaturinfrastruktur sowie alle Personen, die diese Komponenten betreuen.
Zwei sich überschneidende Kategorien sollten getrennt betrachtet werden. Operative Schwachstellen entstehen dadurch, dass es keine Ausweichlösung gibt, wenn eine einzelne Komponente ausfällt: eine Fabrik, eine Transportroute, eine Cloud-Region – und nichts, worauf man zurückgreifen kann, wenn diese ausfällt. Sicherheitslücken sind etwas ganz anderes. Hier geht es um eine tatsächliche Schwachstelle, sei es eine Lücke in den Sicherheitsvorkehrungen eines Partners oder ein Fehler im Code, den Sie zwar nicht selbst geschrieben haben, aber dennoch ausführen.
Der Rest dieses Leitfadens befasst sich mit dieser zweiten Kategorie, insbesondere mit Open-Source-Software, bei der lange Abhängigkeitsketten, öffentliche Register und die Pflege durch Freiwillige zu einer sich schnell verändernden Risikofläche führen.
Häufige Arten von Schwachstellen in der Lieferkette
Vier wiederkehrende Muster machen einen großen Teil der Vorfälle in der Open-Source-Lieferkette aus.
1. Kompromittierte Konten von Betreuern
Mit gestohlenen Zugangsdaten oder einem gekaperten Konto lässt sich bösartiger Code in ein vertrauenswürdiges Paket einschleusen, ohne dass dabei eine Schwachstelle im ursprünglichen Code dieses Pakets ausgenutzt werden muss. Das axios-npm-Kompromittierung ist ein anschauliches Beispiel: das Konto eines legitimen Betreuers, eine normal aussehende Veröffentlichung und ein Fernzugriffstrojaner, der etwa drei Stunden lang mitlief, bevor npm die kompromittierten Versionen entfernte.
2. Typosquatting und Namensraum-Ähnlichkeiten
Bei der Überprüfung von Paketen liegt der Fokus meist eher auf dem Code innerhalb eines Pakets als auf den Koordinaten und dem Herausgeber auf dem Etikett, weshalb ein Name, der sich nur um ein Zeichen vom Original unterscheidet, weiterhin funktioniert. Die gefälschte Jackson-Bibliothek auf Maven Central wurde unter „org.fasterxml.jackson.core“ statt unter dem legitimen „com.fasterxml.jackson.core“ bereitgestellt – ein einfacher Austausch des Präfixes, der auf den ersten Blick authentisch wirkt. Unsere Analyse von „Typosquatting“ bei „npm install“ zeigt, wie weit sich ein überzeugendes Doppelgänger-Paket verbreiten kann, bevor es jemand bemerkt.
3. Ausführung während der Kompilierung und der Installation
Ein Paket muss Ihren Anwendungscode nicht einmal berühren, um einen Build zu kompromittieren. Beide werden vor dem Start Ihrer Anwendung ausgeführt: eine bösartige Python-.pth-Datei beim Start des Interpreters und ein Rust-Skript „build.rs“ während des Cargo-Build-Prozesses. Die Hades-Kampagne nutzte einen Start-Hook aus. Im Arrayref-Kompromittierung im August 2026hatte das Crate eine durch Typosquatting manipulierte Abhängigkeit namens „proc-macro1“ übernommen, deren Build-Skript während des „cargo build“-Vorgangs eine Payload abrief und ausführte.
4. Vertriebskanäle, die von Haus aus Vertrauen genießen
Registrierungsstellen tauschen ein gewisses Maß an Verifizierung gegen Geschwindigkeit ein, und Angreifer haben genau herausgefunden, wo diese Kompromisse liegen. Das Go-Modul-Proxy speichert eine zwischengespeicherte Kopie einer Version, sobald diese aufgelöst wurde. Aus diesem Grund blieb das mit einer Hintertür versehene Modul „github.com/boltdb-go/bolt“ noch mehr als drei Jahre lang reproduzierbar verfügbar, nachdem das Upstream-Repository bereinigt worden war. Packagist ließ in der Vergangenheit zu, dass eine stabile Version einem verschobenen Git-Tag folgte – genau das ermöglichte es den Angreifer von Laravel-Lang mehr als 700 historische Versionen , ohne dass jemals eine neue Versionsnummer erschien. Packagist hat seitdem die Verknüpfung zwischen Version und Commit für veröffentlichte stabile Versionen unveränderlich gemacht, sodass ein erneutes Taggen nicht mehr unbemerkt ändern kann, worauf eine Version verweist.
Nicht jede Schwachstelle in der Lieferkette erfordert überhaupt einen Angreifer. Log4Shell war eine Schwachstelle in einer Bibliothek, die in vielen Abhängigkeitsbäumen mehrere Ebenen tief verborgen war, und genau diese Tiefe war der Grund, warum so viele Teams tagelang damit beschäftigt waren, herauszufinden, ob sie überhaupt betroffen waren.
Wusstest du schon: Der npm-Wurm namens ChainDrop, ein Stamm der Shai-Hulud-Familie, benötigte ebenfalls keine Software-Sicherheitslücke. Am 4. August 2026 verschaffte sich ein Angreifer Zugriff auf das GitHub-Konto eines Betreuers und übertrug bösartige Commits in die Repositorys „keyv“ und „cacheable“. Die projektinternen Release-Workflows erstellten und veröffentlichten die manipulierten Versionen, sodass die erste Welle mit echten Herkunftsnachweisen bei npm eintraf. Von dort aus verbreitete sich der Wurm mithilfe gestohlener Veröffentlichungstoken und erreichte 444 Paketnamen mit insgesamt 2 Milliarden Downloads pro Monat. Eine Kontrolle, die lediglich die Identität des Herausgebers, die Signatur und die Versionsnummer überprüft, hat nichts daran auszusetzen.
Wie sich Schwachstellen in der Lieferkette auf Unternehmen auswirken
Die Kosten einer Schwachstelle in der Lieferkette beschränken sich selten nur auf den Vorfall selbst. Hinzu kommen die wochenlangen Untersuchungen, die während des Ausfalls entgangenen Einnahmen und die Prüfungsergebnisse, die erst Monate später ans Licht kommen. Durch die Erfassung von Abhängigkeiten und einen einstudierten Reaktionsplan lässt sich die Zeit verkürzen, die benötigt wird, um Risiken zu identifizieren und einzudämmen – und genau hier summieren sich still und leise die meisten Kosten.
1. Unmittelbarer finanzieller Verlust
Zu den offensichtlichen Kostenposten zählen Einnahmeausfälle während Ausfallzeiten, Pauschalhonorare für die Reaktion auf Vorfälle, Notfallmaßnahmen für alle betroffenen Builds sowie Bußgelder aufgrund behördlicher Auflagen. Um einen groben Überblick zu geben: Der Verizon DBIR 2026 bezifferte die die mittlere Lösegeldzahlung auf 139.875 US-Dollar, wobei es sich hierbei jedoch um eine Ransomware-Zahl aus dem Datensatz von Verizon handelt und nicht um einen Maßstab für die Kosten eines Vorfalls in der Lieferkette. Ihre eigenen Zahlen hängen davon ab, wie lange Sie gefährdet waren, wie viele Artefakte neu erstellt werden müssen und ob Daten das Unternehmen verlassen haben.
2. Betriebsausfälle
Wenn eine kompromittierte Abhängigkeit in die Produktionsumgebung gelangt, ist das Einfügen einer sauberen Version meist nur der erste Schritt. Jedes Artefakt, in dem das betroffene Paket enthalten ist, muss noch identifiziert, neu erstellt und erneut bereitgestellt werden – und diese Liste ist selten so kurz, wie das Team erwartet.
3. Datenschutzverletzungen und rechtliche Risiken
Bei einem von der Community gepflegten Paket gibt es oft keinen Anbietervertrag, der die Verantwortung zuweist, wenn etwas schiefgeht. Viele weit verbreitete Open-Source-Lizenzen schließen Gewährleistungen aus und beschränken die Haftung, was zu weniger Rechtsbehelfen führen kann als bei einer ausgehandelten kommerziellen Supportvereinbarung. Ihre regulatorischen Verpflichtungen verschwinden nicht einfach deshalb, weil der anfällige Code ursprünglich nicht von Ihnen stammte.
4. Rufschädigung
Kunden und Journalisten interessiert es in der Regel weniger, wessen Code das Problem verursacht hat, als vielmehr die Tatsache, dass Ihre Systeme angegriffen wurden. Die Auswirkungen auf den Ruf können die technische Behebung des Problems bei weitem überdauern, insbesondere wenn es in der Berichterstattung eher um Ihre Sicherheitsmaßnahmen als um Ihr Glück geht.
5. Verstöße gegen Vorschriften und Mängel bei der Prüfung
Je nach Framework und Umfang des Audits können nicht gepatchte Komponenten und nicht geprüfte Abhängigkeiten zu Beanstandungen führen, selbst wenn keine Sicherheitslücken ausgenutzt wurden. Veraltete kryptografische Bibliotheken sind ein häufig auftretendes Beispiel, und jede Beanstandung verursacht Zeitaufwand für die Behebung sowie eine eingehende Prüfung aller damit verbundenen Komponenten durch den Auditor. Lesen Sie dazu unseren Leitfaden zu OpenSSL-Sicherheit.
Realitätscheck: Die Aufnahme von SOC 2 in einen Lieferantenvertrag allein sagt noch nicht viel aus. Ein SOC-2-Bericht bezieht sich bei Typ I auf die Konzeption der Kontrollmaßnahmen zu einem bestimmten Zeitpunkt oder bei Typ II auf die operative Wirksamkeit über einen festgelegten Zeitraum; daher müssen Sie den eigentlichen Bericht, seinen Umfang, seinen Zeitraum und seine Ausnahmen lesen. Selbst diese Überprüfung gibt Ihnen jedoch noch keinen Aufschluss darüber, ob der kritische CVE der letzten Woche behoben wurde.
So erkennen Sie Schwachstellen in der Lieferkette
Das Aufspüren von Schwachstellen in der Lieferkette ist keine glamouröse Aufgabe, aber genau darin liegt der Nutzen. Log4Shell hat dies deutlich gemacht: Teams, die über ein aktuelles Abhängigkeitsverzeichnis verfügten, konnten ihre Anfälligkeit ermitteln, während alle anderen mitten im Vorfall noch damit beschäftigt waren, ein solches Verzeichnis neu zu erstellen. Erledigen Sie diese Arbeit an einem ganz normalen Dienstag und nicht erst während eines Vorfalls.
1. Erstellen und klassifizieren Sie Ihr Abhängigkeitsverzeichnis
Listen Sie alle Open-Source-Pakete auf, die Ihre Anwendungen einbinden – sowohl direkt als auch transitiv –, und nicht nur diejenigen, die bewusst hinzugefügt wurden. Ordnen Sie diese dann danach, was passieren würde, wenn eines davon morgen bösartig würde. Eine Bestandsaufnahme, die sich auf die Angaben in „package.json“ oder „requirements.txt“ beschränkt, lässt alles außer Acht, was unterhalb dieser Dateien eingebunden wird – und genau das sind die Pakete, die Sie auf keinen Fall übersehen dürfen.
2. Eine Software-Stückliste erstellen
Erstellen Sie für jede Anwendung, die Sie entwickeln, eine SBOM in der Build-Pipeline und speichern Sie diese zusammen mit dem Artefakt. Für Software von Drittanbietern, die Sie lediglich ausführen, sollten Sie sich vom Anbieter ein entsprechendes Komponentenverzeichnis beschaffen. Im Hinblick auf die Transparenz der Abhängigkeiten ist dies eine der wertvollsten Kontrollmaßnahmen auf dieser Liste. Eine aktuelle, genaue SBOM verwandelt die Frage „Wo wird diese Komponente ausgeführt?“ von einer manuellen Suche in eine durchsuchbare Abfrage, auch wenn Sie weiterhin Bereitstellungsdaten und Informationen zu Sicherheitslücken benötigen, um die Antwort vollständig zu erhalten. Ohne eine solche SBOM müssen Teams unter Zeitdruck Lockfiles, Build-Protokolle und Live-Systeme miteinander abgleichen.
3. Einzelne Ausfallstellen erfassen
Stellen Sie für jede kritische Abhängigkeit eine direkte Frage: Wenn dieses Paket heute verschwinden oder schädlich werden würde – welche Alternative gäbe es, und wie lange würde die Umstellung dauern? Alles, worauf es keine Antwort gibt, ist ein Single Point of Failure, unabhängig davon, ob es als solcher gekennzeichnet ist oder nicht. Wenden Sie dies auf die Bibliotheken selbst, die dahinter stehenden Betreiberkonten und die Registries an, aus denen Sie beziehen.
4. Zustand von Paketen und Betreuern bewerten
Für die meisten Open-Source-Abhängigkeiten gibt es keinen Anbieter, an den man einen Fragebogen senden könnte; daher müssen die Informationen aus dem Paket und dem dazugehörigen Projekt stammen: Veröffentlichungshistorie, Anzahl der Betreuer, wie schnell frühere CVEs behoben wurden und ob die Releases eine Herkunftsangabe enthalten. Ein kritisches Paket, das von einem einzigen Betreuer betreut wird, der keine sichtbaren Aktivitäten zeigt, verdient eine genauere Prüfung – wobei zu bedenken ist, dass Stille auch einfach bedeuten kann, dass der Code fertiggestellt ist.
5. Das Scheitern proben
Führen Sie eine Tabletop-Übung zu zwei gängigen Szenarien durch: Ein Konto eines Systemadministrators wird kompromittiert, und eine weit verbreitete Bibliothek gibt eine aktiv ausgenutzte CVE bekannt. Messen Sie, wie lange es dauert, grundlegende Fragen zu beantworten. Dabei treten in der Regel Lücken in den Bereichen Bestandsaufnahme, Zuständigkeiten und Entscheidungsbefugnisse zutage – und keine noch so vielen neuen Tools können diese Probleme allein beheben.
Profi-Tipp: Wenn Sie für kommerziellen Support für eine Open-Source-Komponente bezahlen, sollten Sie in diesem Vertrag ausdrücklich ein Patch-SLA und eine Frist für die Benachrichtigung bei Sicherheitsverletzungen festlegen. „Best effort“ ist keine konkrete Zahl, und bei einem unbezahlten Betreuer haben Sie überhaupt kein vertragliches Patch-SLA.
Strategien zur Minderung von Schwachstellen in der Lieferkette
Da sich bereits bestehende Risiken nicht beseitigen lassen, sollten Sie sich auf das konzentrieren, was Sie tatsächlich beeinflussen können: Wie wahrscheinlich ist ein Sicherheitsvorfall, wie groß ist der mögliche Schaden und wie schnell können Sie reagieren? Die folgenden fünf Punkte sind ein guter Ausgangspunkt.
1. Verkürzen Sie die Zeit bis zur Fehlerbehebung
Bei bekannt gewordenen Sicherheitslücken in Abhängigkeiten steigt das Risiko umso mehr, je länger die Behebung auf sich warten lässt. Automatisieren Sie daher die Installation von Patches, wo immer dies möglich ist. Böswillige Veröffentlichungen und Kontoübernahmen stellen eine andere Art von Problem dar, da es keine Bekanntgabe gibt, auf die man reagieren könnte. Dennoch ist Schnelligkeit wichtig, da jede weitere Installation den Schadensumfang vergrößert. Wo Sie nicht sofort Patches installieren können – sei es aufgrund von Komponenten am Ende ihres Lebenszyklus (EOL), festgelegten Versionen von Abhängigkeiten oder Systemen mit Änderungskontrolle – verschafft virtuelles Patchen Zeit, wenn es einen Exploit-Pfad gibt, den die Kontrolle tatsächlich abfangen kann. Bei nicht mehr gepflegten Paketen bieten herstellerunterstützte Patches einen dauerhaften Behebungsweg, vorausgesetzt, Sie validieren die Patches in Ihrer eigenen Umgebung.
2. Ersatzbibliotheken im Voraus auswählen
Eine Ersatzabhängigkeit, die Sie noch nie tatsächlich in einem Build ausgeführt haben, ist kein echter Fallback. Machen Sie sich klar, für welche Ihrer kritischen Bibliotheken es eine brauchbare, produktionsreife Alternative gibt und für welche nicht, bevor Sie unter Druck dazu gezwungen sind, dies herauszufinden.
3. Den Zugriffsbereich eines kompromittierten Pakets einschränken
Entwerfen Sie so, als ob jede Abhängigkeit irgendwann kompromittiert werden könnte. Das bedeutet: „Least Privilege“ in der CI, Sandbox-Umgebungen für den Build, standardmäßig eingeschränkte Installationsskripte und keine langfristig gültigen Veröffentlichungstoken in einer Pipeline, die diese nicht benötigt – insbesondere der letzte Punkt.
Durch Segmentierung und kurzlebige Anmeldedaten wird die Reichweite eines kompromittierten Pakets begrenzt und das Risiko verringert, dass Anmeldedaten in Ihrer gesamten Build-Infrastruktur verloren gehen.
4. Überprüfen Sie, was in Ihren Build gelangt
Verwenden Sie Lockfiles, legen Sie die relevanten Versionen der Abhängigkeiten fest und überprüfen Sie die Hash-Werte der Artefakte, sofern Ihr Ökosystem dies unterstützt. Richten Sie einen Prozess ein, um diese Festlegungen schnell zu aktualisieren, sobald ein Sicherheitsupdate veröffentlicht wird, da eine veraltete Festlegung selbst zu einem Problem wird. Behandeln Sie die Konfiguration für CI und Repository-Automatisierung wie ausführbaren Code, denn genau so verhält sie sich.
Man sollte sich jedoch der Grenzen bewusst sein. Der TanStack-npm-Kompromittierung im Mai 2026 führte zu dem, was Forscher als die ersten dokumentierten bösartigen npm-Pakete bezeichneten, die kryptografisch gültige Herkunftsbescheinigungen enthielten und direkt über den projektinternen Release-Workflow veröffentlicht wurden. Die erste Welle von ChainDrop tat im August dasselbe. Die Herkunftsbescheinigung belegt, wo und wie ein Artefakt erstellt wurde. Sie gibt jedoch keinen Aufschluss darüber, ob dieses Artefakt harmlos ist. Kombinieren Sie dies mit der Überwachung der Build-Pipeline und Ihren übrigen Praktiken zur sicheren Entwicklung.
5. Planung von Ausbesserungsarbeiten nach dem Stillstand der vorgelagerten Anlagen
Ein vernachlässigtes Paket wird nicht einfach deshalb nicht mehr in Ihre Builds aufgenommen, nur weil sich sein Betreuer zurückgezogen hat. Machen Sie sich klar, welche Abhängigkeiten bereits nicht mehr gepflegt werden, und legen Sie einen Plan fest – sei es ein Fork, ein Ersatz oder eine gepatchte Quelle –, bevor eine ungepatchte CVE in einer dieser Abhängigkeiten die Entscheidung für Sie trifft.
Beheben Sie Schwachstellen in der Lieferkette mit TuxCare
Open-Source-Risiken decken ein breites Spektrum ab: anfälliger Code, kompromittierte Herausgeber, Integrität der Builds, transitive Abhängigkeiten und die Geschwindigkeit, mit der Sie diese Probleme beheben können. Die Überprüfung der Herkunft und Integrität ist eine von mehreren Kontrollmaßnahmen und funktioniert am besten in Verbindung mit Patch-Management, Build-Sicherheit, dem Prinzip der geringsten Berechtigungen und einem Reaktionsplan, den Sie tatsächlich einstudiert haben. Wenn Ihr Team Abhängigkeiten nutzt, für die es keine zeitnahen Upstream-Korrekturen mehr gibt, oder keine Möglichkeit hat, zu überprüfen, ob ein Paket aus einer verifizierten Quelle neu kompiliert wurde, überprüft „SecureChain for Open Source Software“ überprüft Pakete bei der Installation, erstellt sie neu aus dem Quellcode und patcht sie auch dann weiter, wenn der Upstream-Support eingestellt wurde – und zwar für JavaScript, Python, Java, Go, Rust und PHP. Die Einführung erfolgt Ökosystem für Ökosystem. Wenn Sie also genau wissen möchten, wie der aktuelle Stand bei einem bestimmten Ökosystem ist, senden Sie bitte eine E-Mail an [email protected].
Ein Großteil dieses Risikos liegt jenseits dessen, was ein Team bewusst installiert. Um genauer zu verstehen, wie eine in einer transitiven Abhängigkeit verborgene CVE in die Produktion gelangt, sehen Sie sich „So vermeiden Sie den Abhängigkeits-Eisberg, der Ihre Produktionsumgebung zum Erliegen bringen könnte.“
