GitHub introduceert een npm firewall als preview. Het idee is simpel maar effectief: verdachte npm-pakketten moeten geblokkeerd worden tijdens het installatieproces, nog voordat ze echt binnen je build of omgeving terechtkomen. Daarmee verschuift de beveiliging van “achteraf detecteren” naar “vooraf tegenhouden”.
Vooral organisaties die afhankelijk zijn van geautomatiseerde installaties via CI/CD of AI-agents merken hier direct het voordeel. Zij installeren immers vaak dependencies om taken af te ronden, zonder dat er telkens handmatig toestemming wordt gegeven per package.
Wat doet de npm firewall precies?
De npm firewall werkt als een install-time policy gate. GitHub geeft aan dat de firewall niet alleen metadata-afspraken bekijkt, maar ook de daadwerkelijke pakketdownloads inspecteert. Staat een verzoek niet (meer) binnen de ingestelde beleidsregels, dan wordt de download tegengehouden.
De feature is momenteel alleen beschikbaar voor npm en wordt aangeboden in publieke preview voor alle GitHub Enterprise Cloud-klanten. Ook in scenario’s met data-resident GitHub Enterprise Cloud moet de firewall inzetbaar zijn.
Waar komt de firewall in je installatiestroom?
GitHub positioneert de firewall tussen endpoints of interne registries en de upstream package repositories. In plaats van dat systemen rechtstreeks naar de publieke npm-registers wijzen, sturen ze hun installatiestappen via de firewall.
Dat betekent dat de firewall als “tussenlaag” kan controleren of een pakket voldoet aan jullie security-eisen. Zo ontstaat er extra controle op het moment dat het risico op besmetting het grootst is: wanneer een nieuw package wordt opgehaald en geïnstalleerd.
Waarom is dit extra relevant voor AI-agents en CI-runners?
De afgelopen tijd is duidelijk geworden dat aanvallen op software supply chains niet altijd via menselijke klikken beginnen. Veel moderne workflows werken met bots: AI-agents die opdrachten afronden, CI-runners die automatisch bouwen, en tooling die dependencies in één run toevoegt.
Juist in zulke omgevingen kan een kwaadaardig package snel “door de pijplijn” glippen—zeker als het beheer pas later ontdekt wordt. Door beleid toe te passen vóór installatie, helpt de npm firewall om het automatische pad van een compromis te doorbreken.
Welke beleidscontroles kun je instellen?
Administrators moeten beleidsregels configureren. GitHub noemt daarbij meerdere typen controles. Een deel daarvan richt zich op bekende dreigingen, andere op kwetsbaarheidssituaties of op specifieke kenmerken die misbruik kunnen faciliteren.
1) Blokkeer bekende malware via advisories
Een controle kan bekende malware tegenhouden door te vergelijken met de GitHub Advisory Database voor actieve malware-advisories. Pakketten die matchen met bekende malware worden dan geblokkeerd.
2) Blokkeer pakketten met kwetsbaarheden boven een drempel
Ook kun je pakketten blokkeren op basis van de ernst van kwetsbaarheden die relevant zijn voor de gekozen packageversie. Standaard staat dit op “Critical only”. Je kunt dit aanpassen naar “High or higher”, “Medium or higher” of “Any severity”.
3) Detecteer en blokkeer “attestation downgrades”
De firewall kan bovendien attestation-gegevens vergelijken tussen de gevraagde packageversie en eerdere versies. Als de versie in kwestie geen SLSA-attestatie heeft waar je op rekent, kan de download worden gestopt.
4) Stop install-scripts die recent zijn toegevoegd
GitHub noemt ook een controle op nieuw geïntroduceerde install-scripts. Daarbij kijkt de firewall of een package recent scripts bevat die kunnen draaien via preinstall of postinstall-hooks. Zulke hooks kunnen namelijk worden misbruikt om gevoelige data te stelen.
5) Gebruik een cooldown of minimum publish age
Daarnaast kun je een cooldownperiode toepassen: pakketten die “te nieuw” zijn volgens jullie minimale publicatieduur, mogen niet geïnstalleerd worden. Het bereik loopt van 1 tot 365 dagen, met een standaard van 1 dag. Zet je dit op 0, dan kun je de cooldown uitzetten.
Wat gebeurt er als een package onterecht geblokkeerd wordt?
GitHub voorziet in een praktische uitweg: als je een package nodig hebt dat ten onrechte wordt geblokkeerd, kun je een exception request indienen. Die aanvraag kan vervolgens worden goedgekeurd door enterprise administrators en security managers.
Dat is belangrijk omdat beveiliging en ontwikkeling niet altijd netjes synchroon lopen. Een goed proces voor uitzonderingen voorkomt dat teams werk omzeilen of policy’s “tijdelijk” uitzetten.
Cooldown als supply chain-frictie: helpt het echt?
Cooldownperioden zijn niet nieuw als concept. GitHub verwijst naar het bredere idee dat vergelijkbare wachttijden in verschillende open-source ecosystemen zijn ingevoerd, om de kans te verkleinen dat een net gepubliceerde, nog niet beoordeelde versie direct in builds terechtkomt.
Het uitgangspunt is dat je aanvallers minder snel voordeel laat trekken uit incidenten, zoals een compromitterde maintainer. Tegelijk erkent GitHub ook de keerzijde: legitieme fixes moeten ook wachten, tenzij developers uitzonderingen aanvragen.
Rust 1.100 en minimum publish age: parallel met security supply chain
In dezelfde aankondiging noemt GitHub een ontwikkeling rond Rust 1.100 (voorzien op 12 november 2026). Daarbij komt ondersteuning voor een configureerbare minimum publish age via een optie zoals global-min-publish-age in cargo/config.toml.
Als je die waarde niet instelt, wordt volgens de brontekst standaard een wachttijd van zeven dagen gehanteerd. Zo krijgen security scanners en maintainers tijd om releases te signaleren voordat updates massaal door dependencies worden opgehaald.
Praktische impact voor organisaties
Als je nu al sterk leunt op geautomatiseerde dependency-installaties, dan is de npm firewall vooral interessant omdat je een extra controlelaag krijgt op het install-moment. In plaats van uitsluitend te vertrouwen op after-the-fact scanning, kun je een deel van het risico vroeg afvangen.
Toch is het geen “zet en klaar” maatregel. Je zult beleid moeten afstemmen op je omgeving: welke severity drempels gelden, hoe strikt je de cooldown wilt instellen, en wat je doet wanneer teams een legitieme dependency nodig hebben die eerst geblokkeerd wordt.
Een logische eerste stap is om beleid geleidelijk uit te rollen en uitzonderingsroutes goed te organiseren, zodat beveiliging niet ten koste gaat van ontwikkelsnelheid.
Conclusie
Met de npm firewall zet GitHub een duidelijke stap richting install-time software supply chain security. Door tijdens metadata en downloads beleid toe te passen—bijvoorbeeld op malware-advisories, kwetsbaarheidsscores, attestation en nieuw install-script gedrag—kun je verdachte packages blokkeren voordat je builds ze installeren.
Voor teams met CI/CD en AI-agents die automatisch dependencies binnenhalen, kan deze aanpak helpen om incidenten sneller te stoppen. De echte waarde zit in een combinatie van goede beleidsinstellingen, duidelijke uitzonderingen en een gecontroleerde uitrol in je ontwikkelproces.
Gerelateerd: als je ook kijkt naar aanvallen en mitigaties rond dependency- en packageketens, lees dan eens PHP2Shell keten: root op firewalls, let op voor inzicht in hoe ketenrisico’s in security vaak verspreid worden.
Bron: https://thehackernews.com/2026/10/github-launches-npm-firewall-to-block.html
