ChainDrop: gültige Provenienz in 400+ npm-Paketen und Claude Code Hooks, die keine npm-Installation benötigen

Am 4. August 2026 haben Angreifer das GitHub-Konto von keyv übernommen, einer Caching-Bibliothek, die laut Elastic Security Labs im Vormonat mehr als 600 Millionen Mal heruntergeladen wurde. Wiz Research und Orca Security halten beide fest, dass schädliche Dateien direkt in den main-Branch von keyv gepusht wurden und dass der eigene GitHub-Actions-Workflow des Projekts anschließend den vergifteten Release erstellte und veröffentlichte — sodass er npm mit gültiger Provenienz erreichte, die das Supply-Chain-Attestierungs-Tooling verwendet, um zu entscheiden, ob ein Paket vertrauenswürdig ist. Ein selbstverbreitender Wurm, den Forscher ChainDrop nennen, verwendete dann gestohlene npm-Token, um den Trick bei den Paketen anderer Maintainer zu wiederholen: Elastic zählte bis zum 6. August mehr als 400 einzelne Pakete, Microsoft Threat Intelligence beschrieb dieselbe Kampagne am 4. August, und die Cyber Security Agency Singapurs zählte über 1.300 kompromittierte Paketversionen mit insgesamt 2 Milliarden monatlichen Downloads. Elastic und Microsoft beschreiben beide Hooks, die erneut ausgeführt werden, wenn ein Repository in Claude Code oder Visual Studio Code geöffnet wird. Die vollständige Quellenliste, die Schweregrad-Einstufung und die Konfidenzbewertung des Eintrags befinden sich in dem Archiv für KI-Vorfälle, neben den anderen Einträgen zur Supply Chain von npm und Entwickler-Tooling, die in seinem Umfeld erfasst wurden.

Wie eine legitime Release-Pipeline ihre eigene Kompromittierung signierte

Wiz Research rekonstruiert die ersten Minuten: von 09:00 UTC am 4. August nutzte der Angreifer eine kompromittierte Identität, um IDE-Persistenz-Payloads in das keyv-Repository einzuschleusen, und veröffentlichte kurz darauf eine neue Version von keyv, die die Payload enthielt. Wiz nennt als kompromittierte Partei ein GitHub-Maintainer-Konto und erklärt, dass mehrere Pakete im keyv- und cacheable-Ökosystem folgten.

Der Rapid-Response-Bericht von Orca Security geht detaillierter auf den Signaturpfad ein. Der Angreifer, so heißt es, hat zwei bösartige Dateien — setup.mjs und Math_Symbol.js — direkt in den Hauptzweig gepusht und unmittelbar neue Releases erstellt. Da diese Releases über die GitHub-Actions-Workflows des kompromittierten Kontos gebaut wurden, wurden die vergifteten Versionen bei npm veröffentlicht, und zwar mit gültigen Provenienzsignaturen, wodurch die standardmäßigen Integritätsprüfungen der Lieferkette umgangen wurden. Zscaler ThreatLabz, ein unabhängiges Forschungsteam, das nicht zu den in dem Bericht zitierten Quellen gehört, kommt zum selben Schluss und gibt dafür eine Stufe an: Das bösartige Paket keyv 6.0.0 trug gültige SLSA Build Level 3 Provenienz, weil der Angreifer das Quellrepository kontrollierte. BleepingComputer, das noch am Tag über die Kampagne berichtete, dokumentiert denselben Mechanismus — bösartige Dateien direkt in die Hauptzweige der Projekte gepusht, neue Releases erzeugt, gültige Provenienz, weil die Builds über legitime GitHub-Actions-Workflows liefen.

Microsofts Analyse ergänzt ein Detail, das wie ein Widerspruch aussieht und keiner ist. In der Ausbreitungsphase des Worms stellte Microsoft Threat Intelligence fest, dass viele bösartige Versionen keinen entsprechenden Source-Code-Commit, Pull Request, Tag oder legitime Veröffentlichung aufwiesen, was darauf hindeutete, dass die Angreifer Paket-Tarballs direkt veränderten und veröffentlichten, statt jedes öffentliche Quell-Repository zu kompromittieren. Zusammengelesen beschreiben die Quellen zwei Signaturregime innerhalb einer Kampagne: Die ersten keyv-Releases durchliefen die echte CI-Pipeline des Opfers und tragen Attestierungen, die dies bestätigen, während die späteren Releases des Worms größtenteils mit gestohlenen Registry-Tokens zusammengestellt und veröffentlicht wurden, sodass keinerlei Quellspur zurückblieb. Microsofts eigene Beobachtung ist, dass das Tarball-direkt-Muster erklärt, warum bösartige Releases häufig als gewöhnliche Patch-Versionserhöhung ohne entsprechende Source-Commits oder Pull Requests erschienen.

Die unbequeme Lehre wird von Zscaler klar benannt: Provenienz validiert den Build-Prozess, nicht die Identität des Kontos oder die Integrität des CI-Systems, das ihn ausführt. Zscaler räumt außerdem eine Lücke ein, die für jeden relevant ist, der den Vorfall rekonstruiert – der genaue Mechanismus der Kontoübernahme, den der Angreifer nutzte, war zum Zeitpunkt der Analyse unbekannt.

Was bei npm install läuft: preinstall, Bun 1.3.13 und ein Collector mit 300 Mustern

Elastic Security Labs beschreibt den Auslöser als einen preinstall-Hook in package.json, der eine legitime npm-Funktion missbraucht, die beliebige Befehle ausführt, bevor ein Paket die Installation abschließt, und keine weitere Interaktion des Opfers erfordert. Der Hook startet setup.mjs, das prüft, ob die Bun-JavaScript-Laufzeit bereits vorhanden ist. Ist sie nicht vorhanden, ermittelt der Dropper Plattform und Architektur des Rechners und lädt Bun v1.3.13 von der offiziellen Release-Seite herunter, entpackt es, nutzt es, um die Payload auszuführen, und löscht anschließend das temporäre Verzeichnis, um seine Spuren zu verwischen. Wiz identifizierte unabhängig den User-Agent Bun/1.3.13, der die bösartigen Aufrufe ausführt. Der Dropper ist plattformübergreifend und zielt auf Linux, macOS und Windows ab.

Die Payload ist stark obfuskiert, und die Quellen unterscheiden sich leicht hinsichtlich ihrer Größe: Elastic gibt sie mit 711 Kilobyte an, Orca Security mit 728 KB. Sie verwendet Control-Flow-Flattening und ein Base91-Stringkodierungsschema und enthält Dune-thematische Strings – laza, kanly, ghola, mentat, lasgun, sietch, fedaykin, tleilaxu, sandworm, sardaukar, ornithopter, navigator – von denen Elastic anmerkt, dass sie Ähnlichkeiten mit früheren Shai-Hulud-Kampagnen aufweisen.

Microsofts Verhaltensbericht ergänzt zwei nützliche Details. Die Payload prüft zuerst ihre Umgebung und beendet sich auf russischsprachigen Systemen, vermeidet doppelte Instanzen und startet auf Entwickler-Workstations eine abgekoppelte Hintergrundkopie; innerhalb von CI bleibt sie am aktiven Job angehängt, sodass sie Workflow-Secrets, Runner-Anmeldedaten und OpenID-Connect-Veröffentlichungsberechtigungen erreichen kann.

Der Collector ist der Punkt, an dem der Vorfall zu einer KI-Tooling-Geschichte statt zu einer allgemeinen Credential-Geschichte wird. Elastic gibt an, er scannt über 300 eindeutige Muster in Credential-Speichern auf einem Entwicklerrechner, wobei die bemerkenswerte Zielausrichtung gerichtet ist auf KI-Tooling-Zugangsdaten: Anthropic, Claude, Codex, Cursor, OpenAI und Gemini. Außerdem erfasst er AWS-, GCP-, Azure- und Alibaba-Cloud-Zugangsdaten, GitHub-Personal-Access-Tokens, JWT- und Session-Tokens, HashiCorp-Vault-Tokens, private SSH-Schlüssel, Kubernetes-Service-Account-Tokens und npm-Tokens. Wiz berichtet, dass die Zielliste im Vergleich zum früheren Mini Shai-Hulud-Code, auf dem er basiert, um fast 70 % erweitert wurde, wobei neue Ergänzungen KI-Agent-Credential-Speicher für Claude, OpenAI, Codex, Cursor und Gemini, Kryptowährungs-Keystores für Foundry, Solana und Monero, Jenkins' master.key, Argo-CD- und Harbor-Secrets, Alibaba- und Tencent-CLI-Konfigurationen sowie /etc/shadow.

Sowohl Microsoft als auch Elastic beschreiben dasselbe Exfiltrationsdesign. Ergebnisse werden als JSON serialisiert, gzip-komprimiert und mit einem zufällig generierten AES-256-GCM-Schlüssel verschlüsselt, und dieser Schlüssel wird mit dem öffentlichen RSA-Schlüssel des Angreifers verpackt. Die Payload hardcodet ihre Command-and-Control-Domain nicht: Elastic zufolge fragt sie einen Ethereum-Smart-Contract unter 0xE1f2395ee43e45A1556EC6438a88c31B83493103 ab, um den aktuellen Endpunkt zur Laufzeit abzurufen, sodass die Infrastruktur rotiert werden kann, ohne die Malware anzufassen. Wenn das fehlschlägt, sucht sie nach einer kryptografisch signierten Markierung – thebeautifulmarchoftime – in der GitHub-Commit-Historie und validiert die Domain gegen einen eingebetteten RSA-Schlüssel. Wenn beides fehlschlägt, exfiltriert sie über ein öffentliches GitHub-Repository, das das Konto des Opfers selbst erstellt, beschrieben als "Shai-Hulud: Here We Go Again". Microsoft merkt an, dass ein Fallback-Pfad ein gestohlenes GitHub-Token mit doppeltem Base64 kodiert, statt es zu verschlüsseln.

Die Ausbreitung hängt von der Token-Qualität ab. Elastic berichtet, dass der Wurm nur aktiv wird, wenn der Zugangsdaten-Sweep ein npm-Token mit Schreibberechtigung für Pakete und der Möglichkeit, ohne Zwei-Faktor-Authentifizierung zu veröffentlichen, findet; anschließend lädt er die neueste Tarball-Datei jedes beschreibbaren Pakets herunter, injiziert sich selbst, erhöht die Patch-Version und veröffentlicht es erneut. BleepingComputer ergänzt, dass jedes Token in Echtzeit gegen den whoami-Endpunkt der Registry validiert wird, bevor es gestohlen wird. Diese Routine hat aus einer einzigen kompromittierten Identität Hunderte Releases gemacht, und sie ist der Grund dafür, dass die bösartigen Versionen wie gewöhnliche Patch-Versionssprünge aussehen.

Der Infektionspfad, für den kein npm install nötig ist

Der Befund, der diese Kampagne von früheren npm-Würmern unterscheidet, ist, dass die Installation nicht mehr der einzige Einstiegsweg ist. Elastic beschreibt zwei zusätzliche Ausführungspfade, die auf Nutzer von KI-Programmierwerkzeugen abzielen. Ein SessionStart Hook in .claude/settings.json führt node .claude/setup.mjs aus, wenn eine neue Claude-Sitzung startet. Für VS Code gilt: Ein folderOpen Task in .vscode/tasks.json führt node .vscode/setup.mjs aus, wenn ein infiziertes Repository geöffnet wird. Microsofts Analyse listet dieselben vier Artefakte auf – .claude/settings.json, .claude/setup.mjs, .vscode/tasks.json und .vscode/setup.mjs – und beschreibt sie als einen sekundären Infektionsweg, der die Payload erneut starten kann, nachdem die ursprüngliche npm-Installation abgeschlossen ist.

Die Bedingung, die dies dramatisch ausweitet, liegt in den gestohlenen Zugangsdaten. Wenn ein GitHub-App-Token unter ihnen ist, berichtet Elastic, dass der Wurm die bösartigen Hooks in bis zu 50 Branches pro zugänglichem Repository committet und dabei .claude/settings.json und .vscode/tasks.json in jeden einzelnen injiziert. Elastics Schlussfolgerung ist, dass ein Entwickler, der einen dieser Branches klont und öffnet, durch das Öffnen des Projekts infiziert werden kann — ohne Paketinstallation und damit ohne jeglichen Install-Skript-Schutz im gesamten Ablauf.

Zscalers Einschätzung ist, dass die Persistenz-Hooks die Paketentfernung überleben und sich einfach durch Öffnen des Projekts in VS Code oder Claude Code erneut ausführen, wodurch die --ignore-scripts-Maßnahme, die viele Teams nach früheren npm-Würmern übernommen haben, umgangen wird. Seine Empfehlung folgt direkt daraus: IDE- und KI-Agent-Konfigurationsdateien — .claude/, .cursor/, .vscode/, .gemini/ — als ausführbaren Code zu behandeln, der mit derselben Sorgfalt wie Quellcode geprüft wird.

Es gibt einen Fingerabdruck für die Repository-Hälfte des Angriffs. Elastic berichtet, dass vom Wurm erzeugte Commits am Autorennamen claude und an der Commit-Nachricht chore: update config identifiziert werden können, und Wiz verzeichnet dieselbe Nachrichtenzeichenfolge. Elastic ergänzt, dass die Commit-Nachricht neben einer Einschüchterungszeichenfolge auch das gestohlene GitHub-Token enthielt – IfYouBlockThisAPIKeyItWillCrashTheLiveProductionServersOfAllThirdPartyClients – was es als Versuch deutet, Entwickler davon abzuschrecken, das Token zu widerrufen. Wiz verzeichnet dieselbe Zeichenfolge in den ursprünglichen Commits, wobei die kürzere Nachricht bei den Commits eingesetzt wird, die die IDE-Hooks einführen.

Die Zählungen stimmen nicht überein, und das ist kein Widerspruch.

Jede veröffentlichte Zahl zum Auswirkungsradius ist an eine andere Einheit geknüpft, und die Einheiten sind nicht austauschbar. Elastic Security Labs zählte in einem Bericht vom 6. August über 400 eindeutige npm-Pakete als kompromittiert. Microsoft Threat Intelligence beschrieb mehr als 400 Pakete über mehrere voneinander unabhängige Publisher hinweg. Aikido, zitiert von BleepingComputer, bezifferte es auf mindestens 868 Pakete in 1.381 Versionen. Orca Security meldet 10 direkt vergiftete keyv- und cacheable-Pakete mit über 619 Millionen monatlichen Downloads, dann 868 weitere Pakete und 1.381 Versionen, die der Wurm erreichte, was mehr als 2 Milliarden monatliche Installationen ergibt. Die CSA-Advisory AD-2026-009 aus Singapur vom 6. August verzeichnet über 1.300 kompromittierte Paketversionen, die zusammen 2 Milliarden monatliche Downloads.

Das sind drei verschiedene Bezugsgrößen – Pakete, Paketversionen und monatliches Downloadvolumen –, die zu drei verschiedenen Zeitpunkten einer noch laufenden Kampagne erhoben wurden. Zscalers Darstellung der Geschwindigkeit erklärt, warum sie auseinandergehen: Darin heißt es: Der Wurm breitete sich in weniger als vier Stunden selbst auf mehr als 400 Pakete aus und veröffentlichte auf dem Höhepunkt ungefähr ein infiziertes Paket pro Sekunde. Eine spätere Zahl als Korrektur einer früheren zu behandeln, wäre falsch; jede ist eine Momentaufnahme, und keine der zitierten Quellen nennt eine endgültige Gesamtzahl.

Die Expositionszahlen von Elastic auf Bibliotheksebene sind die am häufigsten zitierten und am wenigsten mehrdeutigen. Sie meldet allein für keyv über 600 Millionen Downloads im Vormonat, mit flat-cache nahe 580 Millionen, cacheable-request über 137 Millionen, cacheable über 30 Millionen und cache-manager über 16 Millionen. Die Sicherheitsmeldung von CSA listet die konkret kompromittierten Versionen auf, darunter keyv 6.0.0, flat-cache 6.1.24, file-entry-cache 11.1.6, cacheable-request 13.0.20, cacheable 2.5.1, cache-manager 7.2.10, @cacheable/utils 2.5.1 und ecto 5.0.1.

Die Widerrufsfalle

Responder, die eine betroffene Version installiert haben, stehen nach dem ersten Problem vor einem zweiten. Elastic berichtet, dass die Payload in einem bedingten GitHub-Fallback-Pfad versucht, eine Token-Monitor-Komponente zu installieren, die den Zugriff auf Anmeldeinformationen aufrechterhält und einen zerstörerischen Handler enthält, falls das überwachte Token widerrufen wird. Zscaler beschreibt den Mechanismus im operativen Detail und nennt ihn eine Token-Widerruf-Falle: Der Wurm installiert einen Hintergrundprozess, der alle 60 Sekunden die GitHub-API mit dem gestohlenen Token abfragt, und wenn das Token einen 4xx-Fehler zurückgibt – was bedeutet, dass das Opfer es widerrufen hat – wird eine sekundäre zerstörerische Payload ausgelöst, die je nach Variante Remote-Code-Ausführung oder das Löschen des Home-Verzeichnisses des Benutzers umfassen kann.

Wiz ergänzt, dass der Totmannschalter selektiv anhand einer Antwort vom Command-and-Control-Server scharfgeschaltet wird: Der Operator kann einen Wert zurückgeben, der angibt, welcher Befehl scharfgeschaltet werden soll und auf welches Token der Schalter im Hinblick auf einen Widerruf achten soll. Wiz merkt außerdem an, dass der Monitor nach einer gültigen Antwort vom Benutzer-Endpunkt sucht, sodass jeder dort gültige Token-Typ als Auslöser dienen kann.

Die praktische Konsequenz wird von BleepingComputer und der darin zitierten Aikido-Anleitung dokumentiert: Wenn auf einer Entwickler-Workstation oder einem CI/CD-Runner eine betroffene Version installiert wurde, sollte diese als kompromittiert behandelt werden selbst wenn das Paket anschließend entfernt wurde, weil die Ausführung der zweiten Phase Tokens offengelegt und die Build-Integrität untergraben haben kann. Microsofts Anleitung gelangt von der Build-Seite aus zum selben Ergebnis und warnt, dass Organisationen, die ein betroffenes Paket mit aktivierten Lifecycle-Skripten installiert haben, die Workstation oder den Build-Runner als potenziell kompromittiert behandeln und betroffene Systeme sowie nachgelagerte Artefakte aus vertrauenswürdigen Quellen neu erstellen sollten.

Was feststeht, was beurteilt wird und was niemand gezeigt hat

Der Primärbericht und fünf unabhängige Analysen stimmen hinsichtlich der Mechanik überein, und die mechanischen Aussagen sind der stärkste Teil der Akte.

• Das GitHub-Konto des keyv-Maintainers wurde kompromittiert, und bösartige Dateien wurden direkt in main gepusht, bevor am 4. August 2026 eine Version veröffentlicht wurde – übereinstimmend berichtet von Wiz, Orca Security, BleepingComputer und CSA Singapore.

• Mindestens {{1}}keyv 6.0.0{{/1}} erreichte npm über die eigene CI-Pipeline des Opfers und brachte gültige Provenienz mit, wobei {{2}}Zscaler{{/2}} eine {{3}}SLSA Build Level 3{{/3}}-Attestierung angab. Dies ist die Behauptung, die den Vorfall bemerkenswert macht, und sie wird von drei Organisationen gestützt, die nicht Mitautoren der Arbeiten der jeweils anderen waren.

• Ein Preinstall-Hook führte setup.mjs aus, das Bun v1.3.13 herunterlud und eine obfuskierte Payload ausführte, die mehr als 300 Muster für Zugangsdaten durchsuchte, darunter auch Zugangsdaten von KI-Coding-Tools — Elastic und Wiz stimmen sowohl bei der Runtime-Version als auch bei der Liste der KI-Zugangsdaten überein.

• Hooks, die in .claude/settings.json und .vscode/tasks.json geschrieben werden, werden beim Sitzungsstart und beim Öffnen eines Ordners ausgeführt, und ein GitHub-App-Token weitete dies auf bis zu 50 Branches pro zugänglichem Repository aus – Elastics Befund und die Grundlage für seine Aussage, dass ein Entwickler durch das Öffnen eines Repositorys infiziert werden kann.

• Mehr als 400 eindeutige Pakete wurden innerhalb weniger Tage kompromittiert, und CSA Singapore, eine nationale Regulierungsbehörde, veröffentlichte am 6. August 2026 die Warnmeldung AD-2026-009 mit einer Auflistung der betroffenen Versionen und Indikatoren.

Was die Quellen als Bewertung statt als Tatsache behandeln, sollte gekennzeichnet werden. Wiz beschreibt die Nutzlast als Nachfahren der Malware-Familie „Mini“ Shai-Hulud, die auf öffentlichen, von TeamPCP veröffentlichten Shai-Hulud-Open-Source-Repositories aufbaut, mit einigen entscheidenden Änderungen; Orca Security schreibt den Angriff TeamPCP zu; Zscaler bringt ChainDrop mit TeamPCP in Verbindung und ordnet es in eine Abstammungslinie ein, die bis September 2025 zurückreicht. Das ist ein Konsens der Anbieterzuordnung, nicht etwas, das ein zitiertes Primärdokument über eine namentlich genannte Einzelperson oder Gruppe belegt.

Drei Dinge, die keine zitierte Quelle belegt und die dieser Artikel nicht ergänzt. Erstens: wie das Maintainer-Konto übernommen wurde: Zscaler erklärt ausdrücklich, dass der genaue Mechanismus zum Zeitpunkt seiner Analyse unbekannt war. Zweitens: eine einzige abschließende Gesamtsumme: Die Zahlen 400, 868 und 1.300 zählen Pakete, Pakete samt Versionen und Versionen zu unterschiedlichen Zeitpunkten, und keine Quelle behauptet, dass die Kampagne abgeschlossen ist. Drittens, und am wichtigsten für die KI-spezifische Behauptung in diesem Datensatz: Keine zitierte Quelle berichtet von einem bestätigten Fall, in dem ein gestohlener Zugangsdatensatz von Anthropic, Codex, Cursor, Gemini oder OpenAI gegen ein Anbieterkonto wiederverwendet wurde. Dokumentiert sind Absicht und Fähigkeit – eine ausdrückliche Zieliste und ein Collector, der darauf ausgelegt ist, sie zu erreichen – nicht eine nachgewiesene nachgelagerte Kompromittierung der Systeme eines KI-Anbieters.

Was sich danach geändert hat – und was eine Einsatzkraft tun muss

Die konkreteste Gegenmaßnahme in dem Bericht ist eine Plattformänderung. Elastic empfiehlt ein Upgrade auf npm 12 oder höher, wodurch Preinstall-Hooks standardmäßig blockiert werden; Microsofts Leitfaden empfiehlt unabhängig npm CLI v12 und die Funktion min-release-age, die neue Versionen lange genug zurückhält, damit die Community eine Kompromittierung erkennt, bevor sie einen Build erreicht.

Darüber hinaus überschneiden sich die von den Quellen veröffentlichten Reaktionsschritte stark.

• Elastic: Alle GitHub-Tokens, einschließlich Sitzungstokens, auf betroffenen Maschinen widerrufen; npm-Tokens widerrufen und neu generieren, insbesondere Automatisierungstokens mit Schreibberechtigung und Zwei-Faktor-Umgehung; Repositories nach unbefugten Commits mit der Nachricht chore: update config from claude@users.noreply.github.com durchsuchen; Cloud-, Kubernetes-, Vault-, KI-Tooling- und CI/CD-Secrets rotieren; Zwei-Faktor-Authentifizierung für npm-Konten aktivieren.

• Microsoft: npm- und Yarn-Caches auf betroffenen Endpunkten und Build-Hosts bereinigen, bekannt gute Versionen pinnen, Lockfiles und Artefakte auf die kompromittierten Versionen einschließlich transitiver Referenzen prüfen, gemeinsam genutzte Basisimages und Golden-Build-Runner neu erstellen und Token-Scopes, Workflow-Genehmigungen sowie Release-Provenienz überprüfen, da der Vorfall mit Missbrauch der CI/CD-Pipeline über OIDC-Publishing vereinbar ist.

• CSA Singapore: Entfernen Sie betroffene Versionen aus Entwicklungs-, Build- und CI/CD-Umgebungen, betrachten Sie betroffene Systeme als kompromittiert und bauen Sie sie neu auf, rotieren Sie Zugangsdaten, überprüfen Sie Cloud- und Quellcode-Umgebungen auf unbefugten Zugriff, überwachen Sie auf veröffentlichte Indikatoren und stärken Sie Allowlisting-, Integritätsprüfungs- und Provenienzkontrollen.

• Zscaler: .claude/, .cursor/, .vscode/ und .gemini/ als ausführbaren Code behandeln und SLSA- oder Sigstore-Provenienz nicht länger als Beweis für Sicherheit werten – sondern sie stattdessen mit Anomalieerkennung beim Veröffentlichungsverhalten verzahnen, etwa bei Veröffentlichungen außerhalb der Geschäftszeiten, Massenveröffentlichungen von Versionen und Erstveröffentlichenden.

Der Bericht enthält kein Ergebnis einer Bereinigung. Keine zitierte Quelle berichtet, dass die bösartigen Versionen vollständig entfernt, ein Konto wiederhergestellt, eine Festnahme vorgenommen oder eine behördliche Durchsetzungsmaßnahme ergriffen wurde; die Warnung von CSA ist ein Hinweis an Verteidiger, keine Feststellung gegen eine Partei.

Was der Vorfall verändert, ist eine Klassifizierung. Eine Konfigurationsdatei eines Entwicklerwerkzeugs ist ein Ausführungspfad, und ein Editor, der einen Ordner öffnet, ist ein Ausführungsereignis. Und eine Herkunftsbescheinigung ist eine Aussage darüber, welche Pipeline ein Paket erzeugt hat – nicht darüber, wer die Schlüssel in der Hand hielt, als diese Pipeline lief, und genau das ist die Lücke, durch die das erste keyv-Release gefallen ist.