Ein Repository zu öffnen galt lange als harmlose Handlung. Man klont den Code, sieht sich an, was darin steckt, und entscheidet erst danach, ob man ihn ausführt. Genau diese Trennung löst sich gerade auf. Das Sicherheitsunternehmen JFrog hat nach eigenen Angaben Schadcode in 42 GitHub-Repositories entdeckt, der sich automatisch startet – unter anderem durch KI-Assistenten oder im Zuge der normalen Arbeit an einem Projekt. Die Repositories wurden für eine Wurm-Kampagne im npm-Umfeld gekapert, also im Paket-Ökosystem der JavaScript-Welt.

Das Beunruhigende daran ist weniger die Zahl als der Auslöser. Es braucht keinen unvorsichtigen Entwickler mehr, der ein verdächtiges Skript bewusst aufruft. Es genügt, dass eine Werkzeugkette im Hintergrund tut, wofür sie gebaut wurde.

Warum KI-Assistenten den Unterschied machen

KI-Coding-Assistenten – also Werkzeuge, die im Editor Code vorschlagen, Projekte analysieren oder Aufgaben eigenständig abarbeiten – lesen nicht nur Quelltext. Viele von ihnen werten Konfigurationsdateien aus, installieren Abhängigkeiten, führen Build-Schritte aus oder starten Tests, um den Kontext eines Projekts zu verstehen. Je autonomer ein Assistent arbeitet, desto mehr Aktionen laufen ohne gesonderte Rückfrage.

Damit wird die Projektdatei selbst zum Angriffsvektor. Wer Schadcode so platziert, dass er bei einem automatisierten Setup-Schritt anläuft, muss niemanden mehr überreden, etwas anzuklicken. Der Angriff nutzt die Bequemlichkeit, die den Assistenten erst nützlich macht.

Hinzu kommt ein zweiter Effekt: Entwicklerinnen und Entwickler prüfen Repositories häufig erst dann gründlich, wenn der Code tatsächlich in ein Produkt übernommen wird. Der Blick in ein fremdes Projekt zur Recherche, zum Vergleich oder als Vorlage gilt als unkritisch. Genau in diesem Zwischenraum wirkt eine Kampagne, die auf automatische Ausführung setzt.

Tarnung als eigentliches Problem

Gut versteckter Schadcode ist schwer zu finden, weil er sich an Stellen einnistet, die beim Review selten im Mittelpunkt stehen. Niemand liest Build-Konfigurationen mit derselben Aufmerksamkeit wie die Geschäftslogik. Minifizierte oder generierte Dateien werden in Pull Requests oft überflogen. Und ein gekapertes Repository wirkt vertrauenswürdig, solange Name, Historie und Umfeld unverändert aussehen.

Die Wurm-Komponente verschärft das: Wenn kompromittierte Umgebungen ihrerseits Zugangsdaten abgreifen und weitere Projekte oder Pakete infizieren, wächst die Zahl der betroffenen Stellen, ohne dass Angreifer jeden Schritt einzeln steuern müssen. Supply-Chain-Angriffe – also Angriffe über die Lieferkette aus Bibliotheken, Paketen und Werkzeugen – skalieren damit von selbst.

Was Entwicklungsteams konkret ändern sollten

Die Konsequenz ist keine Rückkehr zum manuellen Arbeiten, sondern eine klarere Trennung von Umgebungen und Rechten. Folgende Punkte lassen sich in den meisten Teams ohne großen Umbau umsetzen:

  • Fremden Code isoliert öffnen. Unbekannte Repositories gehören in eine abgeschottete Umgebung, etwa einen Container oder eine virtuelle Maschine ohne Zugriff auf produktive Zugangsdaten.
  • Automatische Ausführung bewusst konfigurieren. Prüfen Sie, welche Aktionen Ihre Editoren, Erweiterungen und KI-Assistenten ohne Rückfrage ausführen dürfen – insbesondere das Installieren von Abhängigkeiten und das Starten von Skripten.
  • Geheimnisse aus der Entwicklungsumgebung entfernen. Tokens, Cloud-Schlüssel und Deployment-Zugänge gehören in einen Secrets-Manager oder in die CI-Pipeline, nicht als Umgebungsvariable auf jeden Arbeitsplatzrechner.
  • Abhängigkeiten festnageln. Lockfiles, fixierte Versionen und ein interner Proxy für Pakete verhindern, dass eine frisch kompromittierte Version unbemerkt in den nächsten Build rutscht.
  • Herkunft prüfen statt Popularität. Sternezahlen und Projektnamen sagen wenig darüber aus, wer aktuell Schreibrechte auf ein Repository besitzt.
  • Zwei-Faktor-Authentifizierung und Rechtevergabe ernst nehmen. Gekaperte Konten sind der übliche Einstieg in fremde Repositories; eingeschränkte Token und regelmäßig geprüfte Zugriffsrechte begrenzen den Schaden.

Reaktionsfähigkeit gehört zur Planung

Ebenso wichtig wie Prävention ist die Frage, was passiert, wenn es doch geschieht. Teams sollten beantworten können, welche Pakete in welcher Version in welchem Projekt stecken, wer zuletzt deployt hat und wie schnell sich Zugangsdaten flächendeckend austauschen lassen. Eine Software-Stückliste, also ein maschinenlesbares Verzeichnis aller verwendeten Komponenten, ist dafür kein Selbstzweck, sondern die Grundlage jeder schnellen Antwort.

Hilfreich ist außerdem eine schlichte organisatorische Regel: Wer einen auffälligen Vorfall bemerkt – ein unerwartetes Skript, einen seltsamen Netzwerkzugriff, eine ungewöhnliche Build-Dauer –, meldet das ohne Rechtfertigungsdruck. Angriffe dieser Art fallen meist durch Kleinigkeiten auf, die einzeln nach Rauschen aussehen.

Produktivität und Kontrolle neu austarieren

KI-Assistenten abzuschalten ist keine realistische Antwort. Sie nehmen Routinearbeit ab und verkürzen Einarbeitungszeiten spürbar. Aber ihr Nutzen entsteht dadurch, dass sie handeln dürfen – und genau diese Handlungsfreiheit muss bewusst zugeschnitten sein. Sinnvoll ist eine Abstufung: volle Automatisierung in bekannten internen Projekten, deutlich engere Grenzen bei allem, was von außen kommt.

Für Web- und Softwareprojekte heißt das: Sicherheit lässt sich nicht mehr allein am Ende der Kette prüfen, sondern beginnt bei der Konfiguration der Arbeitsplätze und der Werkzeuge. Wer KI-gestützte Entwicklung einführt, sollte die Berechtigungen dieser Werkzeuge genauso dokumentieren wie Deployment-Prozesse oder Zugriffsrollen. Und wer Dienstleister beauftragt, tut gut daran, nach Isolation, Abhängigkeitsmanagement und Umgang mit Zugangsdaten zu fragen – denn das Risiko wandert heute über die Lieferkette, nicht über die Firewall.

Quellen