# npm v12 macht sicherere Installationen standardmäßig und zwingt JavaScript-Teams dazu, zu sagen, was sie tatsächlich vertrauen Source: TechNewsList (https://technewslist.com) Canonical URL: https://technewslist.com/de/article/npm-v12-install-time-security-defaults-2026-07-08-night-de Section: Software (https://technewslist.com/de/software) Author: TechNewsList Language: de Published: 2026-07-08T17:24:57.781+00:00 Updated: 2026-07-08T17:24:57.910529+00:00 > Der npm v12-Rollout von GitHub ist wichtig, weil er die Installationszeitausführung und den Abhängigkeitsabruf von freizügigen Standardeinstellungen auf explizite Opt-Ins umstellt, was die Art und Weise, wie JavaScript-Organisationen Builds, CI-Pipelines und automatisierte Veröffentlichungen sichern, erheblich verändern könnte. ## TL;DR - Laut GitHub ist npm v12 jetzt allgemein verfügbar und wandelt wichtige Ausführungspfade zur Installationszeit in explizite Opt-Ins um. - Die Version beginnt auch damit, die sensibelsten Verwendungen von 2FA-Bypass-Granular-Zugriffstokens zu verwerfen. - Das drängt JavaScript-Teams zu klareren Vertrauensrichtlinien für Installationen, CI und Paketveröffentlichung. ## Key points - npm v12 deaktiviert standardmäßig automatische Lebenszyklusskripte, Git-Abhängigkeiten und Remote-URL-Abhängigkeiten, sofern sie nicht ausdrücklich zugelassen sind. - Durch die Änderung werden JavaScript-Paketinstallationen in Richtung eines Genehmigungsmodells statt eines Annahmemodells verschoben. - GitHub schränkt auch die Möglichkeiten von 2FA-Bypass-Tokens ein, insbesondere im Zusammenhang mit Kontoänderungen und direkter Veröffentlichung. - Dabei handelt es sich um eine Änderung der Lieferkettensicherheit, nicht nur um eine Versionsänderung oder eine Optimierung der Entwicklerergonomie. - Teams, die sich frühzeitig anpassen, werden am Ende wahrscheinlich klarere Abhängigkeitsvertrauensgrenzen und eine sicherere Automatisierung erhalten. # npm v12 macht sicherere Installationen standardmäßig und zwingt JavaScript-Teams dazu, zu sagen, was sie tatsächlich vertrauen ## Was passiert ist Laut GitHub ist npm v12 jetzt allgemein verfügbar und wandelt mehrere Verhaltensweisen während der Installation in explizite Opt-Ins um. Lebenszyklusskripte wie „preinstall“, „install“ und „postinstall“ werden nicht mehr standardmäßig ausgeführt. Git-Abhängigkeiten werden nicht mehr automatisch aufgelöst, sofern dies nicht ausdrücklich erlaubt ist. Auch Remote-URL-Abhängigkeiten werden standardmäßig blockiert, es sei denn, ein Betreuer stimmt zu. ![NPM-Sicherheits-Änderungsprotokoll-Grafik](https://github.blog/wp-content/uploads/2026/07/617855414-178b5f87-1787-4f2e-87b4-04c457e2d875.jpg) *npm v12 wandelt mehrere riskante Installationsverhalten in Opt-In-Aktionen um und nicht in Standardverhalten.* Gleichzeitig hat GitHub damit begonnen, die sensibelsten Verwendungen von 2FA-Bypass-Granular-Zugriffstokens für npm abzulehnen. Diese Token verlieren die Fähigkeit, 2FA für sensible Konto- und Paketverwaltungsaktionen zu überspringen, und später verlieren sie auch die Fähigkeit, direkt ohne menschliche Zustimmung zu veröffentlichen. Dies ist eine bedeutende Änderung in der Philosophie. npm legt seit langem Wert auf Bequemlichkeit, auch wenn dies bedeutet, dass leistungsstarke Verhaltensweisen implizit während der Installation oder Automatisierung auftreten. v12 beginnt mit der Umstellung dieses Modells auf explizite Vertrauenswürdigkeit. ## Warum es wichtig ist Angriffe auf die Software-Lieferkette sind oft erfolgreich, weil Entwickler und CI-Systeme mehr ausführen, als ihnen bewusst ist. Im JavaScript-Ökosystem kann eine Paketinstallation Skripte auslösen, nativen Code kompilieren, von Git abrufen oder Remote-Artefakte auf eine Weise abrufen, die leicht zu vergessen und schwer in großem Maßstab zu prüfen ist. npm v12 ist wichtig, weil es besagt, dass diese Verhaltensweisen standardmäßig nicht mehr als sicher angesehen werden sollten. Das ist eine große Sache für Teams, die große Monorepos verwalten, auf komplexe Bäume von Drittanbietern angewiesen sind oder Builds in gemeinsam genutzten CI-Umgebungen ausführen. Die neuen Standardeinstellungen zwingen zu einer Diskussion, die viele Unternehmen aufgeschoben haben: Welche Verhaltensweisen während der Installation sind wirklich notwendig und welche sind lediglich historische Bequemlichkeit? Die Token-Änderungen sind aus demselben Grund wichtig. Langlebige Automatisierungsdaten, die 2FA umgehen können, sind leistungsstark und anfällig. Indem GitHub die Betreuer zu vertrauenswürdiger Veröffentlichung, gestaffelter Veröffentlichung und expliziter menschlicher Genehmigung für sensible Aktionen drängt, versucht es, den Explosionsradius der Token-Kompromittierung zu verringern. ## Technische Details Die v12-Standardeinstellungen wirken sich auf drei wichtige Oberflächen aus. Erstens werden Lebenszyklusskripte nicht mehr ausgeführt, es sei denn, dies ist zulässig. Dadurch wird einer der häufigsten versteckten Ausführungspfade bei der Paketinstallation direkt unterbrochen. Zweitens werden Git-basierte Abhängigkeiten standardmäßig blockiert, wodurch eine Route reduziert wird, die vorhersehbarere Registrierungsworkflows umgehen kann. Drittens werden auch Remote-Tarball- oder URL-Abhängigkeiten standardmäßig blockiert, wodurch ein weiterer Weg eingeschränkt wird, über den Inhalte außerhalb der normalen Paketkontrollen in einen Build gelangen können. GitHub empfiehlt, ausstehende Skripte mit Genehmigungstools zu überprüfen und dann die resultierende Zulassungsliste in „package.json“ zu übernehmen. Das ist ein operativer Hinweis darauf, wo npm das Ökosystem landen möchte: nicht in einer Welt ohne Skripte, sondern in einer Welt, in der die Skriptausführung dokumentiert und beabsichtigt ist. Auf der Authentifizierungsseite verlieren granulare Zugriffstoken, die zur Umgehung von 2FA konfiguriert sind, zunächst ihre Rolle bei der Verwaltung sensibler Konten und verlieren später auch die direkten Veröffentlichungsrechte. GitHub lenkt das Ökosystem eindeutig in Richtung OIDC Trusted Publishing oder Staged Publishing mit menschlichen Genehmigungsschritten. Das breitere technische Muster ist offensichtlich: Softwarebereitstellung deklarativer, überprüfbarer und weniger abhängig von Umgebungsvertrauen. ## Auswirkungen auf Markt und Branche Das JavaScript-Ökosystem ist so groß, dass sich Änderungen an den NPM-Standardeinstellungen über NPM selbst hinaus auswirken. Tool-Anbieter, Framework-Betreuer, CI-Anbieter, Sicherheitsteams und Unternehmensplattformgruppen müssen sich alle anpassen. Einige Projekte werden feststellen, dass sie stärker auf implizites Installationsverhalten angewiesen sind, als ihnen bewusst war. Kurzfristig kann sich das wie Reibung anfühlen. Mittelfristig handelt es sich um einen Aufräummechanismus. Teams, die den Übergang überleben, werden wahrscheinlich eine klarere Übersicht darüber haben, was ihre Builds tun und warum. Dies legt auch die Messlatte für Paketherausgeber höher. Wenn das Veröffentlichen zunehmend OIDC, inszenierte Werbung oder eine stärkere menschliche Zustimmung erfordert, dann ist sicheres Release-Engineering kein nettes Extra mehr, sondern wird zum entscheidenden Faktor. ## Worauf man als Nächstes achten sollte Beobachten Sie, welche beliebten Pakete und Build-Ketten zuerst kaputt gehen. Diese Fehler werden zeigen, wo das Ökosystem am meisten von verstecktem Installationszeitverhalten abhängig ist. Beobachten Sie die Einführung von Trusted Publishing. Wenn Betreuer schnell auf OIDC-basierte Abläufe umsteigen, wird die Sicherheitsoffensive von GitHub zeitlich gut abgestimmt und nicht nur störend wirken. Und beobachten Sie, wie andere Ökosysteme reagieren. Wenn es npm v12 gelingt, das Risiko zu reduzieren, ohne die Produktivität zu beeinträchtigen, fühlen sich möglicherweise mehr Paketmanager berechtigt, explizites Vertrauen anstelle einer freizügigen Automatisierung zum Standard zu machen. ## Quellen - [GitHub: npm-Installationszeitsicherheit und GAT-Bypass2fa-Veraltung](https://github.blog/changelog/2026-07-08-npm-install-time-security-and-gat-bypass2fa-deprecation/) - [GitHub: Kommende Breaking Changes für npm v12](https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/) - [GitHub: Gestaffelte Veröffentlichung und neue Installationszeitkontrollen für npm](https://github.blog/changelog/2026-05-22-staged-publishing-and-new-install-time-controls-for-npm/) Mentions: npm, GitHub, JavaScript, Sicherheit der Lieferkette, Vertrauenswürdige Veröffentlichung, OIDC ## Sources - [GitHub](https://github.blog/changelog/2026-07-08-npm-install-time-security-and-gat-bypass2fa-deprecation/) - [GitHub](https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/) - [GitHub](https://github.blog/changelog/2026-05-22-staged-publishing-and-new-install-time-controls-for-npm/)