GitHub gaat beveiliging npm-packages versterken met verplichte 2fa en meer

GitHub gaat de beveiliging van npm-packages verscherpen om nieuwe supplychainaanvallen tegen te gaan. Het codeplatform gaat bijvoorbeeld 2fa verplichten voor het lokaal publiceren van npm-packages en ook het gebruik van bepaalde toegangstokens forceren.

GitHub meldt in een blogpost dat het platform proactieve beveiligingsmaatregelen gaat nemen rondom npm-packages. Het bedrijf doet dat na een golf van aanvallen op de npm-registry. De beveiliging van npm wordt onder andere versterkt met strengere verplichtingen voor authenticatie. Zo wordt twee-factorauthenticatie voortaan verplicht voor local publishing van npm-packages. Ook komen er granular tokens met een levensduur van maximaal zeven dagen, en wordt er door GitHub ingezet op trusted publishing.

In de komende tijd voert GitHub ook andere verbeteringen door om de bovenstaande beveiligingsmaatregelen bij te staan. Zo worden klassieke toegangstokens afgeschaft, in het voordeel van de eerdergenoemde granular tokens. Dat geldt ook voor 2fa op basis van totp-codes; in plaats daarvan moeten gebruikers overstappen op FIDO. Ook krijgen granular tokens met publicatierechten een kortere geldigheidsduur en komen er aanvullende beperkingen.

De maatregelen volgen op een reeks recente aanvallen, waarbij kwaadaardige code werd toegevoegd aan npm-packages, die gebruikt worden om stukken JavaScript-code mee te verspreiden. Eerder deze maand werden veelgebruikte npm-packages bijvoorbeeld geïnfecteerd met malware nadat hun maintainer werd gephisht. Tweakers schreef onlangs een achtergrondverhaal over npm-packages en waarom ze het doelwit zijn van hackers.

Reacties (13)

[Robtimus]

Ik snap dat dit gedaan wordt voor security, maar vanuit CI/CD oogpunt is dit onwerkbaar. We hebben een aantal workflows die ervoor zorgen dat na het afronden van een PR van de interne GitLab de code automatisch gepusht wordt naar GitHub, getagd, gebuild en gepublished. Al deze stappen gebeuren zoveel mogelijk intern en met credentials die zo kort mogelijk actief zijn. Dit is juist zo opgezet om zonder interactie te kunnen publishen. Dit zou nu dus elke 7 dagen een nieuw token nodig hebben. Aangezien er niet elke 7 dagen een release is betekent dat dus 1 van 2 dingen: of we krijgen falende builds omdat het token verlopen is, of we moeten elke 7 dagen het token roteren of we het nodig hebben of niet.

De package manager met de kortste token tijd die ik ken naast dit is NuGet. Daarbij moeten we 1x per jaar het token roteren, met waarschuwing vooraf dat het token gaat verlopen. Misschien is 12 jaar te lang, maar 7 dagen is wat mij betreft te kort. Die tokens zijn vooral gemaakt voor CI/CD flows, maar nu gaan ze dus de C hieruit een stuk lastiger maken.

[Oon]

Daar heb je toch gewoon een CI token voor? Die is altijd geldig, wordt automatisch aangemaakt en kun je ook niet zomaar achterhalen (tenzij je 'm echt gaat dumpen).
Het is absurd om voor die push acties niét een CI token te gebruiken, want dan zit je dus met een automatisch proces dat jouw eigen privétoken gebruikt

[Robtimus]

Als ik dit artikel goed lees dan worden juist die CI tokens aangepakt. Daar bestaan nu classic en granular tokens voor, en die eerste willen ze verwijderen en van de tweede veel eerder laten verlopen.

Maar ik zie net dat je per NPM package een trusted publisher kan toevoegen voor GitHub actions of GitLab CI/CD (zie ook https://docs.npmjs.com/trusted-publishers). Dat is iets waar we blijkbaar naartoe moeten. Gelukkig gebruiken we een van deze twee, maar dit is wel lastig te testen. Als je een andere CI/CD workflow hebt (b.v. Jenkins) dan heb je blijkbaar pech omdat de NPM UI geen opties heeft voor andere trusted publishers.

[Reactie gewijzigd door Robtimus op 23 september 2025 21:03]

[Oon]

Ah ik zie het inderdaad. Zo te zien is trusted publishing de oplossing, maar ik vraag me dan weer af op welke manier dat niet alsnog een SCA als attack vector toestaat.. Dan heb je wel een gelogde commit, maar het is niet alsof alle source repo's 24/7 in de gaten gehouden worden

[Blokker_1999]

Voor geautomatiseerde processen ga je uiteraard geen FIDO2 toepassen, maar daar bouw je een andere vorm van vertrouwen op. Geen idee hoe GitHub het technisch doet, maar een veelgebruikte manier is het uitwisselen van certificaten. Als je dan een goede hygiene hebt rondom je certificatenbeheer dan wordt het zeer moeilijk voor een aanvaller om de private key van zo een certificaat te stelen.

Tokens op zich zijn niet veilig omdat het puur een tekst gegeven is. Als dat geheim uitlekt dan is het weg. De private key van een certificaat zit daarentegen meestal veilig weg in het systeem niet exporteerbaar, of in sommige gevallen zelfs gewoon op een hardware module. Dan wordt het direct een heel stuk minder risicovol.

[Martinspire]

Jullie moeten om iets uit te rollen nieuwe NPM packages publishen naar de main npmjs.org registry? Dat vind ik wel apart. Want daar gaat het hier om. Ik denk dat je dan beter je eigen registry kunt gebruiken en vanuit daar je eigen authorizatieverplichtingen instellen.

Maar voor je eigen CICD pipeline gebeurt er dus helemaal niks met deze wijzigingen. Dit gaat alleen om publishen van nieuwe packages in die registry en dat mag inderdaad wel wat strenger. Verder vraag ik mij af of ze die authorisatie op alle repositories gaan verplichten, of dat het simpelweg de nieuwe standaard wordt en je er alsnog van af mag wijken bij een aantal settings. Ik zou zelf namelijk geen FIDO token willen zonder TOTP fallback oid.

Verder snap ik niet dat Github/NPM niet verplicht om een goedkeuring te geven via de website om een nieuwe versie te pushen. Waarom dat nog steeds allemaal via de commandline mag zonder verdere extra authenticatie snap ik niet helemaal. Het is niet alsof zo'n login niet misbruikt kan worden of zo. Zolang je login geldig blijft, maakt het geen reet uit of dat via 2FA of FIDO is ingelogd, lijkt mij?

[closefuture]

Daarbij moeten we 1x per jaar het token roteren, met waarschuwing vooraf dat het token gaat verlopen. Misschien is 12 jaar te lang, maar 7 dagen is wat mij betreft te kort.

Als je om de 7 dagen moet roteren dan word het de moeite waard om het te automatiseren. Je kunt kijken naar OpenBao (de opensource Hashicorp Vault fork).

[supersnathan94]

maar 7 dagen is wat mij betreft te kort.

Maar wat is dan lang genoeg?

want als je 30 dagen doet is het nog steeds handig om rollover te automatiseren, met 90 zelfde verhaal en met 180 wordt het al weer snel te lang.

maar neemt niet weg dat je niet meer zo snel wegkomt met wat gehannis met tokens, maar dat je echt wel een serieuze pipeline neer moet zetten met secret vaults en certificaat beheer.

[Martinspire]

Fijn om de stappen te zien, maar ik vind het nog steeds niet genoeg. Ik wil meer zekerheid dat de packages niet eens geaccepteerd worden in de registry als ze malware lijken te bevatten. Betere scanning en liever een optionele extra stap om packages te publishen nadat ze zijn klaargezet oid. En van veelgebruikte packages verwacht ik wel wat meer snelheid in het identificeren, dan wel verhelpen van false positives. Het duurt elke keer een paar uur voordat er ook maar enige activiteit is en dan is het al te laat. Bovendien geven ze vrijwel nooit aan welke malware het was, totdat het al genoeg systemen heeft geïnfecteerd. We zijn er nog lang niet vanaf.

[markg85]

Tot je een phising mail krijgt die er zo goed uitziet dat je erin trapt. Dat was de eerste van die recente problemen op npm. Ook deze github acties gaat daar helemaal niets aan veranderen en daarmee zijn de acties... voor de show en maken ze het gebruik ervan nog irritanter.

Als je deze beveiligingsproblemen echt wil oplossen denk ik dat je een systeem moet hebben waar een update eerst even een paar dagen in een hoekje moet sudderen voor het algemeen beschikbaar komt. Een phising hack voorkom je daar al mee. De developer van zijn software - die in dit geval zelf buitengesloten was - komt heel snel achter het probleem en kan dan "rustig" achter de schermen een oplossing zoeken. De gebruikers van die libraries merken nooit iets van een malafide pakket omdat het nooit de update heeft gehaald.

Nou is dit maar 1 factor en een oplossing daarvoor. Maar gezien de recente hacks zou dit wel heel wat oplossen. Een nieuw probleem wat je dan weer krijgt is toch opzettelijk het "even sudderen" systeem omzeilen wanneer je een kritiek 0-day beveiligingslek op wil lossen.

[svane]

Tot je een phising mail krijgt die er zo goed uitziet dat je erin trapt.

Het uitfaseren van TOTP is juist een hele goede manier om phishing een kleinere kans van slagen te geven.

Deprecate time-based one-time password (TOTP) 2FA, migrating users to FIDO-based 2FA.

Met Passkeys / FIDO-based 2FA is het überhaupt niet mogelijk om je 2FA 'code' te delen met de verkeerde website met de verkeerde domeinnaam, hoe goed de phishing mail ook is!

Voor zeker een aantal van de gehackte developers geldt dat ze met gebruik van passkeys niet in de problemen geraakt zouden zijn!

De andere oplossingen dragen ook bij aan de veiligheid. De kans wordt nooit 0 procent, maar alles helpt.

[supersnathan94]

Met Passkeys / FIDO-based 2FA is het überhaupt niet mogelijk om je 2FA 'code' te delen met de verkeerde website met de verkeerde domeinnaam, hoe goed de phishing mail ook is!

Voor zeker een aantal van de gehackte developers geldt dat ze met gebruik van passkeys niet in de problemen geraakt zouden zijn!

Dat zou ik niet te hard roepen. Het proces zelf is namelijk nog steeds vatbaar voor attacks

FIDO was designed to prevent these attacks. However, when implementing this modern authentication method, most applications do not protect the session tokens created after authentication is successful. I discovered many identity providers are still vulnerable to MITM and session hijacking attack types.  

https://www.silverfort.com/blog/using-mitm-to-bypass-fido2/#:~:text=FIDO%20was%20designed%20to%20prevent%20these%20attacks.,method%2C%20most%20applications%20do%20not%20protect%20the

Staan daar een paar interessante voorbeelden waar eigenlijk blijkt dat dit ook op grote schaal te misbruiken is doordat bijvoorbeeld entra ID met OIDC er voor zorgt dat FIDO gelimiteerd wordt in de beveiliging waardoor je uiteindelijk een token krijgt die je kunt gebruiken om weer tokens te genereren.

En wéér schrik hier van de rol van MS hierin:

We can see in the following example that the native Azure Management portal application does not validate the token granted by the SSO. 

Wat?

Even though FIDO protects against MITM attacks, the whole chain relies on its weakest links, which are the SSO protocols where their granting tokens can be reused by a different device. 

Uiteindelijk hebben ze het wel opgelost, maar dan

I initially conducted this research in Mid-2023, and submitted the findings to Microsoft. In response to initial disclosure, Microsoft claimed this is not a vulnerability. Even so, it is an attack surface that could cause damage to an exposed organization. Four months later, Microsoft presented a conditional access preview of Token Protection,which is a variant of token binding specifically for Trusted Platform Module (TPM).

Nou helemaal top toch? Lekkere implementatie, handig dat dit dan sinds 2024 mooi opgelost is.

To date, Microsoft EDGE is the only browser that offers Token Binding.  Chrome offered Token Binding but removed it due to low adoption.

🤦🏿‍♂️ fricking Chrome.


Ik heb nog niet vaker zo’n goede uiteenzetting gelezen. Zeker de moeite waard. Legt het probleem heel begrijpelijk uit.

[alienfruit]

Of je gebruikt PNPM icm de `minimumReleaseAge`-optie