Default Misstrauen: Dies wird npm v12 ändern, um Ihre Lieferkette zu schützen

GitHub hat wichtige Änderungen in npm angekündigt, die mit der Version 12 ankommen und entworfen sind, um die Sabotagetechniken in der Lieferkette zu reduzieren, die das Standardverhalten von npm install. Im Wesentlichen kommt es zu einer Vertrauensänderung durch Unterlassung auf Misstrauen durch Auslassung: Skripte und Quellen von Abhängigkeiten, die jetzt ausgeführt oder behoben werden, werden automatisch notwendig. explizite Annahme der Betreuer oder die laufende Umgebung.

Die angekündigten Maßnahmen umfassen: die Skripte vorinstallieren, installieren und nachinstallieren werden nicht automatisch ausgeführt Sofern nicht ausdrücklich genehmigt; dass der Aufbau von nativen Modulen durch node-gyp der gleichen Regel unterliegt; und dass die von Git Repositories oder von der entfernten URL gebrachten Einheiten nicht mehr standardmäßig aufgelöst werden. GitHub erklärt, dass diese Änderungen verdeckte Ausführungspfade schließen, die von Angreifern verwendet werden, wie die Verwendung von .npmrc-Dateien in Git-Abhängigkeiten, um schädliche Ausführbarkeiten zu zwingen, auch wenn Skripte deaktiviert sind. Weitere technische Details und die offizielle Ankündigung sind bei der GitHub Changelog.

Die praktische Wirkung ist doppelt: einerseits, deutlich erhöht die Widerstandsfähigkeit gegen Lieferkettenangriffe, da viele neuere Kampagnen von der automatischen Ausführung von Skripten oder nicht registrierten Abhängigkeiten abhängig waren (z.B. Vorfälle mit beliebten Paketen und Wellen von schädlichen Paketen in npm). Andererseits müssen Projekte und Organisationen, die legitime Ströme auf Basis von Git-Abhängigkeiten, entfernten Tarbals oder Vorbereitungsskripten verwenden, ihre Konfiguration überprüfen und anpassen, bevor sie auf npm v12 migrieren, weil diese Ströme nicht mehr standardmäßig funktionieren.

GitHub empfiehlt die Vorbereitung bereits auf die Aktualisierung npm 11.16.0 oder mehr die Mitteilungen über die Aktionen einführt, die mit v12 brechen werden; dieses Fenster erlaubt zu identifizieren, welche Pakete oder Muster des Codes in Zukunft ausdrücklich genehmigt werden müssen. Wenn Sie Reaktionen und Vorschläge der technischen Gemeinschaft lesen möchten, Gemeinschaftsdiskussion wo Erfahrungen und Lösungen geteilt werden.

Für Ausrüstungs- und Sicherheitsbeamte beinhaltet dies eine praktische Überprüfung der Lieferkette: Generieren oder Aktualisieren der SBOM, Prüfung der von Git oder URL kommenden Transitionseinheiten und Kartierung der Pakete, die Installationsskripte ausführen oder native Zusammenstellung erfordern. Drittanbieter-Analyse-Tools und -Praktiken wie Policy Blocking in CI, Verwendung von verifizierten Lockfiles und Einstellung von Versionen sind jetzt relevanter als je zuvor. Eine gute kontextuelle Lektüre über Art und Umfang der Lieferkettenangriffe ist in Snyks Artikel zu diesem Thema verfügbar: was ist ein Angriff auf die Lieferkette.

Aus betrieblicher Sicht ist es zweckmäßig, die CI-Pipelines in einer Umgebung zu testen, die die neuen Einschränkungen vor dem v12-Update simuliert. Konfigurieren Sie weiße Listen für die nötigen Quellen, Dokumentberechtigungen für Skripte und native Gebäude und automatisieren Sie die kontrollierte Genehmigung in kontinuierlichen Integrationssystemen wird Überraschungen in Bereitstellungen und Releases vermeiden. Es ist auch an der Zeit, die Möglichkeit der kritische Abhängigkeiten verkaufen oder interne Spiegel für in der Produktion verwendete Bibliotheken zu bedienen, wodurch die Abhängigkeit von dynamischen externen Quellen reduziert wird.

Wir dürfen die Auswirkungen auf kleine Open Source-Projekte nicht aus den Augen verlieren: Viele Buchhandlungen oder Vorlagen verwenden Installateure und "vorbereiten" Skripte für Verpackungsaufgaben oder Beispiele. Die Betreuer müssen ihre Nutzer darüber informieren, wie sie migrieren und in einigen Fällen alternative Anweisungen (z.B. Skripte manuell ausführen oder Publishing-Prozesse anpassen, um Git- oder Tarbals-Abhängigkeiten zu vermeiden). Der Reibungsaufwand besteht, wird aber durch eine viel geringere Angriffsfläche ausgeglichen.

Schließlich ist für Organisationen, die ihre Position zu Schwellenbedrohungen verschärfen wollen, die praktische Empfehlung, einen zweiphasigen Plan zu erstellen: Erstens, führen Sie npm 11.16.0 in allen Entwicklungs- und CI-Umgebungen, um Warnungen zu sammeln und eine Liste von gerechtfertigten Ausnahmen zu erstellen; zweitens, automatische CI-Richtlinien implementieren, die die Auflösung von nicht genehmigten externen Quellen standardisieren und menschliche Überprüfungen für ihre Berechtigung erfordern. Durch diese Schritte wird die Möglichkeit reduziert, dass ein schädliches Paket während einer Installation ungewollt ausgeführt wird.

GitHubs Bewegung zu einem restriktiveren Modell spiegelt die Reifung der Verteidigung in Massenpaketökosystemen wider: Werkzeuge müssen annehmen, dass die automatische Installation ein Risikovektor ist. Die Teams, die diese Politiken im Vorfeld planen und einen Teil ihres Entwicklungs-Lebenszyklus machen, werden Sicherheit erlangen, ohne die operative Kontinuität zu gefährden.