Cybersicherheit

Wie sich Schadcode über die Lieferkette in vertrauenswürdige Software einschleicht

Susan Hill

Ein Lieferkettenangriff bricht nicht in die Software ein, die du nutzt. Er vergiftet einen der Bausteine, aus denen diese Software gebaut ist, und wartet, bis der ganz normale Update-Vorgang ihn auf dein Gerät trägt. Die App installiert sich sauber, die Signatur stimmt, und das Update kommt über den offiziellen Kanal. Der Schadcode reist einfach mit. Genau diese Umkehrung macht die Technik so wirksam. Sie verwandelt das Vertrauen, das Software funktionieren lässt, in den Punkt, der ausgenutzt wird.

Fast nichts, was du heute ausführst, stammt vollständig von dem Unternehmen, dessen Name darauf steht. Eine einzige App kann Hunderte oder Tausende quelloffene Pakete hereinziehen, jedes von Fremden gepflegt, jedes mit weiteren Paketen im Schlepptau. Entwickler lesen diesen Code selten; sie vertrauen der Registry, aus der er kommt, und der Versionsnummer daran. Wer sich in irgendein Glied dieser Kette schleicht, erreicht alle weiter unten auf einen Schlag, und deshalb kann ein einziger vergifteter Baustein Zehntausende Projekte treffen, bevor es jemand bemerkt.

Die Einstiegspunkte lassen sich auf wenige Muster eingrenzen. Typosquatting platziert ein Schadpaket mit einem Namen, der einen Tastendruck vom Original entfernt liegt, und wartet auf den Tippfehler. Dependency Confusion nutzt aus, wie Build-Werkzeuge Namen auflösen, und bringt sie dazu, ein öffentliches Paket statt des privaten des Unternehmens zu greifen. Eine Kontoübernahme kapert die Zugangsdaten eines echten Betreuers und verteilt Schadsoftware als ganz gewöhnliches Update; Anfang 2026 lieferte das weit verbreitete Paket axios kurzzeitig eine kompromittierte Version aus, nachdem der Rechner seines Hauptbetreuers per Social Engineering geknackt worden war. Und die Vergiftung der Build-Pipeline zielt auf die automatischen Systeme, die Software zusammenbauen und ausliefern, wo ein einziger manipulierter Schritt jedes abhängige Projekt erreicht.

Die Build-Pipeline ist gerade deshalb zum wertvollsten Ziel geworden, weil sie allem anderen vorgelagert ist. Als die beliebte GitHub-Actions-Komponente tj-actions/changed-files 2025 kompromittiert wurde, schrieben Angreifer ihre Versions-Tags so um, dass sie auf Schadcode zeigten, und zogen Geheimnisse aus den Build-Logs von mehr als zwanzigtausend Repositories: Zugangsschlüssel, Tokens und private Schlüssel, alles im Klartext. Eine spätere Kampagne, von Forschern Megalodon genannt, machte GitHub Actions zu einer sich selbst verbreitenden Hintertür, die in etwa sechs Stunden 5.561 Repositories erreichte. Die Maschine, die deine Software baut, lässt sich genauso leicht unterwandern wie die Software selbst.

Auch die Werkzeuge, die Entwickler täglich nutzen, liegen im Wirkungsbereich. GlassWorm, erstmals Ende 2025 entdeckt, verbreitete sich über Erweiterungen für Visual Studio Code in den Marktplätzen von OpenVSX und Microsoft. Es versteckte seine Nutzlast mit unsichtbaren Unicode-Zeichen, sodass die schädlichen Zeilen im Editor buchstäblich unlesbar waren und der menschlichen Prüfung entgingen. Einmal installiert, stahl es Zugangsdaten von npm, GitHub und Git und nutzte sie, um automatisch weitere Pakete und Erweiterungen zu infizieren, das bestimmende Merkmal eines Wurms. Weil Editoren Erweiterungen still im Hintergrund aktualisieren, erhielten Opfer die vergifteten Versionen, ohne irgendetwas anzuklicken. Eine weitere vergiftete VS-Code-Erweiterung diente dazu, rund 3.800 interne Repositories von GitHub selbst zu stehlen.

Was diese Angriffe so schwer fassbar macht, ist, dass jeder einzelne Schritt legitim aussieht. Das Paket ist signiert. Das Update kommt aus der echten Registry. Das Betreuerkonto ist echt. Klassische Abwehr sucht nach bekannten Schaddateien und offensichtlicher Malware, doch Lieferkettenangriffe verstecken sich in vertrauenswürdigem, erwartetem und oft unsichtbarem Code, der genau dann und genau so eintrifft, wie Software eintreffen soll. Schlimmer noch: der altbekannte Sicherheitsrat, sofort zu aktualisieren, ist genau der Mechanismus, auf den der Angreifer setzt. Zum ersten Mal ist es nicht mehr eindeutig sicher, die neueste Version zu installieren.

Die Verteidiger sind sich bei einer Handvoll Praktiken einig geworden, die wirken. Lockfiles fixieren jede Abhängigkeit auf eine genaue, geprüfte Version, sodass ein Installer nur das holt, was geprüft wurde, statt einfach das Neueste. Das Abschalten automatischer Installationsskripte blockiert den häufigsten Weg, auf dem ein Schadpaket Code ausführt, sobald es ankommt. GitHub Actions an einen bestimmten Commit-Hash zu binden statt an ein bewegliches Tag macht den Tag-Umschreib-Trick wirkungslos. Eine Software-Stückliste, eine detaillierte Aufstellung jeder Komponente in einem Build, lässt ein Team binnen Minuten erkennen, ob es betroffen ist, wenn der nächste Vorfall öffentlich wird. Viele Organisationen, die den jüngsten Angriffen entgingen, taten nichts Exotisches: Sie bauten aus einer eingecheckten Lockfile und arbeiteten hinter einem Registry-Proxy, der frisch veröffentlichte Pakete in Quarantäne nahm.

Für Menschen, die keinen Code schreiben, ist der Schutz vor allem indirekt, die Lehre aber nicht. Die Software-Lieferkette ist heute ein Schlachtfeld ersten Ranges, und es sind die Firmen, die die Apps auf deinem Handy und Laptop bauen, die sie absichern müssen. Die vernünftige Reaktion ist weder Panik noch der alte Reflex, alles zu aktualisieren, sobald ein Hinweis erscheint. Sie besteht darin, Software von Teams zu bevorzugen, die offenlegen, was sie ausliefern und wie sie es bauen, und eine vertrauenswürdige Quelle als etwas zu behandeln, das an jedem Glied verdient werden muss, statt als Eigenschaft, die von selbst die Kette hinabwandert.

Die Antwort der Branche nimmt rund um die Herkunft Gestalt an: ein kryptografischer Nachweis, woher ein Stück Code stammt und wie es gebaut wurde, automatisch geprüft, bevor irgendetwas installiert wird. Es ist dieselbe Idee, die vor einer Generation den Webverkehr absicherte, nun angewandt auf das Fließband der Software selbst. Bis dieser Nachweis selbstverständlich ist, bleibt jede Installation ein Akt des Vertrauens in Menschen, die du nie kennenlernen wirst.

Diskussion

Es gibt 0 Kommentare.