Die KI schlägt npm install vor. Wer prüft eigentlich das Paket?

Eine kleine Funktion fehlt. Der Coding-Assistent schlägt zwölf Zeilen Anwendungscode vor – und dazu einen Installationsbefehl für ein Paket, das angeblich genau dieses Problem löst.

Zwei Minuten später funktioniert der Build. Im Pull Request stehen ein paar übersichtliche Codezeilen und mehrere hundert Änderungen im Lockfile.

Genau dort entsteht ein neuer Review-Typ: Nicht nur der generierte Code muss geprüft werden. Die vorgeschlagene Abhängigkeit ist selbst Teil der Architekturänderung.

Das ist kein Argument gegen AI-gestützte Entwicklung. Sie kann Recherche, Boilerplate und Umsetzung deutlich beschleunigen. Aber ein Assistent übernimmt nicht automatisch die Verantwortung für Paketidentität, Maintainer, transitive Abhängigkeiten, Install-Skripte, Release-Prozess oder die Frage, ob das Paket überhaupt nötig ist.

Ein guter Review behandelt deshalb npm install <paket> nicht als Nebeneffekt des Features, sondern als eigene Entscheidung.

Die Abhängigkeit ist Teil des Changes

Bei JavaScript- und TypeScript-Projekten sieht eine neue Dependency oft harmlos aus: eine Zeile in package.json, ein großer Lockfile-Diff und ein Import.

Technisch kann sie aber weit mehr verändern:

• neue direkte und transitive Pakete,
• neue ausführbare Install- oder Build-Skripte,
• native Module oder Binärdateien,
• neue Registry-, Git- oder URL-Quellen,
• weitere Update- und Wartungspflichten,
• neue bekannte oder zukünftige Schwachstellen,
• zusätzliche Lizenz- oder Betriebsabhängigkeiten,
• mehr Code, der in CI, Build oder Laufzeit ausgeführt wird.

Deshalb ist die richtige Frage nicht nur: „Funktioniert der generierte Code?“

Sondern auch: „Welche neue Vertrauensbeziehung haben wir gerade in das Projekt aufgenommen?“

Ein 10-Minuten-Dependency-Gate für AI-generierte Änderungen

Nicht jede neue Bibliothek braucht ein Security-Assessment mit drei Meetings. Aber jede neue Bibliothek sollte eine kurze, reproduzierbare Prüfung überstehen.

1. Existiert genau dieses Paket – und ist es das Paket, das Sie meinen?

Öffnen Sie die Registry-Seite und das verlinkte Quellrepository selbst. Prüfen Sie den exakten Paketnamen, den Namespace, die aktuelle Version und die Projektverknüpfung.

Das klingt banal, ist aber bei AI-Vorschlägen besonders wichtig. Ein Modell kann eine API korrekt erklären und trotzdem einen falschen oder veralteten Paketnamen nennen. Es kann ein Paket empfehlen, dessen Name einem etablierten Projekt ähnelt, oder eine Bibliothek verwenden, die seit Jahren nicht mehr gepflegt wird.

Der Installationsbefehl ist deshalb kein Beweis für Paketidentität.

Prüfen Sie mindestens:

• exakten Paketnamen und Scope,
• Registry-Eintrag,
• verlinktes Source Repository,
• Veröffentlichungsverlauf,
• letzte Releases und erkennbare Wartung,
• ob Dokumentation und tatsächlich veröffentlichte Version zusammenpassen.

GitHub weist in seiner Dependency-Review-Dokumentation darauf hin, dass unter anderem Versionsalter und Zahl der abhängigen Projekte zusätzliche Hinweise liefern können. Solche Signale ersetzen kein Review, helfen aber dabei, versehentlich das falsche Paket zu erkennen.

2. Brauchen Sie überhaupt eine neue Dependency?

AI-Assistenten optimieren häufig auf eine schnelle, bekannte Lösung. Das kann sinnvoll sein. Es kann aber auch bedeuten, dass für drei Zeilen Standardplattform-Code ein neues Paket in den Lebenszyklus des Produkts aufgenommen wird.

Fragen Sie vor der Installation:

• Kann die Plattform oder Runtime das bereits nativ?
• Gibt es im Projekt schon eine Bibliothek mit derselben Funktion?
• Ist die vorgeschlagene Dependency nur ein dünner Wrapper?
• Wird die Funktion an einer Stelle oder in einem zentralen Produktpfad gebraucht?
• Rechtfertigt der Nutzen zusätzliche Updates, Transitives und Review-Aufwand?

Die beste Dependency ist nicht automatisch die kleinste. Aber jede neue Dependency sollte einen benennbaren Grund haben.

3. Prüfen Sie Manifest und Lockfile als eine Änderung

Die aktuelle npm-Dokumentation beschreibt package-lock.json als genaue Beschreibung des erzeugten Dependency-Baums. Der Lockfile soll ins Repository eingecheckt werden und sorgt dafür, dass Team, CI und Deployment denselben Baum installieren können.

Das bedeutet: Ein Pull Request mit neuer Dependency besteht nicht nur aus dem package.json-Eintrag.

Prüfen Sie im Lockfile:

• welche direkten und transitiven Pakete hinzugekommen sind,
• welche Versionen sich unerwartet mitgeändert haben,
• ob sich Registry- oder Quell-URLs verändert haben,
• ob Git- oder Remote-Tarball-Quellen auftauchen,
• ob eine scheinbar kleine Änderung einen ungewöhnlich großen neuen Dependency-Baum erzeugt.

Große Lockfiles sind schwer manuell zu lesen. Genau dafür ist eine strukturierte Dependency Review nützlich: GitHub kann bei unterstützten Manifesten und Lockfiles hinzugefügte, entfernte und aktualisierte Dependencies sowie bekannte Schwachstellen sichtbar machen – einschließlich indirekter Änderungen.

Trotzdem empfiehlt GitHub zusätzlich den normalen Source-Diff zu prüfen, weil nicht jede relevante Änderung von der Dependency-Ansicht erfasst werden kann.

4. Install-Skripte sind ausführbarer Code, nicht Metadaten

Ein Paket kann beim Installieren Lifecycle-Skripte ausführen. Solche Skripte können legitime Aufgaben erledigen: native Komponenten bauen, Dateien generieren oder Plattformanpassungen vorbereiten.

Sie sind aber trotzdem Code, der während Ihrer Installation läuft.

Deshalb gehört bei einer neuen oder unerwarteten Dependency die Frage dazu:

• Hat das Paket Lifecycle-Skripte?
• Was führen sie aus?
• Braucht das Paket diese Skripte tatsächlich?
• Werden beim Installieren Netzwerk, Dateisystem oder Compiler verwendet?
• Unter welchen Berechtigungen läuft die Installation in CI?
• Sind dort Secrets verfügbar, die für den Build gar nicht nötig wären?

Aktuelle npm-12-Dokumentation enthält dafür explizite Steuerungen wie allow-scripts und strict-allow-scripts. Der wichtige Punkt ist weniger ein einzelner Default als die bewusste Projekt-Policy: Welche Dependency-Skripte dürfen in diesem Repository laufen, und was passiert bei einer neuen noch nicht geprüften Dependency?

Wenn das Team diese Frage nicht beantworten kann, entscheidet faktisch die jeweils installierte npm-Version und deren Konfiguration.

5. Git- und Remote-Abhängigkeiten sollten eine bewusste Ausnahme sein

Eine Dependency muss nicht zwingend aus der konfigurierten Registry kommen. package.json kann auch Git-Quellen oder direkte Tarball-URLs referenzieren.

Das kann für interne Projekte oder kontrollierte Spezialfälle legitim sein. Es verändert aber die Vertrauens- und Reproduzierbarkeitsgrenze.

Die aktuelle npm-12-Konfiguration setzt allow-git und allow-remote standardmäßig auf none. Registry-Tarballs aus dem konfigurierten Registry-Kontext bleiben davon unberührt; direkte Git- und beliebige Remote-URL-Quellen müssen dagegen bewusst erlaubt werden.

Das ist für Reviews ein gutes Prinzip, unabhängig vom konkreten Package Manager:

Ungewöhnliche Paketquellen sollten sichtbar und absichtlich sein.

Wenn ein AI-Vorschlag eine GitHub-URL, einen Branch oder einen externen Tarball installiert, behandeln Sie das nicht wie eine normale Registry-Version. Prüfen Sie Quelle, Pinning, Updateweg und warum die Registry nicht verwendet wird.

6. CI sollte den Lockfile prüfen – nicht still reparieren

npm install und npm ci haben unterschiedliche Aufgaben.

Laut aktueller npm-Dokumentation kann npm install den Lockfile aktualisieren, wenn package.json und Lockfile nicht mehr zusammenpassen. Das ist im lokalen Entwicklungsfluss oft nützlich.

npm ci ist für reproduzierbare automatisierte Installationen strenger: Ein Lockfile muss vorhanden sein; bei einem Konflikt zwischen package.json und Lockfile bricht der Befehl ab, statt die Dateien still anzupassen. Er schreibt außerdem weder package.json noch Lockfile um.

Für CI ist das ein wertvoller Kontrollpunkt.

Ein Build sollte nicht unbemerkt eine andere Dependency-Auflösung erzeugen als die, die im Pull Request geprüft wurde.

Prüfen Sie deshalb:

• wird in CI npm ci oder ein vergleichbar eingefrorener Installationsmodus genutzt,
• ist die npm-/Node-Version festgelegt oder zumindest kontrolliert,
• nutzt lokal und in CI dieselbe relevante Konfiguration,
• schlägt ein nicht synchroner Lockfile tatsächlich fehl,
• werden Installationswarnungen nicht im Lograuschen übersehen.

7. Nutzen Sie Dependency Review vor dem Merge

GitHub Dependency Review kann bei unterstützten Repositories zeigen:

• welche Dependencies hinzugefügt, entfernt oder aktualisiert wurden,
• welche indirekten Dependencies sich geändert haben,
• ob bekannte Vulnerabilities betroffen sind,
• Versions- und teilweise Lizenzinformationen.

Mit der Dependency Review Action kann diese Prüfung als Pull-Request-Check erzwungen werden. GitHub dokumentiert, dass der Check standardmäßig bei neu eingeführten bekannten verwundbaren Paketen fehlschlagen kann; Regeln lassen sich an die Repository-Policy anpassen.

Das ist besonders hilfreich für AI-generierte PRs, weil der Reviewer nicht aus einem riesigen Lockfile rekonstruieren muss, welche Dependency-Änderung tatsächlich entstanden ist.

Aber auch hier gilt: „kein bekannter CVE“ ist kein Sicherheitsurteil über ein neues Paket. Es ist eine nützliche Prüfung gegen bereits bekannte Probleme.

8. Provenance ist Zusatzinformation, nicht Freigabe

Bei Paketen mit npm-Provenance kann npm Informationen zum Build-Kontext anzeigen, unter anderem Source Commit, Build-Datei und Transparency-Log-Eintrag. Mit npm audit signatures lassen sich unterstützte Registry-Signaturen und Provenance-Attestierungen prüfen.

Das ist wertvoll, weil Herkunft überprüfbarer wird.

Es beantwortet jedoch nicht, ob Sie diese Dependency fachlich brauchen oder ob der attestierte Source Code sicher ist. Provenance ist deshalb ein Vertrauenssignal für Herkunft, kein automatischer Merge-Button.

Für eine neue Dependency kann die Reihenfolge so aussehen:

1. Paketidentität und Zweck prüfen.
2. Dependency- und Lockfile-Änderung verstehen.
3. bekannte Schwachstellen prüfen.
4. Installations- und Quellverhalten prüfen.
5. vorhandene Provenance oder Signaturen als zusätzliche Evidenz nutzen.
6. Anwendung und kritische Pfade testen.

npm 12 zeigt, warum die Toolchain-Version Teil der Policy ist

Ein unterschätzter Punkt: Dependency-Sicherheit hängt nicht nur vom Repository ab, sondern auch von der Version des Tools, das den Dependency-Baum installiert.

Die aktuellen npm-Dokumente markieren CLI 12.0.2 als aktuelle Version und dokumentieren unter anderem restriktivere Regeln für Git- und Remote-Abhängigkeiten sowie explizite Kontrollen für Install-Skripte.

Wenn Entwickler lokal npm 12 nutzen, CI aber eine andere Major-Version, können Annahmen über zulässige Quellen oder Script-Verhalten auseinanderlaufen.

Darum gehört in einen belastbaren Projektbetrieb:

• Node- und Package-Manager-Version dokumentieren,
• CI-Version kontrollieren,
• relevante .npmrc-Policy versionieren,
• Änderungen an Installationspolicy im Pull Request sichtbar machen,
• Upgrades des Package Managers wie andere Infrastrukturänderungen testen.

„Bei mir wurde es blockiert“ und „in CI wurde es ausgeführt“ sollten nicht zwei gültige Zustände desselben Projekts sein.

Eine kleine Pull-Request-Policy reicht oft aus

Für viele Teams genügt eine kurze Regel: Jede neue direkte Dependency braucht im PR eine Begründung.

Zum Beispiel:

• Warum wird das Paket benötigt?
• Welche vorhandene Lösung wurde verworfen?
• Welche exakte Dependency und Version kommt hinzu?
• Welche transitiven Änderungen entstehen?
• Gibt es Install- oder Lifecycle-Skripte?
• Kommt alles aus der erwarteten Registry?
• Zeigt Dependency Review bekannte Schwachstellen?
• Gibt es Provenance oder Signaturen, wenn sie für das Paket verfügbar sind?
• Funktioniert der Build mit dem eingefrorenen Lockfile?
• Wer übernimmt Updates oder entfernt die Dependency später wieder?

Das dauert bei einem unkritischen Paket wenige Minuten. Bei einem auffälligen Paket zeigt die Checkliste früh, dass mehr Prüfung nötig ist.

Der Vorteil ist nicht Bürokratie. Der Vorteil ist, dass der gleiche Mindeststandard gilt, egal ob die Dependency von einer Senior-Entwicklerin, einem Junior, Dependabot oder einem AI-Assistenten vorgeschlagen wurde.

AI-Code braucht einen Architektur-Review, nicht nur einen Syntax-Review

AI-generierter Code kann hervorragend aussehen. Genau deshalb ist der einfache Review-Reflex gefährlich: „Tests grün, Typen grün, passt.“

Ein Coding-Assistent kann eine Library als Lösung einführen, ohne Ihren Wartungshorizont, Ihre CI-Rechte, Ihre bestehende Dependency-Policy oder die Architekturhistorie des Produkts zu kennen.

Behandeln Sie externe Paketvorschläge daher wie jede andere untrusted technische Empfehlung:

• Name verifizieren,
• Quelle verifizieren,
• Notwendigkeit bewerten,
• Auswirkungen im Dependency-Baum ansehen,
• ausführbares Installationsverhalten prüfen,
• reproduzierbar installieren,
• automatisierte Sicherheitsinformationen auswerten,
• fachlich testen.

Die AI darf die Idee liefern. Die Vertrauensentscheidung bleibt beim Team.

Was Website-Pflichtencheck dabei prüfen würde

Ein Dependency- und AI-Code-Audit kann je nach Repository und Zugriff unter anderem untersuchen:

• direkte und transitive Dependencies,
• unnötige oder doppelte Bibliotheken,
• package.json- und Lockfile-Konsistenz,
• unerwartete Registry-, Git- und Remote-Quellen,
• Lifecycle- und Install-Skripte,
• npm-/Node-Versionen in Entwicklung und CI,
• .npmrc-Policy zu Quellen und Skripten,
• Verwendung von npm ci beziehungsweise eingefrorenen Installationen,
• GitHub Dependency Review und Merge-Gates,
• bekannte Vulnerabilities,
• Provenance- und Signaturprüfung, wo verfügbar,
• CI-Berechtigungen und Secrets während der Installation,
• Ownership für Updates und Entfernung,
• Regressionstests nach Dependency-Änderungen.

Das Ziel ist nicht, neue Pakete zu verbieten. Moderne Webentwicklung lebt von gut gepflegten Dependencies.

Das Ziel ist, aus „die KI hat gesagt, wir sollen das installieren“ einen sauberen technischen Satz zu machen:

„Wir wissen, welches Paket wir hinzufügen, warum wir es brauchen, was es beim Installieren und im Dependency-Baum verändert und welcher kontrollierte Weg es bis Produktion bringt.“

Wenn Ihr Lockfile in den letzten Monaten schnell gewachsen ist und niemand mehr genau sagen kann, warum bestimmte Pakete dort sind, ist ein Dependency-Audit ein sehr konkreter Wartungsschritt: behalten, aktualisieren, absichern oder entfernen – statt nur weiterzuinstallieren.