Die Software-Lieferkette ist 2026 zusammengebrochen – und die Zahlen belegen es

Wichtigste Erkenntnisse

• Zwischen März und Juli 2026 gab es sechs bestätigte Angriffe auf die Lieferkette, die npm, PyPI, Go-Module und Packagist betrafen.
• Keiner von ihnen benötigte einen Fehler im Anwendungscode eines anderen, sondern lediglich einen vertrauenswürdigen Schritt in der Vertriebskette.
• Drei der sechs kamen und gingen innerhalb weniger Stunden, was schneller ist, als die meisten Scan-Pläne ablaufen.
• Die Erkennung nach der Installation wurde für einen langsameren Angriff entwickelt als den, mit dem die Teams derzeit konfrontiert sind.

Zwei der schnellsten Kampagnen dieses Jahres zeigen, wie wenig Zeit ein Angreifer benötigt. Zwei manipulierte Axios-Versionen waren am 31. März etwa drei Stunden lang auf npm verfügbar, bevor sie entfernt wurden. Die Übernahme von Mastra verlief sogar noch schneller: wobei in etwa 88 Minuten mehr als 140 Pakete neu veröffentlicht wurden . Microsoft führt beide Angriffe auf „Sapphire Sleet“ zurück, während Google den Axios-Angriff mit dem nordkoreanischen Cluster in Verbindung bringt, den es nun „Midnight Neptune“ nennt, ehemals UNC1069. Keiner der beiden Angriffe konnte gestoppt werden, bevor die schädlichen Versionen die Nutzer erreichten, und in keinem der Fälle hat jemand den Quellcode des Pakets verändert. Der Angreifer fügte lediglich eine einzige Abhängigkeit zu „package.json“ hinzu und überließ den Rest dem Befehl „npm install“.

Herkömmliche, auf CVE ausgerichtete SCA- und SBOM-Workflows wurden nie dafür konzipiert, eines von beiden zu verhindern, da es in dem entscheidenden Moment nichts gab, womit ein Abgleich hätte erfolgen können. Beide Fenster öffneten und schlossen sich in kürzerer Zeit, als viele nächtliche Builds benötigen, um abgeschlossen zu werden.

So sieht das Jahr 2026 bislang aus. Kein einziger riesiger Sicherheitsvorfall, über den noch Monate später gestritten wird, sondern eine stetige Abfolge kurzer, schneller und professionell durchgeführter Angriffe, die nacheinander öffentliche Register treffen, während die meisten Abwehrmaßnahmen noch am anderen Ende der Pipeline stehen und darauf warten, bereits abgeschlossene Vorfälle zu melden.

Was sich zwischen 2025 und 2026 geändert hat

Reiht man die Daten aneinander, wird das Muster deutlich. Sechs bestätigte Kampagnen fanden innerhalb eines Zeitraums von fünf Monaten – von März bis Juli 2026 – in vier Ökosystemen statt. Das entspricht etwa einer großen, unabhängig bestätigten Kampagne pro Monat, von denen mehrere mit namentlich bekannten Angreifern in Verbindung stehen.

Und die umfassenderen Bedrohungsdaten deuten darauf hin, dass es sich hierbei um mehr als nur eine ungewöhnlich schlechte Phase handelte. Der Cloud-Bedrohungsbericht von Wiz für das erste Halbjahr 2026 ergab, dass die Anzahl der schwerwiegenden Vorfälle, auf die das Unternehmen seine Kunden hingewiesen hat, im Vergleich zum zweiten Halbjahr 2025 um 60 % gestiegen ist – der höchste Wert aller bisher erfassten Zeiträume –, wobei der Anteil der Angriffe auf die Lieferkette von etwa 10 % auf 25 % dieser Vorfälle angestiegen ist. Da Wiz Cloud-Vorfälle erfasst und nicht die Registry-Hygiene, lässt sich dies als unabhängige Bestätigung des Trends werten und nicht als Bestätigung der eigenen These durch den Anbieter. Googles Threat Intelligence Group geht mit hoher Sicherheit davon aus, dass der Anstieg sehr groß angelegter Open-Source-Lieferkettenkampagnen im Laufe des Jahres 2025 und Anfang 2026 eine tatsächliche Ausweitung dieser Taktik darstellt und nicht auf eine verbesserte Erkennung zurückzuführen ist; die von ihr zitierten Zahlen der OpenSSF beziffern den Anstieg identifizierter bösartiger Open-Source-Pakete zwischen 2024 und 2025 auf mehr als 1.400 %.

Besonders interessant ist die Dauer der einzelnen Kampagnen. „Mastra“ lief etwa 88 Minuten lang. „axios“ hielt rund drei Stunden an. Die fünf bösartigen „jscrambler“-Varianten waren über ungefähr denselben Zeitraum aktiv. Die anderen Kampagnen verliefen genau umgekehrt: Sie liefen wochenlang unbemerkt ab, was wohl noch schlimmer ist. Beide Extreme dieses Spektrums stellen eine Herausforderung für Tools dar, die darauf ausgelegt sind, Bedrohungen im nächtlichen Rhythmus zu erkennen.

Realitätscheck: Eine Kampagne pro Monat bedeutet nicht, dass die Zahl der Angreifer entsprechend steigt. Die Automatisierung erklärt vieles davon, und das Jahr 2026 lieferte ein anschauliches Beispiel dafür. TeamPCP veröffentlichte am 12. Mai den vollständigen Quellcode des Mini-Shai-Hulud-Wurms auf GitHub, und innerhalb weniger Wochen tauchten abgeleitete Kampagnen auf, die diese Toolchain nutzten. Das Veröffentlichen eines Pakets lässt sich automatisieren, das Stehlen von Anmeldedaten lässt sich automatisieren, und die Nachahmung von Namespaces lässt sich schon seit Jahren automatisieren.

In unserer ausführlichen Übersicht erfahren Sie außerdem mehr über „Slopsquatting“ und Halluzinationen bei KI-Paketen.

Die sechs Feldzüge, die den Weg ebneten

Die folgenden sechs Fälle sind keine Top-6 nach Anzahl der Pakete. Es handelt sich um die sechs Fälle, die das Spektrum der diesjährigen Vorfälle am besten abdecken – von Übernahmen durch gestohlene Zugangsdaten (axios, jscrambler) über einen sich selbst verbreitenden Wurm und ein wiederbelebtes ruhendes Konto bis hin zu einer Prompt-Injektion, die auf KI-Prüfer abzielte, und einer Kontoübernahme durch Social Engineering.

Wenn man diese sechs Fälle nebeneinanderstellt, fällt eines auf: Bei keinem einzigen war eine Schwachstelle im Code des Opfers erforderlich. In jedem Fall wurde ein vertrauenswürdiger Schritt irgendwo zwischen der Tastatur des Betreuers und Ihrem Installationsbefehl ausgenutzt, und bei vier der sechs Fälle handelte es sich bei diesem Schritt um ein legitimes Betreuerkonto.

Die Gemeinsamkeiten zwischen Axios und Mastra sind kein stilistischer Zufall. Microsoft hat hinter beiden denselben Akteur eingesetzt, sodass es sich bei mindestens zwei der sechs um eine einzige Gruppe handelte, die ihren Ansatz zwischen den einzelnen Aktionen verfeinerte, und nicht um zwei Teams, die unabhängig voneinander auf dieselbe Idee kamen. Auch Hades und Mini Shai-Hulud haben einen gemeinsamen Ursprung. Es handelt sich also um sechs Kampagnen, die jedoch eher vier unterschiedlichen Clustern zuzuordnen sind – was ausdrücklich erwähnt werden sollte, bevor jemand die Zahl als sechs unabhängige Gruppen interpretiert.

Hades ist der Fall, bei dem es sich lohnt, einen Moment inne zu halten. Seine Pakete enthielten Prompt-Injektionen im Klartext, die darauf abzielten, einen LLM-basierten Analysator dazu zu bringen, sie als sicher einzustufen – was die Forscher als neuartige Umgehungstechnik bezeichneten. Diese Strategie funktioniert jedoch nur, wenn Angreifer davon ausgehen, dass mittlerweile KI-Tools zwischen dem Paket und dem Entwickler stehen. Bis Mitte 2026 ist dies durchaus realistisch. Der Fall bei Maven Central im Dezember nutzte ähnliche Störsignale gegen Machine-Learning-Analysen, sodass sich die Technik bereits seit Monaten im Verborgenen weiterentwickelt hatte. Hades betrieb zudem einen Token-Monitor, der mit zerstörerischen Maßnahmen drohte, falls die gestohlenen GitHub-Token widerrufen würden – was die Abfolge der Vorgänge für jeden, der Aufräumarbeiten durchführt, still und leise durcheinanderbringt.

PolinRider ist aus einem anderen Grund derjenige, vor dem man sich in Acht nehmen sollte. Hier handelte es sich nicht um opportunistisches Besetzen verlassener Domainnamen, und der gemeldete Angriffsweg ist seltsamer als ein Dump von Anmeldedaten. Forschern zufolge waren gestohlene GitHub-Anmeldedaten überhaupt nicht der Angriffsvektor. Die Opfer wurden zunächst über eine bösartige VS-Code-Erweiterung oder ein npm-Paket kompromittiert, woraufhin die Übernahme der Kontenverwaltung über abgelaufene Domains oder andere Wege zur Kontowiederherstellung erfolgte – alles verpackt in Social-Engineering-Techniken , für die das Team von „Contagious Interview“ bekannt ist. Eine saubere Veröffentlichungspraxis lässt dieses Risiko nicht verschwinden – das schwache Glied liegt in den Tools und der Kontowiederherstellung des Betreuers und nicht im Veröffentlichungsprozess.

Zwei weitere Kampagnen aus dem Jahr 2026 werden später in diesem Artikel behandelt. TrapDoor platzierte 34 schädliche Pakete auf npm, PyPI und Crates.io, und bei Laravel-Lang wurden mehr als 700 Versionen durch umgeschriebene Git-Tags manipuliert. TeamPCP ist ein anderer Fall. Es erhält keine eigene Zeile, da die Zeile „Mini Shai-Hulud“ bereits TeamPCP entspricht. Die umfassendere Operation, die Google als UNC6780 verfolgt, lief von Februar bis Mai und kettete CI/CD-Kompromittierungen von Sicherheitstools , darunter Trivy, Checkmarx und dessen KICS-Docker-Images sowie LiteLLM, zu einer einzigen langen Serie des Sammelns von Anmeldedaten verknüpfte. Größer als eine Tabellenzeile – derselbe Mechanismus.

Die Angriffsfläche hat sich auf die Installationsphase verlagert

Der rote Faden, der sich durch das gesamte Jahr 2026 zieht, ist das Timing.

Angreifer nutzten dieselbe Schwachstelle in npm, PyPI und Cargo aus drei verschiedenen Blickwinkeln aus, wobei TrapDoor das anschaulichste Beispiel ist, da in einer Kampagne alle drei genutzt wurden: ein Postinstall-Hook bei npm, die Ausführung zum Zeitpunkt des Imports bei PyPI und ein build.rs-Skript, das während des „cargo build“-Vorgangs auf Crates.io ausgelöst wird. Unterschiedliche Auslöser, dieselbe Idee. Der Code wird im Rahmen des Abrufs des Pakets ausgeführt, nicht im Rahmen seiner Nutzung. Die Go-Seite von PolinRider funktioniert wiederum anders, da die Payload in Konfigurationsdateien von Build-Tools und VS-Code-Aufgaben statt in einem Installations-Hook, sodass er ausgelöst wird, wenn die Tools eines Entwicklers das Projekt öffnen, anstatt bei „go get“. Derselbe Vertrauensmissbrauch, anderer Punkt in der Pipeline.

Standardwerkzeuge gehen davon aus, dass zwischen dem Auftreten einer Abhängigkeit und deren Ausführung ein Zeitfenster besteht, das lang genug ist, damit ein Scan zunächst etwas erkennen kann. Die Ausführung während der Installation beseitigt dieses Zeitfenster für alles, was Artefakte erst nach der Auflösung überprüft.

Stellen Sie sich eine 40-köpfige Entwicklerorganisation mit einer recht ausgereiften Pipeline vor. Dependabot eröffnet Pull-Requests, ein SCA-Tool scannt die Lockfile, CI blockiert bei allen Problemen mit hohem Schweregrad, und beim Build wird eine SBOM generiert. Diese Konfiguration geht gut mit bekannten, anfälligen Abhängigkeiten um. Bei einer Version, die vor einer Stunde veröffentlicht wurde, wie ein gewöhnlicher Patch-Bump aussieht, während der Installation ausgeführt wird und noch vor dem Mittagessen wieder zurückgezogen wird, ist sie jedoch weitaus weniger wirksam. Es gab keine Sicherheitswarnung, auf die ein Element in dieser Kette hätte abgeglichen werden können, und in den Fällen von Axios und Mastra befand sich die Schadlast eine Ebene tiefer, in einer Abhängigkeit, die der Scanner aus gutem Grund nicht genauer unter die Lupe nahm.

Achtung: Exaktes Pinning leistet mehr, als man ihm zutraut, und weniger, als man sich erhofft. Jeder, der auf ein sauberes Axios gepinnt hatte und während des dreistündigen Zeitfensters keine Neuinstallation durchgeführt hatte, kam unbeschadet davon. Was das Pinning Ihnen jedoch nicht verrät, ist, ob die Version, auf die Sie bewusst hochgestuft haben, vertrauenswürdig ist, und es nützt nichts, wenn ein ungenauer Bereich bei einer transitiven Abhängigkeit die Auflösung für Sie übernimmt. Genau so ist es bei Mastra passiert, da die eingefügte „easy-day-js“-Abhängigkeit als Caret-Bereich deklariert war und npm munter auf die „armed“-Patch-Version aktualisiert hat. Das Pinning geht zudem davon aus, dass sich das Artefakt hinter einer Version nicht ändern kann – was Laravel-Lang widerlegt hat, indem es historische Tags umgeschrieben hat, sodass sie nun auf einen neuen Commit verweisen.

Das Überprüfen von Paketen, bevor sie auf den Rechner eines Entwicklers oder einen Build-Agenten gelangen, ist einer der wenigen Punkte in der Kette, an denen Code während der Installation gestoppt werden kann, anstatt erst im Nachhinein gemeldet zu werden. Das ist die Lücke SecureChain for OSS schließen soll – und das ist auch der Grund, warum es auf Registry-Ebene angesiedelt ist, anstatt der Pipeline am Ende einen weiteren Scanner hinzuzufügen.

Warum Ihr Scanner immer zu spät ist

Die herkömmliche, auf CVE ausgerichtete Software-Kompositionsanalyse ist bei einer Frage besonders gut: Welche Komponenten mit bekannten Sicherheitslücken haben es in diesen Build geschafft? Darin ist sie wirklich gut, und es lohnt sich, sie beizubehalten.

Das allein beantwortet jedoch noch keine andere Frage: Ist dieses Artefakt zum jetzigen Zeitpunkt tatsächlich das, was sein Betreuer veröffentlicht hat?

Das ist eher ein Datenproblem als ein Produktproblem. Eine auf Schwachstellen ausgerichtete SCA gleicht Ihr Abhängigkeitsinventar mit den Daten aus Sicherheitshinweisen ab, und ein Sicherheitshinweis existiert erst, wenn jemand das schädliche Paket gefunden, gemeldet und die Veröffentlichung des Hinweises veranlasst hat. Die Erkennung erfolgt oft schnell. Socket hat die bösartige „jscrambler“-Version sechs Minuten nach der Veröffentlichung markiert, und bei den TrapDoor-Paketen lagen durchschnittlich weniger als sechs Minuten zwischen Veröffentlichung und Erkennung. Die Abfrage der Sicherheitshinweise durch Ihren Scanner ist der langsame Teil, und viele dieser Vorfälle führen überhaupt nicht zur Vergabe einer CVE-Nummer – was auch der Grund dafür ist, dass keiner von ihnen jemals im CISA-Katalog bekannter ausgenutzter Schwachstellenauftauchen wird. Sicherheitshinweise sind naturgemäß eine Aufzeichnung dessen, was bereits entdeckt wurde.

Wissenswertes: Im Rahmen mehrerer „2026“-Kampagnen wurden bösartige Versionen veröffentlicht, die wie gewöhnliche Versionserhöhungen aussahen, ohne dass ein entsprechender Commit, Pull Request oder Tag dahinterstand. jscrambler 8.14.0 ist der deutlichste Fall, da Forscher im GitHub-Repository des Projekts keinen Commit, kein Tag und keinen PR dafür fanden – dort lautete das aktuellste Tag weiterhin 8.13.0. Herkömmliche Updater prüfen nicht, ob ein Artefakt einer Änderung am Quellcode entspricht. Sie erkennen eine neue Versionsnummer, eröffnen einen Pull-Request, und manche Teams führen diesen automatisch zusammen. Eine Versionserhöhung und eine verifizierte Änderung sind nicht dasselbe.

Wohin die Zahlen zum Ökosystem als Nächstes weisen

Bis 2024 und über den größten Teil des Jahres 2025 hinweg stand npm dank seiner hohen Nutzerzahlen und der Lebenszyklus-Skripte, die bei der Installation automatisch ausgeführt werden, im Mittelpunkt des Interesses. Diese Phase ist nun vorbei.

TrapDoor griff im Mai innerhalb derselben Woche drei Ökosysteme an, mit 34 bösartige Pakete und mehr als 384 Versionen auf npm, PyPI und Crates.io. Es handelte sich dabei nicht um gekaperte, sondern um gefälschte Tools, deren Namen so gewählt waren, dass sie wie Dienstprogramme wirkten, die ein Krypto- oder KI-Entwickler ohne zu zögern installieren würde, und jede Registry erhielt ihren eigenen Ausführungsweg. Außerdem wurden .cursorrules- und CLAUDE.md-Dateien abgelegt, um KI-Programmierassistenten zu steuern – ein guter Vorgeschmack darauf, in welche Richtung sich diese Entwicklung fortsetzen wird.

Auch für Packagist war der Mai ein schwieriger Monat. Am 22. und 23. Mai haben Angreifer innerhalb eines Zeitfensters von etwa 90 Minuten alle Git-Tags in vier Laravel-Lang-Lokalisierungs-Repositorys umgeschrieben und mehr als 700 ältere Versionen verwiesen schließlich auf einen bösartigen Commit, den der Autoloader von Composer anschließend bei jeder Anfrage ausführte. Der Einstiegspunkt war ein durchgesickertes GitHub-Token, und der Quellcode des Projekts wurde dabei nicht berührt. Unabhängig davon verbarg eine Kampagne mit acht Paketen versteckte ihre Schadcode in der Datei „package.json“ anstatt in „composer.json“, wodurch sie genau dort platziert wurde, wo bei einer auf PHP ausgerichteten Überprüfung am wenigsten danach gesucht wurde.

In unserem umfassenden Leitfaden zur Laravel-Sicherheit finden Sie außerdem bewährte Vorgehensweisen zum Schutz Ihres PHP-Ökosystems.

Und im Dezember 2025, kurz vor dem Zeitraum, den dieser Artikel abdeckt, tauchte ein Typosquatting-Variante, die dem Namen „Jackson“ ähnelt, auf Maven Central auf, das ein Cobalt-Strike-Beacon enthielt. Der Trick bestand in einem Präfix-Tausch: „org.fasterxml“ anstelle von „com.fasterxml“, das die echte Bibliothek verwendet – ein Manöver, das von der Reverse-Domain-Konvention von Java nicht erkannt wird. Aikido, das die Malware entdeckte, bezeichnete sie als die erste ausgeklügelte Malware, die sein Team auf Maven Central entdeckt hatte; man sollte dies also eher als eine Premiere für diese Forscher denn für das gesamte Ökosystem betrachten. Die Entfernung erfolgte zumindest zügig, etwa 90 Minuten nach der Meldung.

Man sollte dies eher als eine Verlagerung der Ausrichtung der Kampagnen verstehen und nicht als einen klaren Vorher-Nachher-Unterschied, da bösartige Pakete bereits zuvor in den meisten dieser Registries aufgetaucht waren. Für ein Unternehmen, das mehrere Programmiersprachen einsetzt, lautet die praktische Erkenntnis, dass Abwehrmaßnahmen pro Ökosystem in der Summe keine echte Abdeckung mehr gewährleisten. Solide npm-Kontrollen, lockere PyPI-Praktiken und das völlige Fehlen von Go oder Rust führen dazu, dass zwar die Vordertür verschlossen ist, aber mehrere Seiteneingänge offen stehen – und die Daten dieses Jahres zeigen, dass Angreifer diese bereits ausprobieren.

Was kann man dagegen tun?

Dafür ist keine Neugestaltung der Architektur erforderlich. All dies lässt sich noch in diesem Quartal umsetzen.

Wenn Sie ein primäres Ökosystem haben

Schließen Sie dort zunächst die Lücke bei der Installation. Setzen Sie „ignore-scripts=true“ in der Datei „.npmrc“, wo immer Ihr Build dies zulässt, und leiten Sie Installationen über eine Registry-Ebene, die Pakete vor der Auflösung überprüft. Betrachten Sie das Blockieren von Skripten jedoch nicht als die einzige Lösung. Bei zwei der fünf bösartigen „jscrambler“-Versionen wurde der Dropper aus dem „preinstall“-Hook in den Hauptcode des Pakets und die CLI verschoben, wo „–ignore-scripts“ überhaupt keine Wirkung zeigt.

Wenn Sie mehrsprachig sind

Finden Sie heraus, welche Ökosysteme noch nicht kontrolliert werden, bevor Sie sich eingehender mit denen befassen, für die bereits Kontrollen bestehen. In diesem Bedrohungsmodell sind Lücken in der Abdeckung schwerwiegender als Lücken in der Tiefe. Sowohl TrapDoor als auch PolinRider haben gezeigt, dass bereits ein einziges unkontrolliertes Ökosystem ausreicht, um die Arbeit an allen anderen Stellen zunichte zu machen.

Wenn Sie sich auf automatische Abhängigkeitsaktualisierungen verlassen

Fügen Sie bei neuen Veröffentlichungen ein Verzögerungsfenster hinzu. Die Empfehlungen von Unit 42 zur Risikominderung empfehlen, alle in den letzten 24 bis 72 Stunden veröffentlichten Versionen zu blockieren, da die meisten schädlichen Pakete innerhalb dieses Zeitraums identifiziert und entfernt werden; Wiz verfolgt mit einer 24-stündigen Wartezeit einen ähnlichen Ansatz. Eine kurze Quarantäne macht einen Großteil dieser Angriffe unschädlich, auch wenn man dadurch bei den Patches etwas ins Hintertreffen gerät.

Es ist besser, eine Kontrollinstanz vorzuverlegen, als eine weitere am Ende anzuhängen. Zwei Aspekte sind dabei besonders wichtig: ein Paket abzufangen, bevor es aufgelöst wird, und zu überprüfen, ob das erhaltene Artefakt mit der Quelle und dem Build übereinstimmt, aus denen es angeblich stammt.

Es lohnt sich, die Provenienzfunktion zu aktivieren – allerdings mit einer Einschränkung. Mastra generierte zwar bei CI-Veröffentlichungen eine Provenienz, verlangte diese jedoch nicht, sodass ein gestohlenes Token weiterhin ohne Bescheinigungen veröffentlichen konnte, während die TanStack-Welle von „Mini Shai-Hulud“ Pakete mit gültiger SLSA-Provenienz erzeugte, da die Pipeline selbst manipuliert war. Hätte man Bescheinigungen verlangt, hätte dies den ersten Fall verhindert, nicht jedoch den zweiten.

Auch der Umfang variiert je nach Ökosystem. Die Übernahme von Go-Konten und PyPI-Startup-Hooks sind unterschiedliche Probleme, die unterschiedliche Lösungen erfordern. Daher muss jede Kontrollmaßnahme, für die man bereit ist zu zahlen, berücksichtigen, wie das jeweilige Ökosystem Code tatsächlich ausführt.

Was das für Sie bedeutet

Hier gibt es nichts Exotisches. 2026 hat keine neue Klasse von Sicherheitslücken erfunden. Es hat den Kampf an einen Ort verlagert, den die meisten Teams nicht im Blick hatten, nämlich den Moment, in dem ein Paket aufgelöst und ausgeführt wird, und nicht den Moment, in dem es schließlich gescannt wird. Jede Kampagne auf dieser Liste – vom dreistündigen npm-Hijack bis hin zu einem Go-Modul, auf das über ein gekapertes Betreuerkonto zugegriffen wurde – funktionierte, weil Vertrauen gewährt wurde, bevor eine Kontrollinstanz die Möglichkeit hatte, einen Blick darauf zu werfen, sei es während der Auflösung, der Installation, des Builds oder in dem Moment, in dem ein Editor das Projekt öffnete.

Die eigentliche Frage ist also nicht, ob die Erkennung nach der Installation beibehalten werden soll. Behalten Sie sie bei. Die Frage ist vielmehr, ob die Prävention früher ansetzt, sodass ein Scan, der erst durchgeführt wird, nachdem die Payload bereits Zugriff auf Ihre CI-Geheimnisse erlangt hat, nicht das erste ist, was Sie darauf aufmerksam macht. SecureChain für OSS ist für Teams gedacht, die genau das wollen, ohne es selbst entwickeln zu müssen.

SecureChain herunterladen → 

FAQ

Was ist ein Angriff auf die Software-Lieferkette?

Ein Angriff, bei dem Software über eine vertrauenswürdige Abhängigkeit, ein Build-System, ein Repository oder einen Vertriebskanal kompromittiert wird, anstatt direkt auf Ihre Anwendung abzuzielen. Die Kampagnen des Jahres 2026 richteten sich überwiegend gegen öffentliche Paketregister und die Konten, die dort Inhalte veröffentlichen.

Wie viele Angriffe auf die Software-Lieferkette gab es im Jahr 2026?

Es gibt keine verlässliche Gesamtzahl. Dieser Artikel befasst sich mit sechs großen Kampagnen, die zwischen März und Juli 2026 bestätigt wurden, und mehrere weitere liegen knapp außerhalb dieses Zeitraums, darunter „TrapDoor“, „Laravel-Lang“ und die umfassendere Operation „TeamPCP“.

Verhindert eine SBOM Angriffe auf die Lieferkette?

Nein. Eine SBOM listet auf, welche Komponenten in einen Build eingeflossen sind, was für die Reaktion auf Vorfälle und für Audits von großem Nutzen ist. Sie belegt jedoch nicht, dass ein aufgeführtes Artefakt tatsächlich dasjenige ist, das sein Betreuer veröffentlicht hat, und sie verhindert auch nicht, dass Code während der Beschaffung von Abhängigkeiten ausgeführt wird.

Welche Paket-Ökosysteme waren am stärksten betroffen?

npm war Schauplatz der meisten der vielbeachteten Vorfälle des Jahres 2026, während PyPI, Go-Module, Crates.io und Packagist bis zur Jahresmitte alle Ziel von gezielten Kampagnen waren, die mehrere Pakete betrafen. Maven Central hatte kurz vor Jahresbeginn seinen eigenen Höhepunkt.

SecureChain herunterladen → 

Zusammenfassung

Artikel Name

Angriffe auf die Software-Lieferkette im Jahr 2026

Beschreibung

Sechs große Supply-Chain-Kampagnen betrafen npm, PyPI, Go und Packagist. Was sie gemeinsam haben und warum sie bei Scans nach der Installation immer wieder übersehen werden.

Autor

Tim Walker

Name des Herausgebers

TuxCare

Logo des Herausgebers