60 Milliarden Dollar. So hoch schätzen die Analysten die globalen Schäden durch Angriffe auf die Software-Lieferketten allein für das Jahr 2025. Software-Lieferketten-Angriffe haben sich 2025 weltweit mehr als verdoppelt. Über 70 Prozent der Organisationen berichten, mindestens einen lieferkettenbezogenen Sicherheitsvorfall erlebt zu haben.
Was diese Zahl so alarmierend macht: Die Angriffe treffen nicht mehr die Organisation direkt — sie treffen die Software, auf die sie vertrauen.
Warum Lieferketten das neue Primärziel sind
Klassische Angriffe scheitern an gut konfigurierten Perimetern. Die Lieferkettenangriffe umgehen diese Perimeter, indem sie sich an einem Ort einnisten, dem per Definition vertraut wird: in der Entwicklungsinfrastruktur, in Open-Source-Paketen, in CI/CD-Pipelines.
Die Angreifer benötigen keine neuartigen Schwachstellen mehr und keinen Zugang zum Perimeter. Stattdessen kompromittieren sie Software an der Quelle — durch implizites Vertrauen in Entwickler-Tooling, Identitäten und Software-Distribution — und erhalten so stillen, hochgradig wirksamen Zugang downstream, der oft mehrere Abwehrmechanismen gleichzeitig umgeht.
35 Prozent der Angriffe erfolgten 2025 über kompromittierte Software-Abhängigkeiten, 22 Prozent zielten auf CI/CD-Pipelines und Build-Umgebungen, 20 Prozent nutzten vergiftete oder unverifizierte Container-Images. Abhängigkeiten, Build-Pipelines und Container-Images stellen damit 75 Prozent aller Angriffseinstiegspunkte dar.
Angriffsmethoden im Überblick
Die Methoden, die Angreifer 2026 einsetzen, haben sich stark professionalisiert:
| Angriffsmethode | Veränderung 2025/2026 | Primäres Ziel |
| Typosquatting | +104,3 % | Entwickler bei Paketinstallation |
| Malicious URLs in Paketen | +179,2 % | Automatisierte Build-Prozesse |
| Dependency Confusion | −77,1 % | Rückläufig durch bessere Registry-Kontrollen |
| Self-replicating npm-Malware | Neu (Shai-Hulud) | Developer-Umgebungen, CI/CD |
| KI-Tool-Poisoning | Stark steigend | KI-gestützte Entwicklungsworkflows |
Die Angreifer verlassen ältere, leicht erkennbare Methoden zugunsten hochgradig täuschender Direktkompromittierungs-Taktiken. Der NPM-Ökosystem bleibt mit 65,9 Prozent aller beobachteten schädlichen Pakete der aktivste Angriffsvektor.
Der Shai-Hulud-Moment — ein Wendepunkt
Der Shai-Hulud-Angriff im September 2025 markierte einen Wendepunkt: die erste bekannte selbstreplizierende npm-Malware, die sich autonom über Entwicklerumgebungen und Pakete verbreitete — eher wie ein traditioneller Netzwerkwurm als eine passive Bibliothek.
Das verändert die Bedrohungslogik grundlegend. Bisherige Lieferkettenangriffe waren passiv: Ein vergiftetes Paket wartete darauf, installiert zu werden. Shai-Hulud agiert aktiv — es sucht, verbreitet sich, reproduziert sich. Seit April 2025 verharren Lieferkettenangriffe auf erhöhtem Niveau mit durchschnittlich mehr als 28 Vorfällen pro Monat — mehr als doppelt so viel wie die 13 monatlichen Angriffe zwischen Anfang 2024 und März 2025.
KI als neues Einfallstor
Ein oft übersehenes Risiko liegt in der rasanten Verbreitung KI-gestützter Entwicklungstools. KI-Code-Assistenten können schädlichen Code automatisch abrufen und installieren, wenn sie aufgefordert werden, Abhängigkeitsfehler zu beheben oder fehlende Bibliotheken zu installieren. Die Absicht des Entwicklers mag harmlos sein — das Ergebnis kann katastrophal sein. Die Angreifer nutzen dies zunehmend aus.
Die wachsende Abhängigkeit der Softwareindustrie von KI zur schnelleren Codegenerierung, kombiniert mit weitverbreiteten Open-Source-Risiken und mangelnder Sichtbarkeit in kommerzieller Software, setzt die Endnutzerorganisationen schädlichen Angriffen aus.
Digitale Unterhaltungsplattformen sind dabei keine Ausnahme. Wer online spielt — etwa beim Mr Bet Casino Login — verlässt sich auf die Sicherheit der dahinterliegenden Infrastruktur, ohne diese direkt prüfen zu können. Das macht Softwareintegrität auf Anbieterseite zur Nutzerfrage, nicht nur zur IT-Frage.
Wo die größten blinden Flecken liegen
Weniger als 50 Prozent der Unternehmen überwachen aktuell mehr als 50 Prozent ihrer erweiterten Software-Lieferkette — ein kritisches Sichtbarkeitsproblem, das Organisationen gegenüber Upstream-Kompromittierungen exponiert. Laufzeit-Sicherheitskontrollen erkennen Bedrohungen konsistent zu spät; was dringend benötigt wird, ist Build-Time-Validierung statt Post-Deployment-Fixes.
Das strukturelle Problem dahinter: Ein CISO muss eine schwierige Wahrheit akzeptieren — die Sicherheit der Organisation ist nur so stark wie die des am schwächsten gesicherten Partners. Die Angreifer wissen, dass es weitaus effektiver ist, einen kleinen Lieferanten mit schwacher Sicherheit zu kompromittieren, als eine direkte Attacke gegen ein großes Unternehmen zu führen.
Was Unternehmen konkret tun sollten
Die Antwort auf Lieferkettenangriffe liegt nicht in mehr Perimeter-Sicherheit, sondern in Verifikation auf jeder Ebene des Entwicklungsprozesses:
- SBOM einführen: Software Bill of Materials als Standard — vollständige Inventarisierung aller Komponenten und Abhängigkeiten, die in jeder Software stecken
- Build-Time-Validierung: Sicherheitskontrollen müssen vor der Ausführung greifen, nicht danach — jede Komponente wird vor der Installation kryptografisch verifiziert
- Kontinuierliche Registry-Überwachung: Automatisierte Prüfung aller verwendeten Open-Source-Pakete auf bekannte Schadmuster, Typosquatting-Risiken und unerwartete Versionsänderungen
- Zero-Trust für Entwicklertools: Auch intern verwendete Tools — IDEs, Plugins, CI/CD-Systeme — werden wie externe Drittanbieter behandelt und regelmäßig geprüft
- KI-Tool-Governance: Klare Richtlinien, welche KI-Assistenten in welchem Kontext Pakete installieren dürfen — automatisierte Dependency-Resolution nur mit expliziter Freigabeliste
Vertrauen ist keine Sicherheitsstrategie
Die strukturellen Versagensmuster, die sich 2025 immer wieder wiederholten: Code wurde automatisch ausgeführt, bevor Sicherheitskontrollen eingriffen. Rollen und Veröffentlichungsrechte wurden als dauerhafte Vertrauensanker behandelt, ohne unabhängige Validierung. Die Automatisierung war auf Geschwindigkeit optimiert — ohne Gating, gestufte Rollouts oder Rollback-Kontrollen.
2026 verlangt von Unternehmen einen Paradigmenwechsel: vom impliziten Vertrauen in Software-Komponenten zur kontinuierlichen Validierung auf jeder Ebene. Wer das nicht als strategische Priorität behandelt, läuft Gefahr, Teil einer Kette zu werden, die jemand anderes kompromittiert hat — ohne es zu wissen.
