Mit npm v12 schafft GitHub mehrere sicherheitskritische Standardeinstellungen des Node.js-Paketmanagers ab. Die für Juli 2026 angekündigte Hauptversion führt Installationsskripte aus Abhängigkeiten künftig nicht mehr automatisch aus. Auch Git- und Remote-Abhängigkeiten installiert npm nur noch, wenn Entwickler sie ausdrücklich freigeben. Damit will GitHub einen der wichtigsten Angriffswege in der Software-Lieferkette schließen: die automatische Codeausführung während eines npm install.

npm ist der Standard-Paketmanager des Node.js-Ökosystems und gehört zu den meistgenutzten Paketverwaltungen überhaupt. Moderne Anwendungen ziehen oft Hunderte oder Tausende direkte und indirekte Abhängigkeiten nach. Entsprechend groß ist die Angriffsfläche. Seit Jahren warnen Sicherheitsforscher vor Angriffen auf die Lieferkette, bei denen Schadcode über übernommene Pakete, gestohlene Maintainer-Konten oder manipulierte Installationsskripte in Entwicklungsumgebungen gelangt. Besonders gefährlich sind Mechanismen, die schon beim Installieren eines Pakets Code ausführen – oft, bevor Entwickler die Anwendung überhaupt gestartet haben.

Installationsskripte laufen nicht mehr automatisch

Genau hier setzt die wichtigste Neuerung von npm v12 an. Künftig führt der Paketmanager Installationsskripte aus Abhängigkeiten standardmäßig nicht mehr aus. Das betrifft die Lifecycle-Skripte preinstall, install und postinstall. Auch native Erweiterungen, die npm bislang automatisch über node-gyp kompiliert, baut der Paketmanager nicht mehr ohne Freigabe. Dasselbe gilt für bestimmte prepare-Skripte aus Git-, Datei- oder verlinkten Abhängigkeiten.

Bislang genügt ein einfaches npm install, um solche Skripte automatisch auszuführen. Viele Pakete nutzen den Mechanismus für legitime Zwecke, etwa um zusätzliche Binärdateien herunterzuladen oder native Komponenten zu kompilieren. Dieselbe Funktion gilt aber seit Jahren als attraktiver Angriffsweg: Über ein manipuliertes Installationsskript lässt sich Schadcode bereits während der Installation ausführen. Der Code kann zum Beispiel Umgebungsvariablen auslesen, Zugangsdaten abgreifen oder weitere Schadsoftware nachladen.

Freigaben per Allowlist

An die Stelle des automatischen Ausführens tritt ein Modell mit Freigabeliste. Entwickler bestimmen künftig selbst, welche Pakete ihre Installationsskripte ausführen dürfen. Diese Freigaben hinterlegt npm im Projekt, sodass Teams sie zusammen mit dem Quellcode versionieren können.

Wer früh umstellen will, kann das bereits tun: Schon npm 11.16.0 warnt vor Skripten, die der Paketmanager künftig blockiert. Mit dem Befehl npm approve-scripts --allow-scripts-pending lässt sich prüfen, welche Abhängigkeiten betroffen wären; mit npm approve-scripts lassen sich die vertrauenswürdigen Pakete anschließend freigeben.

Git- und Remote-Abhängigkeiten unter Vorbehalt

Auch beim Umgang mit Git-Abhängigkeiten zieht npm die Zügel an. Pakete, die direkt aus einem Git-Repository stammen, blockiert der Paketmanager künftig standardmäßig; Entwickler müssen solche Quellen ausdrücklich erlauben. GitHub begründet den Schritt mit einem Angriffsweg, über den sich aus einer Git-Abhängigkeit heraus Code ausführen ließ – selbst dann, wenn Installationsskripte eigentlich unterdrückt waren. Hinzu kommt, dass sich Git-Abhängigkeiten generell schwerer kontrollieren lassen als Pakete aus dem regulären npm-Registry.

Eine ähnliche Hürde gilt künftig für Remote-Abhängigkeiten, also Pakete, die direkt von einer URL stammen, etwa als TAR-Archiv per HTTPS. Auch sie installiert npm nur noch nach ausdrücklicher Freigabe. Solche Abhängigkeiten umgehen die übliche Registry-Infrastruktur und erschweren es, ihre Herkunft nachzuvollziehen. GitHub will so verhindern, dass externe Quellen unbemerkt in die Abhängigkeitskette geraten.

Was Entwickler jetzt tun sollten

Mehr Sicherheit bedeutet für Entwickler und Unternehmen zunächst mehr Aufwand. Wer bislang auf Installationsskripte, Git-Abhängigkeiten oder externe Paketquellen setzt, muss seine Build- und CI/CD-Prozesse prüfen und die nötigen Komponenten freigeben. GitHub rät, schon jetzt auf npm 11.16.0 oder neuer zu wechseln und die ausgegebenen Warnungen auszuwerten.

Alle Probleme der JavaScript-Lieferkette löst npm v12 allerdings nicht. Schadcode, der direkt im Anwendungscode eines Pakets steckt, gelangt weiterhin auf die Systeme. Auch kompromittierte Maintainer-Konten, Typosquatting oder verwundbare Bibliotheken fängt der neue Ansatz nicht ab. Für die Sicherheit von Entwicklungs- und Build-Umgebungen dürfte er dennoch eine der weitreichendsten Änderungen der vergangenen Jahre sein.

Weitere Details nennt GitHub im Changelog-Eintrag zu den anstehenden Breaking Changes für npm v12.

(fo)

Viele kleine und mittelgroße Unternehmen (KMU) stehen vor der Herausforderung, ihre IT-Infrastruktur für mobiles Arbeiten und Cloud-Dienste zu rüsten. Das lokale Active Directory (AD) und die Gruppenrichtlinienobjekte (GPOs) genügen dann nicht mehr als alleinige Kontrollinstanz. Eine moderne und zentrale Geräteverwaltung (Mobile Device Management, MDM) erfordert mehr als nur die Verlagerung von Daten und Anwendungen in die Cloud: Die Unternehmensdaten und die Endgeräte, auf denen sie abgelegt sind, müssen auch außerhalb des eigenen Netzwerks geschützt werden.

Microsoft hat sein MDM-Produkt Intune, das alle Arten von Endgeräten verwaltet, mittlerweile als Cloud-Angebot in die Business- und Enterprise-Pläne von Microsoft 365 (M365) integriert. Da immer mehr Kunden vom lokalen Office zum Cloud-Angebot wechseln, ist Intune für viele Firmen bereits Teil ihrer M365-Lizenz – ohne Mehrkosten. Administratoren müssen die Umstellung auf oder die Einführung von Intune sorgfältig planen.

Der Artikel vermittelt wichtige Grundinformationen zu Intune, Anwendungstipps sowie konkrete Schritte zur Umsetzung und zur Vermeidung von Fehlern.

Das war die Leseprobe unseres heise-Plus-Artikels „MDM aus der Cloud: So funktioniert der Umstieg auf Microsoft Intune“.
Mit einem heise-Plus-Abo können Sie den ganzen Artikel lesen.

Zunächst klang alles gut: Apples neues iPhone-Betriebssystem iOS 27 wird, im Gegensatz zu Gerüchten aus den vergangenen Wochen, für alle Modelle zur Verfügung stehen, die auch schon iOS 26 unterstützen. Das heißt: Ab iPhone 11 beziehungsweise 11 Pro und 11 Pro Max darf man mitmachen, beim iPhone SE geht es ab der zweiten Generation los (natürlich inklusive 16e und 17e). Es gibt allerdings ein wichtiges „Aber“: Die neuen KI-Funktionen sind je nach Gerät eingeschränkt, selbst beim iPhone 16, das Apple dereinst als „gemacht für Apple Intelligence“ beworben hatte.

Das beste On-Device-Modell

In der Praxis heißt dies, dass nur iPhone Air, iPhone 17 Pro und iPhone 17 Pro Max die stärksten On-Device-Modelle verwenden können. Der Grund: Nur diese Geräte verfügen über 12 GByte RAM. Gegenüber dem YouTuber Marques Brownlee teilte Apple allerdings mit, dass der einzige Unterschied bei der verbesserten (und vom Nutzer stärker konfigurierbaren) Siri-Stimme liege, die nur die neuen Geräte erhalten.

Zum Zweiten sollen die On-Device-Diktierfunktionen mit den Topgeräten besser sein. Was das in der Praxis heißt, bleibt abzuwarten. Einschränkungen bei Siri AI gibt es auch mit iPads, hier geht es erst bei Modellen mit M4-Chip los. Beim Mac muss es mindestens ein M3 sein, wenn dieser 12 GByte RAM oder mehr hat.

iPadOS 27, macOS 27 und watchOS 27

Bei den anderen Betriebssystemen hat Apple teilweise alte Zöpfe abgeschnitten, was für Besitzer dieser Geräte sehr unschön ist. Bei Mac fallen mit macOS 27 alle Intel-Modelle heraus, wie bereits erwartet worden war. Apple-Silicon-Macs laufen ab 2020 (Air, Pro, mini), Apple-Silicon-iMacs ab 2021, der Mac Studio mit Apple Silicon ab 2022 (also alle Varianten). Natürlich wird auch das MacBook Neo unterstützt. Beim iPad mini muss es mindestens Generation 6 sein, beim Standard-iPad Generation 9, beim Air mit 11 Zoll Generation 4 (13 Zoll alle Modelle) und beim iPad Pro Generation 2 (11 Zoll) beziehungsweise 4 (12,9 Zoll).

Apple-Watch-Besitzer müssen eine Enttäuschung erleben: Es geht mit watchOS 27 erst bei der Series 9 los, die 2023 erschienen war. Und, das dürfte viele überraschen, selbst die Ultra der ersten Serie aus dem Jahr 2022 ist draußen: Es muss stets eine Ultra 2 sein. Welche Gründe es dafür gibt (möglicherweise RAM-Ausstattung), ist noch unklar. Dass Apple gerade einmal vier Jahre alte Geräte nicht mehr mit dem neuesten Betriebssystem ausrüstet, ist jedenfalls ungewöhnlich und für Käufer auch verstörend. tvOS 27 beendet unterdessen ebenfalls den Support für zwei Modelle: Apple TV HD und Apple TV 4K der ersten Generation (von 2015 respektive 2017).

(bsc)