Was ist „Slopsquatting“? Wie durch KI verursachte Paket-Halluzinationen zu Angriffen auf die Lieferkette werden

Wichtigste Erkenntnisse

• Als „Slopsquatting“ bezeichnet man den Vorgang, bei dem ein Angreifer einen von einem KI-Tool erfundenen Paketnamen registriert und darauf wartet, dass jemand dieses Paket installiert.
• Das funktioniert, weil sich Halluzinationen wiederholen, und 43 % traten in allen zehn Wiederholungen der USENIX-Studie erneut auf.
• Ein Repository, das alles ablehnt, was nicht in einem zugelassenen Katalog enthalten ist, verhindert, dass ein frei erfundener Name überhaupt aufgelöst wird.
• Programme, die Abhängigkeiten selbstständig installieren, machen den letzten manuellen Kontrollpunkt überflüssig.

Jemand aus Ihrem Team fügt einen Python-Codeausschnitt aus einem KI-Assistenten ein und führt den Befehl „pip install“ aus, und der Terminal scrollt ohne Fehlermeldung weiter. Der Import funktioniert. Von „Slopsquatting“ spricht man, wenn dieser Paketname zunächst auf nichts verwies, bis ein Angreifer ihn für sich beanspruchte. Das Modell hat ihn erfunden, jemand anderes hat ihn zuerst registriert, und die Installation hat ihm einen Einstiegspunkt verschafft.

Dieser Leitfaden erläutert, was unter „Slopsquatting“ zu verstehen ist, wie die Angriffskette abläuft, welche Erkenntnisse die Forschung tatsächlich darüber liefert, wie häufig dies vorkommt, und welche Abwehrmaßnahmen wirksam sind, bevor der Angriff eine echte Pipeline erreicht.

Was ist „Slopsquatting“?

Slopsquatting ist ein Angriff auf die Software-Lieferkette , bei dem ein Angreifer einen Paketnamen registriert, bei dem große Sprachmodelle häufig Halluzinationen erzeugen, und dann unter diesem Namen bösartigen Code veröffentlicht. Der Entwickler installiert ihn, weil sein KI-Assistent ihm mitgeteilt hat, dass es ihn gibt. Das ist eine Paket-Halluzination: Das Modell empfiehlt eine Abhängigkeit, die nicht in dem Register enthalten ist, auf das es Sie gerade hingewiesen hat.

Der Begriff wurde von Seth Larson, Security Developer-in-Residence bei der Python Software Foundation, geprägt und von Andrew Nesbitt, dem Betreiber der Open-Source-Datenplattform Ecosyste.ms, weiter verbreitet. Er fügt „AI Slop“ an „Typosquatting“. 

Hier hat sich niemand vertippt. Der Installationsbefehl war korrekt, der Name war genau so geschrieben, wie er im Modell angegeben war, und die damit verbundene Sicherheit beruhte auf einem System, das den Namen nie anhand der Registrierung überprüft hat, aus der es ihn empfohlen hat.

Slopsquatting vs. Typosquatting

Typosquatting macht sich menschliche Fehler zunutze. Anfragen statt requests. Oder python3-dateutil, das 2019 auf PyPI hochgeladen wurde, um python-dateutil und wenige Tage später wieder entfernt wurde, nachdem jemand bemerkt hatte, dass es ein zweites Paket einbunden hatte, das SSH- und GPG-Schlüssel sammelte. Slopsquatting nutzt Maschinenfehler aus, und diese Maschinenfehler erweisen sich als weitaus organisierter.

	Typosquatting	Slopsquatting
Was löst die Installation aus?	Ein menschlicher Tippfehler oder ein falsch in Erinnerung gebliebener Name	Eine KI schlägt einen Namen vor, der nicht in der vorgesehenen Namensliste enthalten ist
In einer Studie festgestellte Skala	Konzentriert auf eine Handvoll besonders wertvoller Ziele	205.474 einzigartige halluzinierte Namen wurden beobachtet
Vorhersehbarkeit	Der Angreifer errät mögliche Rechtschreibfehler	Angreifer sammelt Namen, indem er Modelle dazu auffordert
Ähnlichkeit mit echten Namen	Meistens nur eine kleine Änderung vom Original entfernt	13,4 % der Python-Halluzinationen liegen innerhalb einer Bearbeitungsdistanz von 1–2 zum nächstgelegenen echten Paket; 48,6 % sind sechs oder mehr Bearbeitungsschritte entfernt
Wer ist gefährdet?	Entwickler und automatisierte Arbeitsabläufe zur Behebung eines falschen Namens	Jeder, der von KI generierte Abhängigkeitslisten akzeptiert – einschließlich Agenten

Viele der erfundenen Namen haben mit einem echten Paket nicht das geringste zu tun. Nur 13,4 % der erfundenen Python-Namen lagen innerhalb von einem oder zwei Zeichen vom nächstgelegenen existierenden Namen entfernt, während 48,6 % sechs oder mehr Änderungen davon entfernt waren. Es handelt sich hierbei eher um plausibel klingende Erfindungen als um Beinahe-Treffer, weshalb sie bei Überprüfungen der Änderungsdistanz und der Namensähnlichkeit so häufig übersehen werden.

Auch die Namen tauchen immer wieder auf. Die USENIX-Forscher nahmen 500 Eingabeaufforderungen, die Halluzinationen hervorgebracht hatten, und führten jede davon zehnmal erneut aus. 43 % der halluzinierten Namen tauchten in allen zehn Durchläufen auf, und 58 % tauchten mehr als einmal auf. Ein Angreifer muss nicht raten. Diese Wiederholung ist der eigentliche Unterschied zum klassischen Typosquatting, bei dem der Angreifer vorhersagt, wie Menschen sich vertippen, anstatt zu messen, was ein Modell zuverlässig erfindet.

So funktioniert ein Slopsquatting-Angriff

Vier Schritte, von denen keiner technisch anspruchsvoll ist – was mit ein Grund dafür ist, warum durch KI erzeugte Pakete einen so effizienten Übertragungsmechanismus darstellen. Ein erfolgreicher Versuch entspricht MITRE ATT&CK T1195.001, „Compromise Software Dependencies and Development Tools“, und fällt somit in ein Bedrohungsmodell, das Sie bereits kennen, anstatt als etwas Exotisches abseits davon zu stehen.

1. Die Halluzinationen ernten

Der Angreifer führt in großem Umfang Befehle zur Codegenerierung aus, sammelt alle Paketnamen aus der Ausgabe und gleicht jeden einzelnen mit PyPI oder npm ab. Namen, die nicht aufgelöst werden können, werden in die Liste aufgenommen. Namen, die auch bei wiederholten Durchläufen desselben Modells nicht aufgelöst werden können, werden an den Anfang der Liste gesetzt.

Eine Erkenntnis verdient es, genauer betrachtet zu werden. In der USENIX-Studie waren die halluzinierten Namen weitaus häufiger modellspezifisch als modellübergreifend: 81 % der einzigartigen Namen stammten von genau einem der 16 getesteten Modelle. Häufigkeit und Überschneidungen variieren je nach Modell. Daher ist es sinnvoll, die Assistenten zu messen, die Ihr eigenes Team tatsächlich nutzt, anstatt davon auszugehen, dass eine gemeinsame Blacklist ausreicht.

Messungen im Forschungsmaßstab sind nicht billig, müssen es aber auch nicht sein. Das USENIX-Team erzeugte 576.000 Code-Beispiele für 16 Modelle , um zwei Sprachen und einen breiten Satz an Prompts abzudecken. Der Umfang, der erforderlich ist, um ein Framework, ein Cloud-SDK oder einen intern anmutenden Anwendungsfall zu untersuchen, stellt ein anderes und wesentlich kleineres Problem dar.

Die Modellwahl spielte bei den Modellen, die im Rahmen der Studie Anfang 2024 getestet wurden, eine große Rolle: Open-Source-Modelle wiesen im Durchschnitt eine Halluzinationsrate von 21,7 % auf, während diese bei den kommerziellen Modellen bei 5,2 % lag. Ein Preprint aus dem Jahr 2026, in dem dieselbe Methodik auf fünf neuere Pioniermodelle angewendet wurde, , ergab Gesamtquoten zwischen 4,62 % und 6,10 %. Da er noch nicht einem Peer-Review unterzogen wurde, sollte man ihn eher als frühes Anzeichen denn als feststehenden Trend betrachten. Die erfundenen Namen haben sich in keiner Weise verändert.

Insider-Tipp: Plausible Endungen wie -utils, -helpers, -clientund -sdk können einen erfundenen Namen auf den ersten Blick glaubwürdig erscheinen lassen. Betrachten Sie eine vernünftig anmutende Namenskonvention als Anlass zur Überprüfung, niemals als Beweis dafür, dass ein Paket echt ist.

2. Den Namen registrieren und ihn lebendig wirken lassen

Der Angreifer registriert die besten Namen und veröffentlicht etwas, das funktioniert: funktionsfähigen Code, der in etwa das tut, was der Name vermuten lässt, eine README-Datei und eine Lizenz, die sich normal liest.

Die Payload befindet sich im Installationspfad oder in einem Import, der selten aufgerufen wird. Ein Installations-Hook, der bei seiner Ausführung eine ausgehende Anfrage sendet, oder Code, der sich auf einem Laptop anders verhält als an einem Ort mit wertvollen Anmeldedaten und Netzwerkzugang. Harmlos wirkende Funktionen verschaffen Zeit, gerade weil der erwartete Import scheinbar funktioniert.

Die Download-Zahlen sprechen eine deutlichere Sprache als jedes hypothetische Beispiel. Lasso Security verzeichnete ein leeres Paket unter dem erfundenen Namen „huggingface-cli“ und verzeichnete über drei Monate hinweg mehr als 30.000 Downloads, darunter ein Forschungs-Repository von Alibaba, in dessen README die Nutzer zur Installation aufgefordert wurden. Ein harmloser Proof-of-Concept ohne jegliche Schadfunktion wurde dennoch in echten Entwicklungsartefakten referenziert.

3. Ein Entwickler installiert es auf Anweisung der KI

Die Installation selbst ist unspektakulär. Jemand fragt einen Kollegen, wie man etwas macht, erhält einen Code, der funktionsfähig aussieht, und führt den dazugehörigen Befehl aus.

pip install PACKAGE_NAME

Ohne Registrierungsprüfungen oder Endpunktwarnungen wird keine Warnung ausgelöst. Das Paket wird aufgelöst, installiert und importiert. Wenn der Entwickler etwas überprüft, dann nur, ob der Import funktioniert – was auch der Fall ist.

Das Vertrauen in das Modell überträgt sich auch hier. Ein Paketname, der in ansonsten korrektem Code vorkommt, profitiert von der Glaubwürdigkeit dieses Codes, und in einem schnell arbeitenden Team erhält eine neue Abhängigkeit, die im Rahmen einer ansonsten routinemäßigen Änderung eingeführt wird, weniger Aufmerksamkeit als die umgebende Logik – es sei denn, bei der Überprüfung werden hinzugefügte Abhängigkeiten ausdrücklich aufgezeigt. Eine Person muss den Vorschlag immer noch lesen und sich entscheiden, ihn auszuführen. Wenn ein Agent Abhängigkeiten installieren darf und keine Genehmigungshürde im Weg steht, liest niemand den Vorschlag überhaupt.

4. Es bleibt über alle Builds und CI-Durchläufe hinweg erhalten

Sobald der Name in der requirements.txt oder package.jsonsteht, ist es keine Entscheidung mehr, sondern wird zur Infrastruktur. Builds, die anhand dieses Manifests installiert werden, beziehen es ein. Neue Container-Images integrieren es. Jede Umgebung, die diese Abhängigkeit auflöst, erbt sie – von Laptops über CI-Runner bis hin zu Build-Systemen, die Deployment-Token und Registry-Zugangsdaten verwalten.

Die transitive Ausbreitung verschlimmert die Situation noch. Wenn das kompromittierte Paket als Abhängigkeit einer internen Bibliothek eingebunden wird, gelangt es zu Diensten, deren Betreuer den ursprünglichen Vorschlag gar nicht gesehen haben. Dann geht es bei der Überprüfung nicht mehr darum, wer es installiert hat, sondern darum, wo es letztendlich gelandet ist.

Die Folgen sind die üblichen Risiken bei jeder kompromittierten Abhängigkeit: Diebstahl von Anmeldedaten, Cryptomining, unerwarteter ausgehender Datenverkehr oder eine umfassendere Kompromittierung aller Elemente, auf die die Build-Umgebung Zugriff hat, einschließlich Linux-Hosts.

Achtung: Lockfiles kennzeichnen das schädliche Paket genauso zuverlässig wie ein legitimes. Ein Lockfile garantiert die Reproduzierbarkeit; es sagt nichts darüber aus, was darin gesperrt wurde. Es reproduziert die Kompromittierung auf jedem Host, auf dem daraus installiert wird, bis die Abhängigkeit und ihr Lockfile-Eintrag gezielt entfernt werden.

Was die Forschung zeigt

Diese Zahlen stammen aus „We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs“, vorgestellt auf der USENIX Security 2025. Es handelt sich um die groß angelegte Studie, auf die sich letztendlich alle anderen in diesem Bereich berufen, und jede Zahl in der folgenden Tabelle geht direkt auf diese Studie zurück und nicht auf eine Zusammenfassung aus zweiter Hand.

Ergebnis	Abbildung
Vorgestellte Paketempfehlungen	440.445 von 2,23 Millionen (19,7 %)
Beobachtete einzigartige, halluzinierte Namen	205,474
Halluzinationsrate bei Open-Source-Modellen	21.7%
Halluzinationsrate bei kommerziellen Modellen	5.2%
In allen 10 Wiederholungen traten die Halluzinationen erneut auf	43%
Halluzinationen, die sich nie wiederholten	39%
Python-Halluzinationen als npm-Pakete verfügbar	8.7%

Drei Dinge sind hier wichtiger als die in der Überschrift genannte Prozentzahl.

Wiederholung ist der Schlüssel zum Erfolg für Angreifer. 43 % der halluzinierten Namen tauchten in allen zehn Wiederholungen erneut auf, und 58 % tauchten mehr als einmal auf, womit der Großteil davon nicht mehr als einmaliges Rauschen angesehen werden kann. Gerade diese Wiederholbarkeit macht das „Harvesting“ für Angreifer lohnenswert.

Die Zahl der systemübergreifenden Nennungen ist es, die viele Menschen in die Irre führt. 8,7 % der fiktiven Python-Namen waren gültige npm-Pakete, sodass ein Entwickler, der prüft, ob ein Name irgendwo existiert, ein grünes Licht erhält, das nichts aussagt. Die Existenz in einer anderen Registry ist kein Beweis dafür, dass es sich um die gewünschte Abhängigkeit handelt.

Die Verteilung nach Sprachen verschiebt sich. Bei den Modellen aus dem Jahr 2024 in der USENIX-Studie lag der Anteil von JavaScript bei 21,3 %, während Python auf 15,8 % kam. Der Preprint aus dem Jahr 2026 berichtete, dass sich dieses Verhältnis bei den fünf neueren Modellen umgekehrt habe. Betrachten Sie dies als eine Eigenschaft des jeweiligen Modells und nicht als eine Eigenschaft der Sprache.

Warum KI-Agenten den Einsatz erhöhen

 

Schritt 3 oben geht davon aus, dass jemand einen von der KI vorgeschlagenen Code liest, bevor er ihn ausführt. Mit agentenbasierten Tools lässt sich diese Annahme umgehen. Ein Agent, der einen Fehler liest, feststellt, dass eine Abhängigkeit fehlt, und diese installiert, hat den Kreislauf geschlossen – und ohne Vorschau, Richtlinienprüfung oder Genehmigungsstufe gelangt der Paketname auf die Festplatte, bevor ihn jemand zu Gesicht bekommt.

Tests von Anbietern deuten darauf hin, dass sich die Tools zwar verbessern, das Problem jedoch nicht lösen. Die „Slopsquatting“-Untersuchung von Trend Micro ergab, dass Programmieragenten mit „Chain-of-Thought“-Logik und Live-Websuche die Halluzinationsrate in der Bewertung um etwa die Hälfte senkten, wobei die Konfigurationen mit Live-Validierung von allen die wenigsten Phantomabhängigkeiten erzeugten. Dennoch gelangten weiterhin Namen durch. Trend Micro führt die verbleibenden Fehler auf das Ausfüllen von Kontextlücken, die Nachahmung von Oberflächenformen und die ökosystemübergreifende Übernahme von Namen zurück, wobei der Agent etwas zusammenstellt, das den Konventionen echter Pakete folgt, ohne einem davon zu entsprechen.

Eine Reduzierung um 50 % ist beachtlich. Das ist keine Kontrollmaßnahme, die man einem Wirtschaftsprüfer einfach so übergeben kann.

Dann gibt es noch das sogenannte „Vibe-Coding“, womit hier gemeint ist, KI-generierten Code schnell zu akzeptieren, ohne dessen Abhängigkeiten oder deren Verhalten bei der Installation eigenständig zu überprüfen. Die sicherere Voreinstellung ist das Gegenteil davon: Jede von der KI vorgeschlagene Abhängigkeit eines Drittanbieters bleibt ungeprüft, bis eine andere Quelle als das Modell das Paket und die Version bestätigt. Kombiniert man diese Lücke mit Agenten, die sich selbstständig installieren, entfällt der Überprüfungs-Checkpoint gänzlich.

So schützen Sie sich vor Slopsquatting

Keine einzelne Kontrollmaßnahme deckt dies auf. Die Verifizierung deckt die offensichtlichen Fälle auf, die Festlegung von Grenzwerten begrenzt den Auswirkungsbereich, eine durchgesetzte Zulassungsliste schließt den Auflösungsweg ab, und die Richtlinien für Scans und Überprüfungen sorgen dafür, dass die ersten drei Maßnahmen ordnungsgemäß funktionieren. Setzen Sie sie gemeinsam ein.

Wenn Ihre Builds direkt aus öffentlichen Registries bezogen werden, ist die Whitelist in Verteidigungsmaßnahme 3 ausschlaggebend für die Art des Problems. Falls Sie bereits einen internen Mirror betreiben, sollten Sie zunächst prüfen, ob dieser eine Whitelist durchsetzt oder lediglich alles zwischenspeichert, was ihm übermittelt wird, denn ein uneingeschränkter Pull-Through-Cache lässt diese Sicherheitslücke im Wesentlichen unverändert bestehen.

1. Überprüfen Sie, ob das Paket vorhanden ist und eine Historie aufweist.

Bevor ein von der KI vorgeschlagenes Paket in ein Manifest aufgenommen wird, sollten Sie überprüfen, wann es erstmals veröffentlicht wurde, wer es pflegt, ob das dahinterstehende Repository echt und aktiv ist und ob das Artefakt in der Registry mit dieser Quelle übereinstimmt. Die Daten zur Veröffentlichung und zum Betreuer stammen direkt aus den Metadaten der Registry, ohne dass etwas installiert oder Paketcode ausgeführt werden muss.

curl -s https://pypi.org/pypi/PACKAGE_NAME/json

npm view PACKAGE_NAME time.created maintainers

Die Übernahme erfolgt über eine separate Abfrage. Der JSON-Endpunkt von PyPI gibt in den Download-Feldern den Wert -1 zurück. Beziehen Sie diese Daten daher aus pypistats oder dem BigQuery-Datensatz, falls das Download-Volumen Teil Ihres Diagramms ist. Auch die Authentizität des Repositorys und die Übereinstimmung zwischen Quelle und Artefakt müssen separat überprüft werden; ein Registry-Link allein sagt nichts darüber aus, wem das entspricht, worauf er verweist.

Legen Sie die Maßstäbe als Richtlinie fest und verlassen Sie sich nicht auf Ihr Bauchgefühl. Alter, Übernahme, Identität des Betreuers, überprüfte Übereinstimmung zwischen Quelle und Artefakt. Diese vier Faktoren decken offensichtliche Unstimmigkeiten auf, bevor eine Abhängigkeit in den Graphen aufgenommen wird – doch ein gut konstruiertes bösartiges Paket kann dennoch alle diese Prüfungen bestehen. Es handelt sich um Anhaltspunkte für die Überprüfung, nicht um einen Nachweis der Sicherheit.

2. Abhängigkeiten mit Lockfiles und Hashes festlegen

Lockfiles gewährleisten die Reproduzierbarkeit. Hashes gewährleisten die Integrität: Vorausgesetzt, der Hash wurde im Rahmen eines von Ihnen als vertrauenswürdig eingestuften Prozesses ermittelt und geschützt, bestätigen sie, dass das von Ihnen installierte Artefakt tatsächlich das von Ihnen genehmigte Artefakt ist.

pip install –require-hashes -r requirements.txt

Der Hash-Check-Modus funktioniert nach dem Alles-oder-Nichts-Prinzip. Jede Anforderung und jede transitive Abhängigkeit muss mit == festgelegt und mit einem Hash versehen werden, sonst schlägt die Installation sofort fehl. Rechnen Sie also damit, dass der erste Durchlauf mühsam sein wird. Was das Festlegen jedoch nicht leistet, ist die Gewissheit, dass das festgelegte Element jemals sicher war. Die Registrierungsdaten von npm sind unveränderlich, sodass ein bestimmter Name und eine bestimmte Version auch nach einer Rücknahme nicht erneut veröffentlicht werden können; realistisch gesehen besteht das Risiko darin, am ersten Tag das falsche Paket zu genehmigen und festzulegen. Deshalb sollte das Festlegen erst nach der Überprüfung erfolgen und nicht an deren Stelle treten.

Die Ausführung von Skripten bei der Installation ist ein separater Hebel, und npm hat ihn bereits betätigt. Das aktuelle npm blockiert standardmäßig Installationsskripte für Abhängigkeiten und überspringt Lebenszyklus-Skripte für alle Elemente, für die kein entsprechender Eintrag in `allowScripts` und listet am Ende der Installation auf, was übersprungen wurde. npm install-scripts approve sowie npm install-scripts deny pflegen diese Liste, wobei die Genehmigungen an die Version gebunden sind, die Sie tatsächlich geprüft haben.

npm ci –ignore-scripts

Bei älteren npm-Versionen ist dieses Flag die „grobe“ Variante desselben Konzepts, allerdings ohne die Zulassungsliste. In beiden Fällen gilt dies nur für die Installationsphase. Code, der beim Import, beim Erstellen oder zur Laufzeit ausgeführt wird, bleibt davon unberührt.

3. Beziehe Informationen ausschließlich aus einer sorgfältig ausgewählten Quelle

Die wirksamste strukturelle Maßnahme besteht darin, zu ändern, worauf ein Name aufgelöst werden kann. Ein Repository, das alles ablehnt, was nicht in einem genehmigten Katalog enthalten ist, schlägt die Auflösung eines erfundenen Namens fehl – und das ist die kostengünstigste Stelle in der gesamten Kette, an der ein Fehler auftreten kann.

Diese Eigenschaft ergibt sich aus der Zulassungsliste und nicht aus dem kuratierten Repository. Viele private Registries stellen geprüfte Builds für die von ihnen abgedeckten Pakete bereit und leiten alles andere vom Upstream weiter, wodurch die ursprüngliche Sichtbarkeit für jeden Namen außerhalb der abgedeckten Menge erhalten bleibt. Es lohnt sich, dies zu überprüfen, bevor man davon ausgeht, dass ein Mirror geschlossen wurde.

SecureChain von TuxCare wurde speziell für die unterstützten Sprachen entwickelt. Es umfasst sechs Ökosysteme – JavaScript, Python, Java, Go, Rust und PHP –, die alle aus demselben kuratierten Katalog bereitgestellt werden. Der Zeitplan für die Einführung variiert je nach Ökosystem leicht, und eines oder mehrere davon befinden sich möglicherweise noch in der Vorbereitungsphase. Wenn Sie den aktuellen Status für einen bestimmten Stack benötigen, senden Sie bitte eine E-Mail an [email protected].

Pakete werden aus dem Quellcode in abgesicherten, isolierten Umgebungen neu kompiliert, auf bekannte Malware und verdächtige Codemuster überprüft und im Rahmen eines SLA gepatcht, sobald CVEs bekannt werden, wobei SLSA-Level-3-Herkunftsnachweise sowie SBOM- und VEX-Daten zur Verfügung stehen. Richten Sie Ihren Paket- oder Repository-Manager auf die TuxCare-Registrierung aus, und die neu generierte Lockfile-Datei speichert TuxCare-URLs und Prüfsummen anstelle öffentlicher Tarballs. Laut der Dokumentation von TuxCare stellt diese Registrierung über denselben Endpunkt SecureChain-Builds bereit, sofern vorhanden, und ansonsten öffentliche Upstream-Pakete; die Garantie gegen Slopsquatting ergibt sich also aus der Allowlist, die Sie zusätzlich anwenden, und nicht allein aus dem Wechsel der Registrierung.

4. Verhalten bei neuen Abhängigkeiten analysieren und beobachten

Das Scannen nach Signaturen und Reputationen funktioniert am besten bei Bedrohungen, die bereits identifiziert wurden. Ein gerade erst registriertes schädliches Paket ist noch nicht in diesen Datenbanken erfasst, und genau dieses Zeitfenster nutzt Slopsquatting aus.

Verhaltensprüfungen schließen diese Lücke. Unerwartete Netzwerkzugriffe während der Installation, verschleierter oder minimierter Quellcode in einem Paket, das eigentlich im Klartext vorliegen sollte, das Auslesen von Anmeldedaten und Umgebungsvariablen sowie Schreibvorgänge außerhalb des Paketverzeichnisses. Viele legitime Pakete weisen ein oder zwei dieser Merkmale auf, insbesondere Builds mit nativen Modulen. Daher besteht die Aufgabe darin, diese zur Überprüfung hervorzuheben, anstatt sie automatisch zu blockieren.

Überprüfen Sie Änderungen an den Abhängigkeiten in der CI, bevor sie zusammengeführt werden, und führen Sie zusätzlich regelmäßig eine geplante Neuüberprüfung durch. Die erste Überprüfung erfasst die von Ihnen hinzugefügten Elemente; die zweite erfasst das Paket, das bei der Einbindung noch einwandfrei war, drei Wochen später jedoch nicht mehr.

Expertentipp: Führen Sie bei jedem Pull-Request eine Differenzanalyse des Abhängigkeitsmanifests durch und verlangen Sie eine explizite Freigabe für Ergänzungen, unabhängig von der Code-Review. Die Trennung von Änderungen an den Abhängigkeiten von allgemeinen Code-Änderungen sorgt dafür, dass die Überprüfung der Lieferkette sichtbar genug ist, um darauf zu bestehen.

5. Erstellen Sie Richtlinien für die Überprüfung von KI-generiertem Code

Tools beheben keine Prozesslücken. Legen Sie schriftlich fest, was geschieht, wenn ein KI-Tool eine Abhängigkeit vorschlägt.

Eine praktikable Richtlinie behandelt jedes von der KI vorgeschlagene Paket als nicht vertrauenswürdig, bis eine Person es den Prüfungen aus „Maßnahme 1“ unterzogen hat, und genehmigt neue Abhängigkeiten anhand von Name und Version und nicht allein aufgrund eines erfolgreichen Builds. Agenten erhalten keinen ungeprüften Schreibzugriff auf Abhängigkeitsmanifeste; Ergänzungen und Versionsänderungen durchlaufen ein Genehmigungsverfahren. Die genehmigte Quellenliste wird auf der Ebene des Paketmanagers oder der Repository-Richtlinien durchgesetzt, sodass ein Verstoß gegen die Richtlinie als Build-Fehler und nicht als Vertrauensproblem erscheint.

Was sich durch TuxCare SecureChain bei der Installation ändert

Slopsquatting funktioniert, weil ein Installationsbefehl einen Namen, den niemand überprüft hat, ohne Weiteres auflöst. SecureChain verändert das Ergebnis, das man erhält, wenn ein solcher Name aufgelöst wird. Pakete im Katalog werden aus verifizierten Quellen neu kompiliert und vor der Bereitstellung auf bekannte Malware und verdächtige Muster überprüft; außerdem werden sie auch dann weiterhin gepatcht, wenn die Upstream-Betreuer das Projekt nicht mehr betreuen. Damit wird das Problem der kompromittierten Abhängigkeiten gelöst, das direkt neben dem Problem der halluzinierten Namen liegt.

Setzen Sie zusätzlich eine Zulassungsliste durch, damit der Build nicht über diesen Katalog hinausgelangen kann und ein erfundener Name überhaupt nichts hat, von dem aus er installieren könnte – unabhängig davon, ob ein Angreifer bereits zuvor dort vorgelangt ist oder nicht.

Erfahren Sie auf der SecureChain für OSS-Seite, oder stellen Sie uns eine Frage zu Ihrer spezifischen Umgebung.

FAQs