Elke npm install, pip install of Maven-build haalt code van mensen die u nooit hebt ontmoet uw product binnen. In maart 2026 publiceerde ENISA het Technical Advisory for Secure Use of Package Managers, een korte, praktische gids om dat veilig te doen. Dit artikel vat het advies samen en voegt een paar notities uit ons eigen SCA-werk toe.
Wat het advies behandelt
Het advies is versie 1.1. Het is herzien na een consultatie tussen december 2025 en januari 2026 die 15 bijdragen opleverde, en het valt onder de licentie CC BY 4.0.
De scope is bewust smal: het gebruiken van packages en het beheren van dependencies op applicatieniveau. Package managers van besturingssystemen, het veilig publiceren van packages, de beveiliging van de registries zelf en secure coding vallen erbuiten. De voorbeelden gebruiken vooral npm en GitHub, maar de principes gelden voor elk ecosysteem.
U installeert meer dan u denkt
Het advies begint met een eenvoudig voorbeeld. Een Node.js-webserver van tien regels met het framework express haalt ongeveer 27 directe dependencies binnen, en 68 packages in totaal zodra de transitieve dependencies zijn opgelost. Elk daarvan is nu onderdeel van uw product.
ENISA maakt daarover twee punten die het herhalen waard zijn:
- Code van derden is niet meer van iemand anders zodra ze in uw build zit. Ze wordt deel van uw vertrouwde codebase en verdient dezelfde kritische blik als uw eigen code.
- Geïnstalleerde code is niet hetzelfde als bereikbare code. Uw applicatie voert misschien maar een klein deel van een package uit. Een kwetsbaarheid in code die nooit wordt uitgevoerd, is minder waarschijnlijk uit te buiten, maar “niet direct bereikbaar” is geen garantie: reflectie, verkeerde configuratie of gemanipuleerde invoer kunnen onverwachte paden openen.
Dezelfde verwevenheid die package managers nuttig maakt, verspreidt ook problemen. Bijna 100.000 packages zijn direct afhankelijk van express, en het zijn er ruim een miljoen als u transitief gebruik meetelt.
Twee soorten risico
ENISA deelt de risico’s van het gebruik van packages in twee categorieën in.
Packages met ingebouwde kwetsbaarheden
De eerste categorie zijn zwakheden in de packages zelf: onveilige code of een onveilig ontwerp, te ruime standaardinstellingen of openstaande debugmodi. Die komen in uw aanvalsoppervlak terecht, ook al hebt u ze niet zelf geschreven.
Niet-onderhouden packages maken het erger. De voorbeelden uit het advies:
- node-serialize: de laatste versie, elf jaar geleden uitgebracht, heeft een bekende kritieke kwetsbaarheid bij deserialisatie. De enige oplossing is het package niet gebruiken, en toch wordt het nog wekelijks gedownload.
- tokio-tar: de kwetsbaarheid “TARmageddon” kwam uit deze verlaten Rust-library, jaren nadat het onderhoud was gestopt.
- crypto-js: volgens de eigen repository stopgezet, maar nog steeds miljoenen keren per week gedownload.
Supplychainaanvallen
De tweede categorie zijn aanvallen waarbij iemand een leverancier compromitteert om diens klanten te bereiken:
| Aanval | Hoe het werkt | Voorbeelden uit het advies |
|---|---|---|
| Kwaadaardige packages | Een aanvaller publiceert een nieuw package met kwaadaardige code en wacht tot ontwikkelaars het installeren, direct of als transitieve dependency. | crypto-encrypt-ts; GlassWorm-malware in VS Code-extensies |
| Gecompromitteerde legitieme packages | Een aanvaller krijgt publicatierechten via een gestolen of via social engineering verkregen maintaineraccount, of een maintainer keert het package tegen de eigen gebruikers. | event-stream, ua-parser-js, de npm-aanval van september 2025 op 18 packages met 2,6 miljard downloads per week, colors en faker |
| Typosquatting | Een kwaadaardig package met een naam die lijkt op die van een populair package, wachtend op een tikfout. | crossenv dat zich voordoet als cross-env |
| Dependency confusion | Een publiek package met dezelfde naam als een intern package en een hoger versienummer, opgepikt door buildtools die beide registries raadplegen. | Het onderzoek uit 2021 dat tientallen grote bedrijven bereikte |
In beide gevallen werkt het effect door. Het advies wijst op CVE-2025-55182 in React, met een CVSS-score van 10,0, die eerste schattingen in verband brachten met meer dan 12 miljoen websites.
Vier fasen in het gebruik van packages
De kern van het advies is een eenvoudige levenscyclus voor elke dependency: selecteren, integreren, monitoren en mitigeren. De eerste twee fasen bouwen beveiliging in, de laatste twee houden haar op peil. Voor elke fase geeft ENISA aanbevelingen en een cheatsheet met voorbeeldcommando’s.
1. Selecteren: kies betrouwbare packages
Vraag u eerst af of u het package wel nodig hebt. Minder dependencies betekent een kleiner aanvalsoppervlak en minder beheer. Controleer daarna:
- dat het uit een officiële registry komt, bij voorkeur gepubliceerd via een veilige workflow met provenance, zoals Trusted Publishing van npm
- de bekende kwetsbaarheden, in OSV, de EU Vulnerability Database (EUVD), de NVD of een commerciële database
- dat package en registry handtekeningen en integriteitshashes ondersteunen, en dat u niet rechtstreeks installeert uit een Git-repository of tarball-URL die die controles omzeilt
- de maintainers: wees voorzichtig met packages van nieuwe accounts met maar één project
- tekenen van actief onderhoud: recente commits, getagde releases, afgehandelde issues, een SECURITY.md-bestand. ENISA waarschuwt dat sterren en downloadaantallen kunnen worden opgeblazen en niet als enige maatstaf moeten dienen.
- installatiescripts die extra code of binaries van externe URL’s downloaden
Bijvoorbeeld met npm:
npm audit signatures # handtekeningen en provenance controleren
npm view <package> scripts # zoeken naar pre- en post-installscripts
npm view <package> maintainers
npm ls --all # de volledige dependencyboom bekijkenENISA raadt ook aan om waar mogelijk een interne allowlist van goedgekeurde packages of maintainers bij te houden.
2. Integreren: houd onder controle wat u installeert
- Genereer bij elke build een SBOM, zodat u voor beveiliging en compliance een overzicht hebt van elke dependency.
- Laat de build falen als die componenten met bekende hoge of kritieke kwetsbaarheden bevat.
- Dwing integriteit af: npm controleert de SHA-512-hashes in de lockfile automatisch; pip heeft daarvoor
--require-hashesnodig. - Beperk installaties tot vertrouwde registries, het liefst via een lokale registry of proxy zoals Nexus Repository, JFrog Artifactory of Verdaccio. Een cachende proxy houdt uw builds ook draaiende als een package upstream verdwijnt.
- Schakel installatiescripts uit waar dat kan, en accepteer dat sommige packages dan niet werken.
- Pin versies met een gecommitte lockfile en gebruik die in CI (
npm ci). Lees changelogs voordat u upgradet.
npm ci --ignore-scripts # precies de lockfile installeren, zonder installatiescripts
npm audit --omit=dev --audit-level=high # falen bij hoge of kritieke bevindingen
pip install --require-hashes -r requirements.txtENISA benoemt de afweging bij pinnen: het beschermt u tegen niet-beoordeelde updates, maar verlengt uw blootstelling aan bekende kwetsbaarheden als niemand regelmatig updates beoordeelt en doorvoert. Het advies noemt ook een optionele, situationele maatregel: installeer alleen versies die ten minste een paar dagen geleden zijn gepubliceerd. Dat geeft de community tijd om een kwaadaardige release op te merken voordat die uw build bereikt.
3. Monitoren: merk het op als er iets verandert
Dependencies die veilig waren op de dag dat u ze toevoegde, blijven dat niet. ENISA raadt aan om:
- SBOM-gegevens te gebruiken voor continue kwetsbaarheidscontroles, bijvoorbeeld met Grype of OSV-Scanner
- dependencies volgens een schema in CI te scannen, niet alleen als de code verandert
- kwetsbaarheidsfeeds te volgen, zoals EUVD, OSV en de NVD, en machineleesbare advisories van leveranciers in CSAF
- verouderde versies in de gaten te houden
- meldingen in te stellen voor nieuwe CVE’s in vastgepinde versies, deprecated of niet-onderhouden releases, gebrek aan activiteit van maintainers en wisselingen van maintainer of eigenaar
Die laatste groep wordt makkelijk over het hoofd gezien. Een nieuwe maintainer was het startpunt van de event-stream-aanval, en weinig teams letten op eigendomswisselingen.
4. Mitigeren: beoordeel voordat u herstelt
Het advies is verfrissend eerlijk over SCA-bevindingen. Een kwetsbare versie in uw dependencyboom betekent dat het package code bevat die onder specifieke omstandigheden kan worden uitgebuit. Het betekent niet automatisch dat uw applicatie kwetsbaar is.
De stappen van ENISA voor mitigatie:
- Beoordeel de bevinding met meer dan alleen de CVSS-score: EPSS voor de kans op uitbuiting, de Known Exploited Vulnerabilities-catalogus van CISA, VEX-verklaringen van de leverancier en bereikbaarheidsanalyse met tools zoals CodeQL of Semgrep.
- Prioriteer aan de hand van een vastgestelde risicodrempel, bijvoorbeeld “CVSS 7,0 of hoger, of EPSS 0,3 of hoger, is hoge prioriteit”, en richt u op bereikbare, uitbuitbare kwetsbaarheden in productiedependencies.
- Mitigeer door te upgraden, een tijdelijke maatregel te nemen zoals een WAF-regel of feature flag, of het package te verwijderen, terug te draaien of te isoleren als er geen oplossing is.
- Documenteer en informeer: leg een VEX-status vast (affected, not affected, under investigation of fixed), genereer de SBOM opnieuw, werk de release notes bij en informeer waar nodig klanten, autoriteiten of interne teams.
Automatisering en AI-ondersteund ontwikkelen
Het advies sluit af met twee vooruitblikken. Handmatige controles schalen niet naar honderden dependencies in veel repositories, dus SBOM-generatie (Syft, CycloneDX), scanning (Grype, OSV-Scanner) en installatiecontroles horen in de CI/CD-pipeline.
En AI-codeassistenten veranderen wie dependencies kiest. Als code wordt gegenereerd met weinig menselijke review, weet misschien niemand waarom een package is toegevoegd. ENISA noemt “slopsquatting”: aanvallers die packagenamen registreren die AI-tools verzinnen. Het advies: houd zicht op elk package dat AI-gegenereerde code introduceert, beoordeel of elk package nodig is, automatiseer de controles bij selectie en integratie, en versterk detectie en respons om de verminderde controle vooraf te compenseren.
Waarom dit belangrijk is voor de CRA
De Cyber Resilience Act maakt veel hiervan verplicht voor fabrikanten. Ze moeten zorgvuldigheid betrachten bij het integreren van componenten van derden, opensource inbegrepen, een SBOM opstellen en kwetsbaarheden in de componenten die ze leveren gedurende de hele ondersteuningsperiode opsporen en verhelpen. Het advies noemt de CRA niet bij naam, maar de vier fasen lezen als een praktische uitwerking van die verplichtingen. Onze CRA-gids voor het mkb behandelt ze uitgebreid.
Onze kijk
Voor teams die met npm, Python of Java werken, is dit een goede checklist om naast de CI-pipeline te leggen. Het is kort en concreet, en de cheatsheets maken van elke aanbeveling een commando dat u vandaag kunt uitproberen. Het hoofdstuk over mitigatie verdient extra aandacht: teams die elke SCA-bevinding even urgent behandelen, raken uitgeput door false positives en missen de paar die ertoe doen.
Twee kanttekeningen. De voorbeelden zijn sterk op npm gericht; volgens het advies gelden de principes ook elders, en dat klopt, maar u moet de equivalente maatregelen in uw eigen ecosysteem zelf vinden. En C en C++ komen helemaal niet aan bod, terwijl ze hun eigen probleem hebben: SBOM-componenten missen vaak de identifiers die kwetsbaarheidsdatabases nodig hebben. Ons artikel over CPE-verrijking voor C++-libraries in Conan-builds vult dat gat, en onze handleiding voor het deployen van OWASP Dependency-Track laat een manier zien om SBOM-gestuurde monitoring in te richten. Over SBOM’s in het algemeen schreven we een overzicht van het ENISA-advies over software bills of materials.
ENISA benadrukt ook dat de genoemde tools voorbeelden zijn, geen aanbevelingen. Het gaat om de maatregel, niet om het merk.