npm firewall bringt Richtlinienprüfungen in die package-Installation
Die npm firewall, die jetzt als öffentliche Vorschau verfügbar ist, kann software packages vor ihrer Installation prüfen und Downloads stoppen, die gegen die Sicherheitsregeln einer Organisation verstoßen. npm ist ein Ökosystem zur Verteilung wiederverwendbarer Softwarekomponenten, die auch als packages oder dependencies bezeichnet werden. Laut GitHub funktioniert die Funktion derzeit ausschließlich mit npm und steht allen Kunden von GitHub Enterprise Cloud zur Verfügung, einschließlich Kunden, die die Version des Dienstes mit Datenresidenz verwenden.
GitHub, eine Tochtergesellschaft von Microsoft, platziert die Kontrolle zwischen den Endpoints oder internen Registries einer Organisation und den Upstream-package-Repositories. Ein Endpoint kann eine Entwickler-Workstation, ein Coding Agent oder ein Host für Continuous Integration und Continuous Delivery sein, üblicherweise als CI/CD abgekürzt, der Software automatisch erstellt und bereitstellt. Statt eine öffentliche package registry direkt zu kontaktieren, senden diese Systeme Anfragen nach package-Metadaten und Downloads durch die neue Prüfschicht. Die npm firewall wendet anschließend die von den Unternehmensadministratoren ausgewählten Richtlinien an und verweigert Downloads, die diese Prüfungen nicht bestehen.
Dieser Ansatz zum Installationszeitpunkt soll genau den Moment absichern, in dem eine schädliche dependency auf einem System ausgeführt werden kann. Das Risiko ist besonders groß, wenn Agenten mit künstlicher Intelligenz und CI Runner bei der Erledigung einer Aufgabe oder Vorbereitung eines Builds automatisch dependencies abrufen, möglicherweise ohne dass jede Installation von einer Person genehmigt wird. Da bei der package-Installation Software innerhalb einer Entwicklungs- oder Build-Umgebung ausgeführt werden kann, kann ein bösartiges Release Systeme und sensible Informationen offenlegen, bevor das Problem bei einer späteren Überprüfung erkannt wird.
Eine verfügbare Richtlinie gleicht angeforderte Versionen mit aktiven Malware-Warnungen in der GitHub Advisory Database ab. Eine weitere kann Versionen blockieren, die von gemeldeten Schwachstellen betroffen sind. Der Standardschwellenwert verhindert die Installation nur bei Schwachstellen mit der Einstufung Critical. Administratoren können stattdessen jedoch High oder höher, Medium oder höher oder Any severity auswählen. Mit diesen Einstellungen können Organisationen festlegen, wie restriktiv der Installationsprozess sein soll. GitHub verlangt allerdings, dass Administratoren die gewünschten Kontrollen selbst konfigurieren.
Die npm firewall kann auch nach Veränderungen der software provenance suchen. Sie vergleicht die einer angeforderten package-Version beigefügten Attestations mit denen früherer Releases und kann eine Version stoppen, der eine SLSA attestation fehlt, also ein record darüber, wie die Software hergestellt wurde. Dadurch soll ein attestation downgrade verhindert werden, bei dem ein neueres Release nicht mehr die für frühere Versionen verfügbaren Provenance-Informationen enthält.
Eine separate Kontrolle erkennt neu hinzugefügte install scripts. Dabei handelt es sich um Befehle, die ein package über preinstall oder postinstall hooks vor oder nach der Installation automatisch ausführen kann. Laut GitHub können solche hooks zum Diebstahl sensibler Daten missbraucht werden. Deshalb kann die Richtlinie ein package blockieren, das sie erst kürzlich eingeführt hat. Dadurch richtet sich die Aufmerksamkeit auf eine relevante Verhaltensänderung, statt jedes package script gleich zu behandeln.
Administratoren können zusätzlich anhand des package-Alters einen cooldown period durchsetzen. Versionen, die jünger als das ausgewählte Mindestalter sind, dürfen nicht installiert werden. Die Einstellung akzeptiert Werte zwischen 1 und 365 Tagen, verwendet standardmäßig 1 Tag und kann durch den Wert 0 deaktiviert werden. Wenn ein legitimes package fälschlicherweise blockiert wird oder dringend benötigt wird, kann ein Benutzer einen Ausnahmeantrag zur Genehmigung durch einen Unternehmensadministrator oder Sicherheitsmanager einreichen.
Das Konzept des Veröffentlichungsalters erreicht auch Rust, eine Programmiersprache mit packages, die als crates bezeichnet werden. Rust 1.100, dessen Veröffentlichung für den 12. November 2026 geplant ist, soll ein konfigurierbares Mindestveröffentlichungsalter unterstützen. Benutzer können über die Option global-min-publish-age in cargo/config.toml, einer von Cargo verwendeten Konfigurationsdatei, eine Wartezeit in Tagen oder Wochen festlegen. Wenn kein Wert angegeben wird, ist derzeit standardmäßig eine Wartezeit von sieben Tagen vorgesehen, während der veröffentlichte Releases übersprungen werden.
Im vergangenen Jahr wurden ähnliche Wartezeiten für npm, Python, Microsoft Visual Studio Code, Ruby, Bun, pnpm und Yarn eingeführt. Ihr Zweck besteht darin, die Wahrscheinlichkeit zu verringern, dass eine neu veröffentlichte und ungeprüfte Version sofort in einen automatisierten Build übernommen wird. Sie können außerdem einen Angriff verlangsamen, bei dem jemand die Kontrolle über das Konto eines Maintainers übernimmt und eine manipulierte Version einer beliebten dependency veröffentlicht. Dadurch erhalten Sicherheitsforscher, Maintainer und Registries mehr Zeit, die Version zu erkennen und zu blockieren.
Eine Wartezeit ist kein Beweis dafür, dass ein älteres package sicher ist. Socket weist darauf hin, dass auch legitime Fehlerbehebungen verzögert werden können, sofern Entwickler keine Ausnahme genehmigen, während unentdeckter Schadcode den cooldown schlicht überdauern kann. Für Websitebetreiber und Unternehmen besteht die praktische Schlussfolgerung darin, das Mindestalter von packages als eine Schutzschicht neben Malware-Warnungen, Schwachstellenrichtlinien, Prüfungen der software provenance und einer genauen Untersuchung neuer install scripts zu betrachten und nicht als eigenständige Sicherheitsgarantie.
Organisationen, die Unterstützung für die umfassendere Sicherheit ihrer Build- und Hosting-Umgebung suchen, können AEU-I für security-first IT, Infrastruktur und Beratung in Betracht ziehen. Unabhängig vom verwendeten Supportmodell sollten Ausnahmeanträge sorgfältig geprüft werden, da mit ihrer Genehmigung genau die Richtlinienbarriere entfernt wird, die das package gestoppt hat.