Paket existiert nicht, Namensrisiko
Prüfregel · RSC-SEC-151
- Sicherheit
- Schweregrad: Hoch
- CWE-1357
- OWASP A08-2021
Fragt die direkten Abhängigkeiten aus package.json bei der öffentlichen npm-Registry ab und meldet Namen, die es dort nicht gibt. Gescopte Pakete, Scopes mit eigener Registry in der .npmrc und Workspace-Repos bleiben außen vor, weil ein 404 dort auch „privat“ heißen kann.
Warum das zählt
KI-Assistenten erfinden Paketnamen, und zwar wiederholbar: In einer USENIX-Studie von 2025 war rund jeder fünfte vorgeschlagene Name erfunden, und fast die Hälfte davon kam bei derselben Frage wieder. Angreifer nutzen genau das („Slopsquatting“): Sie registrieren die erfundenen Namen und veröffentlichen darunter ein Paket mit Install-Skript.
Solange ein Name in eurer package.json frei ist, kann ihn jeder belegen — der nächste `npm install` auf einem Entwickler-Rechner oder in der CI führt dann fremden Code aus. Ein heute fehlschlagender Install ist deshalb kein harmloser Tippfehler, sondern eine offene Stelle in der Lieferkette.
So prüft ihr es selbst: `npm view <paket>` zeigt, ob es das Paket gibt. Antwortet die Registry mit „404 Not Found“, stammt der Name entweder aus einer privaten Registry oder es gibt ihn nicht.
Prüfstufe
- Repo-Zugang (Deep-Scan)
So behebt ihr es
Den Namen entfernen oder durch das gemeinte, existierende Paket ersetzen und die Lock-Datei neu erzeugen; kommt das Paket aus einer privaten Registry, diese in der .npmrc des Projekts eintragen.