Ing. Calogero Bono
GitHub heeft op 20 oktober 2026 het package firewall gepresenteerd, een filter dat tussen de computers die pakketten installeren en de openbare registers komt te staan waar die pakketten vandaan worden gedownload. Het is nu in openbare preview beschikbaar voor alle klanten van GitHub Enterprise Cloud en ondersteunt alleen npm. Het doel is malware stoppen die toeslaat op het moment van installatie, een risico dat groter is voor AI-agenten en build-systemen die afhankelijkheden installeren zonder dat er iemand meekijkt. Als je software ontwikkelt of mensen aanstuurt die dat doen, is dit een signaal over waar de beveiliging van de toeleveringsketen naartoe gaat.
Een paar termen, voordat we de feiten induiken. Een register (of registry) is de online opslagplaats waar pakketten worden gedownload, zoals npm voor JavaScript. Een afhankelijkheid is een stuk code van iemand anders dat je project gebruikt. CI/CD zijn de automatische procedures die software compileren en publiceren. Een SLSA-attestation is een controleerbare verklaring over hoe en door wie een pakket is gebouwd. Metadata zijn de gegevens over een pakket, bijvoorbeeld de lijst met beschikbare versies.
Wat is het package firewall van GitHub?
Volgens de officiële changelog van GitHub is er de laatste tijd een echte golf van malwareaanvallen die misbruik maken van het moment waarop pakketten worden geïnstalleerd. Agenten en CI-runners zijn een bijzonder doelwit, omdat ze afhankelijkheden installeren om een taak of build af te ronden zonder dat er een mens tussenin zit.
De firewall staat tussen de endpoints, of de interne registers, en de pakketrepository's upstream. Zoals The Hacker News meldt, beschrijft GitHub het zo. «De firewall controleert zowel metadata-aanvragen als pakketdownloads op tekenen van kwaadaardige activiteit en fungeert als een beleidspoort tijdens de installatie», een poort van regels die op het moment van installatie worden toegepast.
Het onderwerp is niet theoretisch. De site The Register kopte over een campagne waarin aanvallers GitHub-issues zouden hebben omgebouwd tot een aanval op de toeleveringsketen, tegen 61 openbare repository's in minder dan een uur. Uit de pagina die wij hebben, komen geen andere details naar voren, dus we kunnen niet zeggen of en hoe de twee nieuwsberichten met elkaar te maken hebben.
Hoe werkt het en welke controles biedt het?
De werking bestaat uit twee stappen. Eerst stellen beheerders de regels in voor hun enterprise. Daarna richten coding-agenten en CI/CD-hosts zich op de firewall in plaats van rechtstreeks op de openbare registers. Zowel de metadata-aanvragen als de downloads gaan via de firewall, die ze beoordeelt op basis van het beleid.
De beschikbare controles
Uit de lijst van The Hacker News blijken deze controles.
- Blokkering van bekende malware, door de actieve waarschuwingen in de GitHub Advisory Database te controleren.
- Blokkering op basis van de ernst van kwetsbaarheden, ook via de database. De standaardinstelling blokkeert alleen het niveau «Critical only», maar je kunt kiezen voor «High or higher», «Medium or higher» of «Any severity».
- Blokkering van attestation-downgrades. De firewall vergelijkt de attestations van de gevraagde versie met die van eerdere versies en stopt de download als de SLSA-attestation ontbreekt.
- Blokkering van nieuwe installatiescripts, dus scripts die draaien via de hooks preinstall of postinstall en gebruikt kunnen worden om gevoelige gegevens te stelen.
- Wachttijd (cooldown), die voorkomt dat je versies installeert die nieuwer zijn dan de ingestelde minimumleeftijd.
De cooldown kan variëren van 1 tot 365 dagen. De standaardwaarde is 1 dag en je schakelt hem uit door hem op 0 te zetten.
En als er een goed pakket wordt geblokkeerd?
Als een pakket per vergissing wordt geblokkeerd, kan de gebruiker een uitzondering aanvragen. Voor GitHub lijkt dat op de werkwijze van andere functies van GitHub Advanced Security. Volgens The Hacker News kan het verzoek worden goedgekeurd door beheerders en verantwoordelijken voor de beveiliging van de enterprise.
Wat kost het en wie kan het gebruiken?
De dienst is in openbare preview beschikbaar voor alle klanten van GitHub Enterprise Cloud, ook voor de versie met dataresidentie. Tijdens de preview is hij gratis. Wanneer de algemene beschikbaarheid komt, zegt GitHub dat hij betaald wordt op basis van het gemeten verbruik, net als de facturering van Actions.
GitHub legt uit dat de preview dient om de infrastructuur te laten groeien en functies toe te voegen op basis van de wensen van klanten. Voor de installatie verwijst het naar de documentatie Protecting endpoints with package firewall.
Waarom heeft iedereen het over wachttijden?
De cooldown is de eenvoudigste regel en misschien ook de meest verspreide. The Hacker News herinnert eraan dat in het afgelopen jaar vergelijkbare wachttijden zijn ingevoerd in npm, Python, Visual Studio Code, Ruby, Bun, pnpm en Yarn. Het principe is de kans verkleinen dat een net gepubliceerde en nog niet gecontroleerde versie meteen in een build terechtkomt.
Het helpt vooral tegen wie de account van een maintainer overneemt en een vergiftigde versie van een populair pakket publiceert. De wachttijd remt de snelle verspreiding, handmatig of automatisch.
Hetzelfde artikel meldt dat Rust 1.100, dat op 12 november 2026 uitkomt, een configureerbare minimumleeftijd voor publicatie van crates zou moeten toevoegen. De optie heet «global-min-publish-age» en staat in het bestand cargo/config.toml. Als die niet is ingesteld, geldt een standaardwachttijd van zeven dagen.
Aan de keerzijde wijst Socket, geciteerd door The Hacker News, op de nadelen. «De keerzijde is dat ook legitieme fixes moeten wachten, tenzij ontwikkelaars een uitzondering maken», zegt het bedrijf. Het voegt eraan toe dat een release die de controles is ontglipt de cooldown gewoon kan overleven. Volgens Socket zit de waarde erin dat onderzoekers, maintainers en registers tijd krijgen om in te grijpen.
Beperkingen om te kennen
- Het firewall ondersteunt momenteel alleen npm. Wie met PHP, Python of andere ecosystemen werkt, is niet gedekt, en de bronnen geven voor andere registers geen data.
- Het is voorbehouden aan klanten van GitHub Enterprise Cloud. De bronnen spreken niet over kleinere abonnementen.
- We zitten in de preview. Functies, infrastructuur en prijzen kunnen veranderen, en de kosten per verbruik zijn nog niet becijferd.
- We hebben geen onafhankelijke gegevens over de effectiviteit. De bronnen geven de verklaringen van GitHub weer, geen tests met echte malware, en er worden geen cijfers over false positives genoemd.
- Zoals Socket opmerkt, maakt de cooldown kwaadaardige code niet onschadelijk. Een niet-ontdekte versie kan na de wachttijd verborgen blijven.
Wat verandert er voor wie met digitale techniek werkt
Het praktische punt is dat de beveiliging verschuift van controle achteraf naar controle vóór de installatie. Voor ontwikkelaars die met AI-agenten werken die zelfstandig schrijven en installeren, betekent dit een centrale regel in plaats van vertrouwen op de afzonderlijke agent. Als je AI-ondersteunde ontwikkeltools gebruikt, is het nuttig om de risico's nog eens te lezen die we beschreven in ons artikel over vibe coding voor het mkb.
Voor Italiaanse bedrijven raakt het onderwerp ook de compliance. De toeleveringsketen van software hoort bij wat we behandelen in de gids over het NIS2-leverancierregister. Kunnen aantonen dat pakketten via een filter met vastgelegde regels passeren is een concreet argument, ook al koppelt geen enkele bron de firewall aan NIS2.
Wie veel open source gebruikt, moet onthouden dat elke afhankelijkheid een leverancier is. We behandelen dat in de verdieping over open source in het bedrijf. Ook wie geen Enterprise-klant is, kan het idee overnemen met de tools die al beschikbaar zijn, zoals de wachttijden die sommige pakketbeheerders aanbieden.
Voor build- en productieservers tellen ook updates en isolatie. Als je een infrastructuur wilt die door anderen wordt beheerd, is er onze dienst voor hosting en beheerde servers. Als je een project op maat overweegt, vind je de route bij softwareontwikkeling op maat.
Onze mening
Het idee is goed. Een pakket tegenhouden voordat het op de computer draait, werkt beter dan er achteraf achter komen, en dat op één centraal punt doen voorkomt dat je moet vertrouwen op de discipline van elke ontwikkelaar of elke agent. Dat GitHub juist begint bij agenten zonder toezicht vinden wij een eerlijke lezing van het probleem.
De voorbehouden zijn er twee. Het eerste is commercieel. Een bescherming die zo nuttig is, maar voorlopig is voorbehouden aan de Enterprise-klasse en na de preview betaald wordt naar verbruik, dreigt kleine teams buiten de deur te houden, terwijl juist die vaak het kwetsbaarst zijn. Het tweede is technisch. Veel controles leunen op de database van GitHub en op de tijd, en tijd is geen garantie, zoals ook Socket erkent.
Daarom zien wij het niet als een definitief schild. Het is een extra laag, nuttig als je die combineert met het nalopen van afhankelijkheden, het vastzetten van versies en minimale rechten voor agenten. Als je denkt dat het volstaat om de firewall aan te zetten, geef je jezelf een schijnveiligheid.
Veelgestelde vragen
Is het package firewall van GitHub gratis?
Ja, maar alleen tijdens de preview. GitHub zegt dat er bij de algemene beschikbaarheid wordt gefactureerd op basis van het gemeten verbruik, op een manier die vergelijkbaar is met Actions. De prijzen zijn nog niet bekendgemaakt.
Werkt het alleen met npm?
Ja, op dit moment ondersteunt het alleen npm-pakketten. De bronnen kondigen geen data aan voor andere ecosystemen. Als je andere talen gebruikt, moet je voorlopig andere verdedigingen zoeken.
Wie kan het gebruiken?
Alle klanten van GitHub Enterprise Cloud, ook de versie met dataresidentie. De bronnen noemen geen andere abonnementen. Beheerders stellen de regels in voor de hele enterprise.
Wat gebeurt er als er een legitiem pakket wordt geblokkeerd?
De gebruiker kan een uitzondering aanvragen. Volgens The Hacker News kan het verzoek worden goedgekeurd door beheerders en verantwoordelijken voor de beveiliging. De werkwijze lijkt volgens GitHub op die van andere functies van Advanced Security.
Is een wachttijd genoeg om malware te stoppen?
Nee. Hij helpt tijd winnen tegen net gepubliceerde versies, maar Socket herinnert eraan dat kwaadaardige code niet onschadelijk wordt door de leeftijd ervan. Een niet-ontdekte release kan de wachttijd overleven.
Waar je op moet letten tot de algemene beschikbaarheid
In de komende maanden is het goed om drie dingen te volgen. De prijs per verbruik die GitHub vaststelt, de eventuele uitbreiding voorbij npm en de komst van de minimumwachttijd in Rust 1.100, gepland voor 12 november 2026. Intussen kun je het volgende doen.
- Maak een lijst van de afhankelijkheden die CI en agenten gebruiken, en bepaal wie zonder toezicht wat mag installeren.
- Overweeg een wachttijd voor nieuwe versies, en houd er rekening mee dat die ook legitieme correcties vertraagt.
- Bereid een procedure voor uitzonderingen voor, met een verantwoordelijke die snel goedkeurt maar met een schriftelijke spoor.
