GitHub heeft aangekondigd dat het een nieuwe pakket-firewall als preview introduceert om de installatie van verdachte npm-pakketten tijdens de installatietijd te blokkeren.
“De firewall onderzoekt zowel metadata-aanvragen als pakketdownloads op tekenen van kwaadaardige activiteit en fungeert als een beleidspoort tijdens installatie,” zei GitHub.
De functie, die momenteel alleen npm-pakketten ondersteunt, is in openbare preview beschikbaar voor alle GitHub Enterprise Cloud-klanten, inclusief GitHub Enterprise Cloud met lokale gegevensresidentie.
Volgens de Microsoft-dochter wordt de firewall geplaatst tussen endpoints of interne registries en de upstream-pakketrepositories om malware-aanvallen te ontmoedigen die systemen compromitteren wanneer pakketten worden geïnstalleerd.
Dergelijk gedrag kan gebruikers aan ernstige beveiligingsrisico’s blootstellen, vooral wanneer kunstmatige intelligentie (AI)-agents en CI-runners automatisch afhankelijkheden installeren om een taak of build te voltooien zonder hun expliciete toestemming.
Het idee is dat endpoints zoals codeeragents en CI/CD-hosts de firewall gebruiken voor hun verzoeken in plaats van rechtstreeks naar de openbare pakketregistries te verwijzen. De firewall controleert vervolgens pakketdownloads aan de hand van beleidscontroles zoals minimale leeftijd van het pakket en malware-advertenties, en blokkeert downloads die niet aan die beleidsregels voldoen.
Om de firewall te gebruiken moeten beheerders beleidscontroles configureren, zoals de onderstaande opties –
- Blokkeer bekende malware door te controleren aan de hand van de GitHub Advisory Database op actieve malware-adviezen.
- Blokkeer pakketten op basis van de ernst van kwetsbaarheden door de GitHub Advisory Database te raadplegen op fouten die de gevraagde pakketversie beïnvloeden. De standaardinstelling blokkeert alleen “Kritieke” kwetsbaarheden als drempel om een installatie te blokkeren, maar gebruikers kunnen kiezen voor “Hoog of hoger”, “Medium of hoger” of “Elke ernst”.
- Blokkeer attestation-downgrades door attestaties voor de gevraagde pakketversie te vergelijken met die van eerdere versies en de download te stoppen als de gevraagde versie geen SLSA-attestatie heeft.
- Blokkeer nieuw geïntroduceerde installatiescripts door te controleren of het pakket recent scripts heeft toegevoegd die worden uitgevoerd via preinstall- of postinstall-hooks, die misbruikt kunnen worden om gevoelige gegevens te stelen.
Blokkeer pakketten op basis van een cooldown-periode die voorkomt dat versies die jonger zijn dan de geconfigureerde minimale leeftijd geïnstalleerd worden. De waarde kan variëren van 1 tot 365 dagen. De standaardwaarde is 1 dag. Gebruikers kunnen het uitschakelen door de waarde op 0 te zetten.
Gebruikers die toegang nodig hebben tot een pakket dat ten onrechte door de firewall wordt geblokkeerd, kunnen een uitzondering aanvragen, die vervolgens goedgekeurd kan worden door enterprise-beheerders en securitymanagers.
De ontwikkeling komt terwijl Rust 1.100, dat gepland staat voor release op 12 november 2026, zich voorbereidt op het toevoegen van ondersteuning voor een configureerbare minimale publicatieleeftijd. Dat stelt beveiligingsscanners en maintainers in staat om tijd te krijgen om kwaadaardige crate-releases te signaleren en te blokkeren voordat ze door gebruikers geïnstalleerd of gebruikt kunnen worden.
De waarde, gedefinieerd via de optie “global-min-publish-age” in “cargo/config.toml”, stelt gebruikers in staat een minimale publicatieleeftijd in dagen of weken op te geven. Als niets wordt opgegeven, geldt standaard een wachttijd van zeven dagen waarin releases die binnen dat venster zijn gepubliceerd worden overgeslagen.
Afgelopen jaar zijn vergelijkbare wachttijden geïmplementeerd in open-source-ecosystemen, waaronder npm, Python, Microsoft Visual Studio Code, Ruby, Bun, pnpm en Yarn, als manier om de beveiliging van de softwareleveringsketen te versterken door de kans te verkleinen dat een nieuw gepubliceerde, ongereviewde versie direct in een build wordt opgenomen.
Cooldown-periodes helpen frictie toe te voegen en vertragen aanvallen waarbij een kwaadwillende partij een vergiftigde versie van een populair pakket publiceert nadat een maintainer-account is overgenomen, waardoor een snelle verspreiding via handmatige of geautomatiseerde installaties wordt voorkomen.
“Het nadeel is dat legitieme fixes ook moeten wachten, tenzij ontwikkelaars een uitzondering maken,” zei Socket. “Kwaadaardige code wordt ook niet magisch onschadelijk met de tijd. Een release die detectie ontloopt, kan simpelweg de cooldown overleven. De waarde zit in het kopen van tijd voor onderzoekers, maintainers en registries om te handelen voordat de volgende dependency-update een aanval verder verspreidt.”
