Open source zit in bijna elke codebase. Synopsys meldde in 2024 dat 96% van de onderzochte codebases open source componenten bevatte, en 84% daarvan had minstens één bekende kwetsbaarheid. Supply chain attacks raken dus niet alleen grote softwarebedrijven, maar ook MKB-websites die bouwen op npm, Composer en andere dependencies. In dit artikel lees je hoe die aanvallen werken, waarom teams er zo vaak op misgaan en hoe je het risico beheersbaar maakt.
Waarom zijn supply chain attacks ineens zo’n groot risico?
Een supply chain attack gebruikt niet je eigen code als ingang, maar een schakel daaromheen: een package, een maintainer, een buildserver of een updatekanaal. Dat maakt dit type aanval lastig, omdat de software die jij vertrouwt ineens de drager van het probleem kan zijn. Microsoft liet met dependency confusion zien dat publieke packages soms onbedoeld boven interne varianten uitkomen. Ook de XZ Utils-backdoor liet zien dat dit niet alleen om npm gaat, maar om het hele ecosysteem. Voor kleinere organisaties is het risico simpel: je gebruikt dezelfde libraries als grotere partijen, maar hebt meestal minder controle op herkomst en updates.
Wat gebeurt er precies in je softwareketen?
Je softwareketen begint bij iets simpels: npm install, composer update of een CI-build die dependencies binnenhaalt. Daarna volgen scripts, transitive dependencies en deployment. Transitive dependencies zijn de bibliotheken van je bibliotheken. Juist daar ontstaat vaak het blinde vlekgebied.
Een aanvaller kan bijvoorbeeld een malafide package publiceren die lijkt op een bekende naam, of een legitieme dependency overnemen via een gecompromitteerde maintainer. Bij event-stream en ua-parser-js zag je hoe snel vertrouwde code alsnog gevaarlijk werd. In de praktijk is de keten dus alleen zo veilig als de zwakste schakel in je package flow. Meer daarover past ook bij ons eerdere stuk over Zero Trust development en API security gateways, omdat controle over input, toegang en leveranciers daar op dezelfde manier terugkomt.
Waarom maken teams juist hier snel fouten?
Omdat snelheid meestal wordt beloond. Een developer wil door, een manager wil live, een bureau wil opleveren. Dan voelt een dependency die “gewoon werkt” veiliger dan een uur uitzoekwerk. Dat is menselijk, niet dom.
Daar komt bij dat package managers veel uit handen nemen. Dat is handig, maar ook verraderlijk. Wat automatisch gaat, krijgt al snel het label “veilig genoeg”. Standaardisatie helpt hier juist omdat je niet op elke individuele keuze wilt vertrouwen. NIST SSDF en SLSA leggen daarom nadruk op vaste processen, provenance en gecontroleerde builds: maak goede keuzes de standaard, niet de uitzondering.
Hoe verklein je dependency-risico’s zonder je team te vertragen?
-
Zet version locking aan.
Gebruikpackage-lock.jsonin npm encomposer.lockin Composer. Daarmee bouw je reproduceerbaar. Zonder lockfile kan een “zelfde” build morgen andere versies ophalen. -
Beperk vrije updates.
Laat dependencies niet handmatig en ad hoc bijwerken. Werk met vaste updatevensters en reviewmomenten. -
Voer dependency-audits uit.
Kijk niet alleen naar bekende CVE’s, maar ook naar onderhoudsstatus, downloads, eigenaar en publicatiegeschiedenis. -
Maak een SBOM.
Een SBOM is de ingrediëntenlijst van je software. CISA, NTIA en NIST zien dit als een belangrijk fundament voor supply chain security. -
Gebruik private registries waar dat kan.
Vooral bij interne packages of gevoelige omgevingen voorkomt dit verwarring en verklein je dependency confusion-risico.
Persoonlijk adviseer ik hier een combinatie van lockfiles, SBOM en vaste updateprocessen. Het nadeel is dat je team iets meer discipline nodig heeft en updates minder spontaan gaan.
Welke tools en controles helpen je echt verder?
Dependabot is praktisch als je vooral overzicht wilt. Het maakt update-PR’s aan en houdt verouderde packages zichtbaar. Het nadeel is dat het geen inhoudelijk oordeel geeft; iemand moet nog steeds beoordelen wat veilig is.
Snyk en OWASP Dependency-Check helpen goed bij bekende kwetsbaarheden. Ze geven snel inzicht in risico’s, vooral in CI/CD. Maar scanners vinden vooral bekende problemen. Ze zien minder goed kwaadaardige intentie, misbruik van maintainers of gemanipuleerde releaseprocessen.
SBOM-tools zoals CycloneDX en SPDX helpen je om afhankelijkheden te documenteren. Dat is niet sexy, maar wel nuttig als je grip wilt op wijziging, audit en incidentrespons.
Private package registries zijn vooral nuttig als je meerdere teams of externe ontwikkelaars hebt. Je beperkt dan de kans dat een build zomaar iets uit een publiek ecosysteem haalt wat niet de bedoeling was.
Waar liggen de valkuilen bij supply chain beveiliging?
De grootste valkuil is schijnveiligheid. Eén scanner, één beleid of één registry lost het probleem niet op. Een tweede valkuil is dat teams alleen naar CVE’s kijken. Veel supply chain-incidenten beginnen niet met een bekend lek, maar met vertrouwen, publicatiegedrag of een overgenomen account.
Een derde valkuil is onvolledige monitoring. Als je niet weet welke dependencies echt in productie staan, kun je ook niet gericht patchen of blokkeren. Daarom is alleen “security tooling aanzetten” onvoldoende. Je hebt proces, overzicht en eigenaarschap nodig. Daar helpt ook ons eerdere artikel over SEO- en performancegrondslagen indirect bij: snelle, overzichtelijke systemen zijn vaak ook eenvoudiger te beheren.
Welke rol kan RDS-Online spelen in een veiligere softwareketen?
Wij kijken bij hosting en ontwikkeling niet alleen naar uptime, maar ook naar beheersbaarheid. Denk aan nette deployflows, correcte SSL-inrichting, logging, toegangsbeheer en een omgeving waarin updates voorspelbaar kunnen landen. Dat klinkt basaal, maar juist die basis bepaalt of dependencybeheer werkbaar blijft. Als je omgeving rommelig is, wordt security al snel handwerk. En handwerk is nu eenmaal foutgevoeliger dan een vast proces.
Hoe pak je dit vandaag nog gestructureerd aan?
Begin klein. Zet lockfiles aan, maak een inventaris van je belangrijkste dependencies en kies één scanproces voor je CI. Voeg daarna een SBOM toe voor je kernapplicatie en bepaal wie updates beoordeelt. Als je meerdere developers of bureaus hebt, leg dan ook vast hoe packages worden gepubliceerd en waar ze vandaan mogen komen. Daarmee verlaag je het risico zonder je team onnodig af te remmen. Mocht je er niet helemaal uitkomen, neem dan gerust contact op. 🚀
Bronnen
- Synopsys OSSRA 2024 — https://www.synopsys.com/software-integrity/resources/analyst-reports/open-source-security-risk-analysis.html
- Microsoft Security Blog: private package feeds en dependency confusion — https://msrc.microsoft.com/blog/2021/02/3-ways-to-mitigate-risk-using-private-package-feeds/
- CISA: SBOM — https://www.cisa.gov/sbom
- NIST: Secure Software Development Framework — https://csrc.nist.gov/Projects/ssdf
- npm package-lock.json — https://docs.npmjs.com/cli/v10/configuring-npm/package-lock-json
- Composer lockfile en dependency management — https://getcomposer.org/doc/01-basic-usage.md
- CISA alert: malicious code in XZ Utils — https://www.cisa.gov/news-events/alerts/2024/03/29/malicious-code-xz-utils
- GitHub Advisory: ua-parser-js — https://github.com/advisories/GHSA-pjwm-rvh2-c87w
- Snyk analyse van event-stream — https://snyk.io/blog/malicious-code-found-in-npm-package-event-stream/