Der Angriff auf die Softwarebibliotheken keyv und cacheable vom 4. August 2026 zeigt eine oft übersehene Grenze. Die sogenannte Provenance, also der Nachweis, wo und über welchen Prozess ein Artefakt gebaut wurde, bestätigt die Herkunft eines Builds. Sie bestätigt nicht, dass der zugrunde liegende Quellcode legitim oder unverändert war.
Bei keyv@6.0.0 waren npm-Provenance und SLSA-Attestation (ein Beleg, dass die Software in einer sicheren, nachvollziehbaren Umgebung gebaut wurde) gültig. Dennoch enthielt das veröffentlichte Paket Schadcode, weil dieser bereits vor dem Build in das Repository eingebracht worden war. Der reguläre Prozess baute und signierte damit korrekt einen kompromittierten Stand.
https://socket.dev/supply-chain-attacks/keyv-and-cacheable-compromise
Provenance schützt den Veröffentlichungsweg, nicht automatisch die Integrität des Quellcodes. Wer eine gültige Attestation als vollständigen Sicherheitsnachweis bewertet, verwechselt Build-Herkunft mit Code-Integrität.
Das kompromittierte Paket enthielt einen preinstall-Hook, der bereits bei der Installation lief. Damit konnte Schadcode auf Entwicklerrechnern oder CI-Runnern auf Tokens, Cloud-Zugänge und weitere sensible Daten zugreifen. Die Gefahr beginnt also nicht erst in der Produktivumgebung, sondern beim Auflösen und Installieren von Abhängigkeiten.
https://snyk.io/blog/inside-keyv-npm-compromise-preinstall-malware-trusted-provenance-ide-hooks/
Hinzu kamen Projektkonfigurationen für Claude Code und VS Code, die beim Öffnen eines Repositorys Code ausführen konnten. Solche Dateien gehören inzwischen ebenso in Sicherheitsreviews wie Build-Skripte und CI-Konfigurationen. Ein reiner Dependency-Scan reicht dafür nicht aus.
https://safedep.io/keyv-npm-supply-chain-compromise/
Die gemeldete Reichweite unterstreicht das Risiko, auch wenn sie keine Zahl tatsächlich kompromittierter Systeme beschreibt. keyv kam laut Aikido zum Zeitpunkt der Analyse auf rund 127 Millionen wöchentliche Downloads. Entscheidend für die eigene Bewertung sind jedoch nicht globale Summen, sondern die konkret verwendeten Versionen in Lockfiles, Artefakt-Proxys und Build-Caches.
https://aikido.dev/blog/keyv-and-friends-compromised-in-npm-supply-chain-attack
Für Security- und Plattformteams folgt daraus eine klare Priorität. Lifecycle-Skripte sollten nur dort laufen, wo sie erforderlich sind, und dabei möglichst geringe Rechte erhalten. Installationsprozesse dürfen keinen Zugriff auf weitreichende Publishing-Tokens oder produktive Cloud-Zugänge bekommen. Neu veröffentlichte Abhängigkeiten können zudem vor der Übernahme in zentrale Builds eine Wartezeit durchlaufen.
Auch die Incident Response muss diesen Fall abdecken. Nach einer potenziell bösartigen Installation muss schnell erkennbar sein, welche Zugangsdaten auf dem betroffenen System verfügbar waren. Host-Isolierung und die Suche nach Persistenz sollten vor der Token-Rotation erfolgen, weil eine vorschnelle Sperrung Angreifer warnen kann.
https://snyk.io/blog/inside-keyv-npm-compromise-preinstall-malware-trusted-provenance-ide-hooks
Provenance bleibt wichtig. Sie ist jedoch ein Herkunftsnachweis, kein vollständiger Integritätsnachweis. Sicherheit entsteht erst dann, wenn auch die Ausführung fremden Codes, seine Berechtigungen sowie ausführbare Editor- und Agentenkonfigurationen kontrolliert werden.
Der Vorfall sollte für jeden Anlass sein, die Ausführung fremden Codes als eigenständiges Risiko zu behandeln. Besonders gilt dies bei Installationsprozessen und Build-Runnern mit weitreichenden Zugängen, da dort ein kompromittiertes Paket unmittelbar Tokens oder Cloud-Zugriffe abgreifen kann. Editor- und Agentenkonfigurationen gehören deshalb verbindlich in Repository-Reviews.
