Inwiefern unterscheidet sich das von „pip-audit“ oder „Composer audit“?

Das sind Audits nach der Installation – sie laufen, nachdem der Code eines Pakets bereits auf der Festplatte ist (und möglicherweise schon ausgeführt wurde). Ein 5bats-Gate prüft vor der Installation den gesamten Dependency-Baum und hält Releases zurück, die zu neu sind, um bereits geprüft worden zu sein.

Tätigen die Gates ausgehende Anrufe?

Sie durchsuchen öffentliche Schwachstellen-Feeds (OSV, Sicherheitshinweis-Datenbanken), um ein Paket zu überprüfen – das ist ihre Aufgabe –, senden aber keine Telemetrie und führen keine Protokolle. Die Überprüfung läuft lokal ab und bricht ab, wenn ein Feed nicht erreichbar ist.

Warum gibt es kein „npm-Gate“?

So ist es nun mal. pnpm verfügt über eine integrierte Einstellung für das Mindestalter von releases, und für npm gibt es bereits bewährte Tools – 5bats erfindet das also nicht neu. Die gates konzentrieren sich auf pip, Composer, Homebrew und KI-Coding-Assistenten.

Supply-chain gates

pip install, composer install und brew upgrade führen den eigenen Code eines Pakets während der Installation aus – ein bösartiges Paket wird also sofort ausgeführt, sobald es installiert wird, noch bevor eine Überprüfung nach der Installation stattfinden kann. Diese Gates verlagern die Überprüfung auf den Zeitpunkt vor der Installation.

Warum das wichtig ist

Angreifer nutzen diese Ausführung während der Installation ständig aus – typosquats, gekaperte Maintainer-Konten und bösartige zero-day-Releases, die im Netz landen und stundenlang heruntergeladen werden, bevor sie von einer Datenbank als bedenklich markiert werden. OWASP stuft anfällige und veraltete Komponenten in seinen Top 10 als A06 ein, und das gefährlichste Zeitfenster sind die ersten Stunden nach der Veröffentlichung einer fehlerhaften Version – genau dann, wenn noch kein Sicherheitshinweis sie erfasst hat, sodass eine Überprüfung nach der Installation nichts mehr nützt.

Zwei Vorfälle im Mai 2026 machen das deutlich (wie berichtet): Bei Laravel-Lang haben Angreifer mit gestohlenen Zugangsdaten innerhalb weniger Minuten bösartige releases über rund 700 Versionen verteilt, die über die Post-Install-Hooks von Composer ausgeführt wurden, bevor composer audit sie als bedrohlich kennzeichnen konnte; bei TrapDoor wurden über 34 Pakete auf PyPI, npm und Crates.io beim Import automatisch ausgeführt, um SSH-Schlüssel und Anmeldedaten zu stehlen – und jedes PyPI-Paket war zum Zeitpunkt der Meldung nicht älter als 72 Stunden, sodass eine freshness hold allein sie bereits blockiert hätte, ganz ohne CVE.

Die unten aufgeführten gates führen diese Überprüfung vor der Installation durch – und zwar über den gesamten Dependency-Baum hinweg. Dabei werden releases zurückgehalten, die zu neu sind, um als vertrauenswürdig zu gelten, und der Vorgang bricht ab, wenn etwas nicht verifiziert werden kann.

→ Ausführliche Erklärung: Was ist ein Angriff auf die supply chain? – wie er funktioniert, die Angriffsarten, das „Freshness Window“ und wie man sich dagegen schützen kann.

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

Die Prüfung rückt vor den Install: ein bösartiges oder zu frisches Paket erreicht Deinen Rechner nie.

Die Werkzeuge

pip-cve-gate

Jedes pip install kann Code einbinden, der sofort ausgeführt wird, sobald er eintrifft – und ein brandneues bösartiges Paket taucht meist auf, bevor die Sicherheitsdatenbanken überhaupt auf dem neuesten Stand sind. pip-cve-gate überprüft zuerst den gesamten Dependency-Baum und hält releases zurück, die zu neu sind, um ihnen zu vertrauen, sodass das bösartige Paket gar keine Chance hat, ausgeführt zu werden.

Mehr über pip-cve-gate erfahren →

composer-cve-gate

Composer führt die eigenen Skripte eines Pakets während der Installation aus, sodass ein bösartiges PHP-Paket ausgeführt wird, bevor Du es überhaupt zu Gesicht bekommst. composer-cve-gate überprüft die gesamte lockfile, bevor composer install ausgeführt wird, und blockiert alles, was anfällig, bösartig oder verdächtig neu ist – und schließt damit die Lücke, die die eigene Überprüfung von Composer offen lässt.

Mehr über composer-cve-gate erfahren →

homebrew-safe-upgrade

Homebrew-Pakete werden nicht vorab geprüft, und schon eine einzige manipulierte Formel kann Malware auf Tausende von Macs übertragen. homebrew-safe-upgrade überprüft jedes Paket und dessen dependencies vor dem Upgrade auf bekannte Schwachstellen, hält Releases zurück, die erst wenige Tage alt sind, und bricht den Vorgang ab, wenn etwas nicht verifiziert werden kann.

Mehr über homebrew-safe-upgrade erfahren →

claude-code-cve-gate

Wenn Claude Code ein Paket für Dich installiert, geschieht dies mit deinem Zugriff und deinen Anmeldedaten – daher stellen seine Installationen Deine Angriffsfläche dar. claude-code-cve-gate überprüft im Hintergrund jede Installation, die der Assistent versucht – pip, npm, composer, Cargo, go, Gem, brew –, anhand der Datenbanken für Schwachstellen, bevor sie ausgeführt wird.

Mehr über claude-code-cve-gate erfahren →

mistral-code-cve-gate

Der gleiche Schutz für Mistral-basierte Coding-Tools, mit einem nachvollziehbaren Protokoll jeder Überprüfung – entwickelt für datensouveräne, regulierte Arbeitsabläufe in der EU, bei denen Du nachweisen musst, was ausgeführt wurde. Die Konfiguration entspricht der von claude-code-cve-gate.

Mehr über mistral-code-cve-gate erfahren →

TrapDoor hat sich nicht nur auf Pakete beschränkt – es hat auch KI-Assistenten zu Komplizen gemacht.

Siehe Sicherheit von KI-Agenten für den anderen Teil der Verteidigung.