Abhängigkeitssicherheit
Regeln
- Führen Sie
npm audit in CI aus – schlagen Sie den Build bei hohen/kritischen Schwachstellen fehl
- Verwenden Sie
lockfile-lint, um zu überprüfen, dass alle Pakete auf die offizielle npm-Registry auflösen
- Legen Sie Hauptversionen in
package.json fest: verwenden Sie ^ für Nebenversions-Updates, niemals * oder latest
- Überprüfen Sie neue Abhängigkeiten vor der Installation: prüfen Sie npm-Downloadzahlen, letztes Veröffentlichungsdatum, Anzahl der Maintainer
- Verwenden Sie
npm ls --all, um transitive Abhängigkeiten zu auditieren – Ihre direkten Abhängigkeiten ziehen hunderte weitere nach sich
- Richten Sie Snyk, Socket.dev oder GitHub Dependabot für Echtzeit-Schwachstellenwarnungen ein
- Aktualisieren Sie Abhängigkeiten wöchentlich – veraltete Abhängigkeiten häufen bekannte Schwachstellen an
- name: Abhängigkeiten auditieren
run: npm audit --audit-level=high
- name: Lockfile-Integrität überprüfen
run: npx lockfile-lint --path package-lock.json --type npm --allowed-hosts npm --validate-https
{
"dependencies": {
"next": "^14.0.0",
"react": "^18.0.0",
"zod": "^3.0.0"
}
}
Vermeiden
npm install random-package ohne vorherige Überprüfung des Pakets – Typosquatting ist real
- Ignorieren von
npm audit-Warnungen – bekannte Schwachstellen sind der einfachste Angriffsvektor
- Verwendung von
* oder latest als Versionsbereiche – eine kompromittierte Veröffentlichung trifft sofort Ihren Build
- Ausführen von
postinstall-Skripten aus nicht vertrauenswürdigen Paketen ohne Überprüfung
- Annahme, dass beliebte Pakete sicher sind – selbst
event-stream (Millionen Downloads) wurde kompromittiert