Playbook3 Abschnitte · 2 Min. LesezeitVon Dezső Mező · Veröffentlicht 3. Oktober 2026.mdSupply chainnpmSecurityCI
Das durchschnittliche npm-install zieht hunderte transitive Pakete — jedes der Code eines Fremden in Reichweite deiner Nutzerdaten. Durch Lesen kann man sie nicht auditieren — aber man kann entscheiden, welche Fremden man laufen lässt, genau wissen, was gerade installiert ist, und schnell merken, wenn einer feindselig wird. Das ist der Arbeits-Satz an Kontrollen, in der Reihenfolge, in der sie sich bezahlen.
01Lockfiles sind der Audit-Trail
Lockfile committen, und Installs werden reproduzierbar — die CI baut, was du reviewed hast, nicht was die Registry heute ausliefert. 'npm install', das in der CI deinen Tree mutiert, ist der stille Weg, wie sich eine Dependency-Version unter dir ändert.
02Kontinuierlich scannen, nicht einmal
CI-Scanner melden bekannte CVEs bei jedem Build; wöchentliche Dependabot- oder Renovate-PRs halten den Baum vom Versteinern ab. Beides entfernt kein Risiko — beide machen aus 'wir könnten irgendwo verwundbar sein' eine endliche, reviewbare Liste.
03Weniger, älter, besser gepflegt
Die stärkste Kontrolle ist, weniger Dependencies zu wählen: Ein Paket mit drei Maintainern und wöchentlichem Release-Rhythmus ist ein anderes Risiko als eines vom letzten Dienstag. Für alles, was Geld, Auth oder Kundendaten berührt, ist das Schreiben der fünfzig Zeilen oft die billigste Option auf dem Tisch.
Was bleibt
- Lockfile committen — die CI baut, was du reviewed hast.
- CVE-Scanning in der CI plus wöchentliche Update-PRs.
- Weniger, ältere, gepflegte Pakete bevorzugen.
- Für Geld, Auth und Kundendaten sind die fünfzig Zeilen billiger als eine Dependency.
Mehr aus dem Lab
Alle Beiträge ansehen
Prompt injection in production agents
KI-Sicherheits-Self-Audit
MCP-Server in Produktion, nicht in der Demo
Prompts sind Code: evaluiere sie wie Code
Sollen wir das an Ihrem System ansehen?Gespräch beginnen
