Wenn sich npm gegen dich wendet

Ein modernes JavaScript-Projekt hat leicht über tausend Abhängigkeiten, die meisten von ihnen indirekt. Python, Go, Rust und Java-Projekte sind nicht weit zurück. Jedes dieser Pakete ist Code, geschrieben von jemandem, den Sie nie getroffen haben, läuft auf Ihrem Laptop und in Ihrem Informanten mit Zugriff auf Ihre Geheimnisse.

Jahrelang hat das Vertrauen meistens funktioniert. In letzter Zeit haben Angreifer gezeigt, wie zerbrechlich es ist.

Jüngste Angriffe

Ohne in jeden Vorfall einzugehen, ist das Muster der letzten Jahre klar:

• Entführte Unterhalterkonten. Im September 2025 phishten Angreifer die Betreuer sehr beliebter npm-Pakete und veröffentlichten bösartige Versionen von Bibliotheken, die pro Woche Milliarden von Malen heruntergeladen wurden. Der Code versuchte Kryptowährung von Nutzern zu stehlen.
• Selbstverbreitende Würmer. Auch im Jahr 2025 wird ein Wurm mit dem Spitznamen Shai-Hulud verbreitet durch npm: Einmal installiert, stahl es Token vom Computer oder CI des Entwicklers und verwendete sie, um infizierte Versionen anderer Pakete zu veröffentlichen, die diese Person unterhielt. Hunderte Pakete wurden betroffen.
• Kompromizierte Baustoffe. Angreifer haben Code eingefügt, der die Maschinen der Entwickler nach Geheimnissen durchsuchte, und sogar KI-Befehlszeilen-Tools verwendet, die lokal installiert sind, um sie zu finden.
• Typosquatting und Slopsquatting. Pakete mit Namen, die nur einen Buchstaben von den beliebten entfernt sind, oder Namen, die KI-Assistenten erfunden haben.
• Angriffe im Langspiel Wie die Hintertür von XZ Utils, wo ein Angreifer Jahre damit verbrachte, das Vertrauen eines Wartungskräften zu gewinnen.

Was sie gemeinsam haben: Sie nutzen keinen Fehler in Ihrem Code aus. Sie nutzen das Vertrauen aus, das Sie in Ihre Abhängigkeiten setzen.

Ein Paket zu installieren, ist wie den Code eines Fremden mit deinen Anmeldeinformationen auszuführen. Wir haben einfach aufgehört, so darüber nachzudenken.

Sperrdateien und private Register

Die Grundlagen sind wichtig:

• Verpfändet die Schließdateien (package-lock.json, pnpm-lock.yaml, poetry.lock, uv.lock, go.sum) und mit ihnen streng installieren: npm ci statt npm install in CI. Auf diese Weise kann eine neue bösartige Version nicht während eines Builds hereinbrechen.
• Verwenden Sie eine private Registrierung oder einen Proxy (Artifactory, Nexus, GitHub Pakete, AWS CodeArtifact, Google Artifact Registry) und die Datenbank für die Erstellung von Daten. Es speichert genehmigte Pakete, kann bekannte schlechte Pakete blockieren und gibt Ihnen einen einzigen Ort, um zu kontrollieren, was kommt.
• Anwendungsbereich interne Pakete (wie @acme/...) und konfigurieren Sie Ihren Paketmanager so, dass interne Namen nur aus Ihrer Registrierung kommen können. Das verhindert Verwirrung über die Abhängigkeit, wo ein Angreifer ein öffentliches Paket mit dem gleichen Namen wie Ihr internes veröffentlicht.

Warten, bevor neue Versionen installiert werden

Die meisten schädlichen Paketversionen werden innerhalb von Stunden oder Tagen erkannt und entfernt. Eine einfache, aber mächtige Verteidigung: installieren Sie keine brandneuen Versionen sofort.

• - Erneuerung minimumReleaseAge wartet auf eine konfigurierbare Zeit (z. B. drei Tage), bevor er ein Update vorschlägt.
• Pnpm unterstützt eine Mindestveröffentlichungsalterseinstellung, so dass es nicht Versionen, die jünger als die Schwelle sind, auflösen wird.
• Einige Registrierungsstellen und Vollmachtsstellen unterstützen ähnliche Quarantänezeiten.

Du verlierst ein paar Tage mit neuen Features. Sie erhalten Schutz vor den meisten "publish and hope"-Angriffen.

Einschränkung der Installationsmöglichkeiten von Skripten

Viele Angriffe laufen während der Installation, durch postinstall - Das ist ein Schritt weiter.

• Installationsskripte standardmäßig deaktivieren wenn möglich (npm config set ignore-scripts true, pnpm strengere Standardeinstellungen für Abhängigkeits-Build-Skripte) und erlauben sie nur für Pakete, die sie wirklich benötigen.
• Die Rennen bauen in isolierten, vergänglichen Umgebungen auf: ein frischer Container- oder CI-Laufmann pro Job, ohne langlebige Anmeldeinformationen.
• Einschränkung des Netzwerk-Ausgangs von Informanten, wo du kannst. Eine Build, die keinen unbekannten Server erreicht, kann deine Geheimnisse nicht dorthin senden.
• Veröffentlichen Sie niemals Token auf Entwickler-Maschinen Wenn Sie es vermeiden können. Verwendung Vertrauenswürdige Verlage Die Daten werden von CI (npm und PyPI unterstützen beide OIDC-basierte Veröffentlichung) und erfordern 2FA für die Instandhalter.

Werkzeuge , die mich warnen

• Steckdosis: analysiert Pakete auf verdächtiges Verhalten (Installationsscripts, Netzwerkzugang, verschleierter Code, neue Wartungsprogramme), nicht nur bekannte Schwachstellen.
• OSV-Scanner, Trivy, Grippe, npm-Audit: bekannte Schwachstellen und bekannte bösartige Pakete.
• OpenSSF-Scorecard: Bewertet, wie gut ein Projekt Sicherheitspraktiken befolgt, bevor es übernommen wird.
• GitHubs Abhängigkeitsüberprüfung Die Kommission hat die Kommission aufgefordert, die in den letzten Jahren durchgeführten Untersuchungen zu überprüfen.

Und ein Nicht-Werkzeug: Frage neue Abhängigkeiten- Ich weiß . Braucht dieses Projekt wirklich ein Paket für das Linkspolstern einer Schnur? Jede Abhängigkeit, die du nicht hinzufügst, ist eine, um die du dir keine Sorgen machen musst.

Wenn Sie betroffen sind

Wenn ein kompromittiertes Paket Ihren Stapel erreicht:

1. Finden Sie heraus, wo es installiert wurde (SBOMs und Lockfiles machen das schnell).
2. Angenommen, alle während der Installation zugänglichen Geheimnisse sind kompromittiert: Drehen Sie sie ..
3. Überprüfen Sie die Datenlisten und Maschinen auf Anzeichen von böswilligem Verhalten.
4. Verknüpfen Sie sich mit einer bekannten Version und bauen Sie sie wieder auf.

Also, wo fange ich an?

Strenge Verriegelung von Installationen in CI, ein Mindestveröffentlichungsalter für Updates, ein privates Proxy-Register und keine langlebigen Publish-Token. Diese vier Maßnahmen hätten die meisten der jüngsten Angriffe abgeschwächt.

Meine Meinung: Abhängigkeiten sind ein Geschenk der Open-Source-Welt. Nehmen Sie sie dankbar an, aber überprüfen Sie, was drin ist, bevor Sie sie in Produktion bringen.

Desly