Was ist ein Angriff auf die Software-Supply-Chain?

Ein Angriff auf die Software-Supply Chain liegt vor, wenn ein Angreifer nicht etwas kompromittiert, das Du selbst geschrieben hast, sondern etwas, das Du installierst – ein Paket, eine dependency, ein Update –, sodass sein Code auf Deinem Rechner als vertrauenswürdiger Teil Deines Projekts ausgeführt wird. Du hast in Deinem eigenen Code keinen Fehler gemacht; Du hast einfach pip install, composer install oder brew upgrade ausgeführt und damit die Sicherheitslücke eines anderen mit einbezogen. OWASP stuft anfällige und veraltete Komponenten in seinen Top 10 als A06 ein, und diese Angriffe sind zu einer der häufigsten Methoden geworden, mit denen Entwickler kompromittiert werden.

In diesem Leitfaden wird erklärt, wie supply chain Angriffe funktionieren, welche Hauptarten es gibt, warum die ersten Stunden nach einer release so entscheidend sind und wie man sich dagegen schützen kann.

So funktioniert ein Angriff auf die supply chain

Der Installationsschritt führt Code aus

Die entscheidende Tatsache, die die meisten Leute übersehen: Beim Installieren eines Pakets wird dessen Code oft ausgeführt. pip führt setup.py und Post-Install-Hooks aus, Composer führt Skripte aus, npm führt preinstall/postinstall aus, Homebrew führt Formelcode aus. Ein bösartiges Paket wartet also nicht darauf, dass Du es importierst – es wird sofort bei der Installation ausgeführt. Wenn ein Post-Install-Prüfprogramm (pip-audit, composer audit, safety) läuft, befindet sich der Code bereits auf der Festplatte und wurde möglicherweise schon ausgeführt.

Die wichtigsten Angriffsarten

• Typosquatting – ein Paket, dessen Name sich nur um einen Buchstaben von einem beliebten Namen unterscheidet, in der Hoffnung, dass Du Dich vertippst oder einen falschen Befehl kopierst.
• Gekaperte Maintainer-Konten – Ein Angreifer stiehlt die Zugangsdaten eines echten Maintainers und veröffentlicht eine bösartige Version eines legitimen, vertrauenswürdigen Pakets, das Du bereits nutzt.
• Verwechslung von Abhängigkeiten – Ein Angreifer veröffentlicht ein öffentliches Paket mit demselben Namen wie eines Deiner privaten internen Pakete, und das Installationsprogramm wählt das öffentliche (bösartige) Paket aus.
• Bösartige Updates bei echten Paketen – eine bisher saubere Abhängigkeit wird in einer neuen Release bösartig, oft tief in Deinem Baum verborgen als transitive Abhängigkeit, die Du nie direkt ausgewählt hast.

Warum die ersten Stunden am wichtigsten sind

Wenn eine bösartige Version veröffentlicht wird, gibt es ein Zeitfenster – oft mehrere Stunden –, bevor eine Sicherheitsdatenbank sie erfasst. Während dieses Zeitfensters melden Schwachstellenscanner „alles klar“, da sie nur über bereits gemeldete Schwachstellen Bescheid wissen. Der Angriff ist genau dann am effektivsten, wenn Deine Tools am blindesten sind.

Deshalb blockiert ein freshness hold – also die Weigerung, releases zu installieren, die erst seit wenigen Stunden oder Tagen verfügbar sind, bis sie überprüft werden konnten – eine ganze Klasse von Angriffen, die keine CVE-Datenbank rechtzeitig erkennen könnte.

Tatsächliche Vorfälle (wie berichtet)

Zwei Kampagnen im Mai 2026 verdeutlichen diesen Trend:

• Laravel-Lang (Packagist) – Angreifer mit gestohlenen Veröffentlichungszugangsdaten haben bösartige releases in etwa 700 Versionen in wenigen Minuten. Der Stealer lief die Post-Install-Hooks von Composer durch, sodass zu dem Zeitpunkt, als composer audit könnte alles markieren, was es bereits ausgeführt hatte.
• TrapDoor – gilt als die erste gleichzeitige Kampagne, die mehrere Ökosysteme betrifft: über 34 bösartige Pakete in PyPI, npm und Crates.io – werden beim Import automatisch ausgeführt, um SSH-Schlüssel, Cloud- und GitHub-Zugangsdaten sowie Kryptowährungsdaten zu stehlen Wallets. Jedes betroffene PyPI-Paket war zum Zeitpunkt der Meldung weniger als 72 Stunden alt – allein eine freshness hold hätte Habe sie alle blockiert, kein CVE nötig. TrapDoor hat außerdem CLAUDE.md-Injection-Payloads eingeschleust, was darauf hindeutet, dass es mit Prompt injection .

Weiterführende Literatur: OWASP — A06: Schwachstellen und veraltete Komponenten · TrapDoor (The Hacker News ) · Laravel-Lang Packagist-Hack (alert ).

Wer ist gefährdet?

Jeder, der dependencies installiert – also jeder, der Software veröffentlicht. Einzelentwickler und kleine Teams sind genauso stark betroffen wie große Unternehmen, verfügen aber oft über weniger Schutzmaßnahmen. Wenn Du einen KI-Programmierassistenten Pakete für Dich installieren lässt, vervielfacht sich das Risiko: Der Assistent installiert mit Deinen Zugangsdaten und Deinen Zugriffsrechten, sodass ein bösartiges Paket in Deinem Namen ausgeführt wird – ausgelöst durch ein Tool, das in Deinem Auftrag handelt.

So schützt man sich vor Angriffen auf die supply chain

Prüfe es vor der Installation, nicht danach

Verlege die Sicherheitsprüfung auf vor der Installation, und zwar über den gesamten Dependency-Baum hinweg – nicht nur für das von Dir genannte Paket, sondern für alles, was es mit einbezieht. Eine Überprüfung nach der Installation ist eine Sicherheitsmaßnahme im Nachhinein; eine Überprüfung vor der Installation ist ein echter gate.

Die neuesten releases zurückhalten

Richte eine „freshness hold“-Regel ein, damit brandneue Versionen erst nach ein paar Tagen zugelassen werden. Du verzichtest dabei auf nichts Wesentliches – Du brauchst so gut wie nie eine release, die erst ein paar Stunden alt ist – und schließt damit die Lücke, auf die Angreifer setzen.

Fail geschlossen

Wenn ein Tool etwas nicht überprüfen kann – einen nicht erreichbaren Sicherheitshinweis-Feed, eine Version, die es nicht auswerten kann, ein Paket, dessen Alter es nicht bestimmen kann –, sollte es die Prüfung unterbrechen und nicht einfach durchwinken. A gate that fails to open when there is a problem gives false confidence, which is worse than no gate. The default setting „deny when unsure“ makes a gate trustworthy.

Die kostenlosen Tools, die 5bats dafür entwickelt

5bats verwandelt diese Schutzmechanismen in vorinstallierte Gates, die Du lokal und kostenlos ausführen kannst, ganz ohne Aufrufe von Drittanbietern – und zwar über die Paketmanager, die Entwickler tatsächlich nutzen (pip, Composer, Homebrew und KI-Programmierassistenten):

• pip-cve-gate – ein Drop-in-pip-Wrapper, der den gesamten Baum anhand von OSV, der PyPI Advisory DB und der OSSF-Liste bösartiger Pakete überprüft – mit einer freshness hold –, bevor pip irgendetwas ausführt.
• composer-cve-gate — Gates bei composer install aus der lockfile (die Lücke, die composer audit hinterlässt), über fünf Signale hinweg.
• homebrew-safe-upgrade — überprüft jede Formel und ihre dependencies, hält zu neue releases zurück, verifiziert den SHA-Hash des Downloads und bricht bei Fehlern ab.
• claude-code-cve-gate und mistral-code-cve-gate – fangen jede Installation ab, die ein KI-Assistent versucht, damit er mit Deinen Zugangsdaten kein bösartiges Paket herunterladen kann.

→ Schau Dir auf der Seite supply-chain gates an, wie das alles zusammenpasst.

FAQ

Was ist der Unterschied zwischen dem hier und pip-audit oder composer audit?

Das sind Prüfungen nach der Installation – sie laufen ab, nachdem der Code des Pakets bereits auf Deiner Festplatte ist (und möglicherweise schon ausgeführt wurde). Eine Prüfung vor der Installation findet bevor irgendetwas ausgeführt wird statt, deckt den gesamten Dependency-Baum ab und kann releases zurückhalten, die zu neu sind, um bereits geprüft worden zu sein.

Warum hat 5bats kein npm-Gate?

So ist es nun mal. pnpm verfügt über eine integrierte Einstellung für das Mindestalter von releases, und es gibt bereits bewährte Tools für das npm-Ökosystem – 5bats erfindet das also nicht neu. Der Fokus liegt auf pip, Composer, Homebrew und KI-Coding-Assistenten. npm taucht hier immer noch als Teil des Bedrohungsbildes auf – TrapDoor hat es abgedeckt –, nur eben nicht als 5bats-Tool.

Hält mich ein Frischeverlust auf?

So gut wie nie, zumindest nicht in einer Weise, die wirklich zählt. Man braucht so gut wie nie eine release, die erst ein paar Stunden alt ist, und wenn man ein paar Tage wartet, schließt sich genau das Zeitfenster, auf das Angreifer setzen.

Hast Du einen Fehler oder eine Lücke entdeckt?

5bats lässt sich lieber korrigieren, als selbstbewusst im Unrecht zu liegen. Falls hier etwas ungenau oder veraltet ist oder eine Bedrohung fehlt, melde Dich über Session oder E-Mail – Korrekturen und Ergänzungen sind wirklich willkommen.

Lasst die Tools kostenlos bleiben

Dieser Leitfaden und die darin genannten Tools sind kostenlos und selbst finanziert. Wenn Dir diese Arbeit nützlich ist, kannst Du Sponsor werden – so bleibt sie gepflegt, wird auf CVE-Schwachstellen geprüft und bleibt für alle kostenlos – kein Konto, kein Tracker von Drittanbietern, nur ein einfacher Link.