Bij een software supply chain aanval wordt niet alleen jouw organisatie aangevallen. Een cybercrimineel misbruikt ook een softwareleverancier, ontwikkelomgeving, distributiekanaal of externe afhankelijkheid. Via die vertrouwde schakel kan de aanvaller meerdere klanten bereiken.
Moderne software bestaat uit veel onderdelen. Denk aan eigen broncode, open-sourcebibliotheken, API’s, cloudservices, buildsystemen, softwarepakketten en automatische updates. Elke schakel kan een risico vormen als de beveiliging niet op orde is.
Deze aanvallen zijn lastig te herkennen. Kwaadaardige code kan meekomen met een legitieme update of een pakket dat je organisatie al vertrouwt. De gevolgen lopen uiteen van datadiefstal en accountmisbruik tot ransomware, bedrijfsonderbreking en verlies van vertrouwen.
In dit artikel lees je wat een software supply chain aanval is en hoe cybercriminelen leveranciers en ontwikkelomgevingen aanvallen. Ook ontdek je hoe de aanval zich verspreidt en welke maatregelen je kunt nemen. Software supply chain security is daarbij een gezamenlijke verantwoordelijkheid van ontwikkelaars, leveranciers, IT-afdelingen, inkopers en eindgebruikers.
Wat is een software supply chain aanval?
Bij een software supply chain aanval misbruikt een aanvaller de keten rond software. Die keten bestaat uit ontwikkelaars, leveranciers, cloudplatforms, updates en externe pakketten. Eén succesvolle inbraak kan toegang geven tot veel klanten tegelijk.
Je hoeft niet zelf het eerste doelwit te zijn. Een kleinere leverancier of dienstverlener kan minder goed beveiligd zijn. Toch kan die partij toegang hebben tot jouw systemen, gegevens of softwaredistributie.
Hoe cybercriminelen softwareleveranciers aanvallen
Cybercriminelen zoeken naar zwakke plekken bij organisaties die software ontwikkelen, onderhouden of verspreiden. Zij gebruiken gestolen inloggegevens, phishing of bekende kwetsbaarheden. Een slecht beveiligde cloudomgeving, een broncodeplatform of een ontwikkelaarsaccount kan de eerste toegang bieden.
De CI/CD-pijplijn vormt een belangrijk doelwit. Deze omgeving bouwt, test en publiceert software. Krijgt een aanvaller toegang tot de build- of releaseomgeving, dan kan kwaadaardige code met een legitieme applicatie worden meegebouwd.
Te ruime toegangsrechten vergroten de schade. Hetzelfde geldt voor ontbrekende multifactor-authenticatie. Een scheiding tussen ontwikkel-, test- en productieomgevingen beperkt de gevolgen van een gestolen account.
Het Nationaal Cyber Security Centrum (NCSC), CISA en ENISA adviseren organisaties om leveranciersrisico’s, toegangsrechten en softwareherkomst vast te leggen en geregeld te controleren.
De rol van software-updates en afhankelijkheden
Updates verbeteren normaal de werking van software en verhelpen beveiligingsfouten. Een aanvaller kan dit vertrouwde proces misbruiken. Een gemanipuleerde update lijkt legitiem en kan zo bij klanten binnenkomen.
Software gebruikt vaak externe componenten. Denk aan npm-pakketten, Python-packages, Java-bibliotheken, containerimages, plug-ins en open-sourcecode. Een directe bibliotheek kan weer meerdere andere pakketten gebruiken. Je hebt daardoor niet altijd volledig zicht op de hele keten.
Risico’s ontstaan door verouderde componenten, kwetsbaarheden en overgenomen projecten. Typosquatting en kwaadaardige pakketten vormen een aparte dreiging. Bij typosquatting lijkt de naam van een pakket sterk op die van een betrouwbaar pakket.
Een Software Bill of Materials (SBOM) is een inventaris van alle softwarecomponenten. Met zo’n overzicht zie je sneller welke producten risico lopen wanneer een bibliotheek of pakket wordt gecompromitteerd.
Een kwetsbare afhankelijkheid bevat een beveiligingsfout. Bij een actief gemanipuleerde afhankelijkheid is de code bewust aangepast. Updates uitschakelen is geen veilige oplossing. Gebruik gecontroleerde updates met digitale handtekeningen, tests, versiebeheer, monitoring en een terugvalscenario.
Voorbeelden van een software supply chain aanval
- SolarWinds, 2020: aanvallers brachten kwaadaardige code in het bouwproces van Orion-software. Gemodificeerde updates bereikten overheden en bedrijven.
- NotPetya, 2017: malware verspreidde zich via de update-infrastructuur van de Oekraïense boekhoudsoftware M.E.Doc. Organisaties wereldwijd kregen te maken met grote verstoringen en financiële schade.
- event-stream, 2018: een nieuwe maintainer voegde kwaadaardige code toe aan een populair npm-pakket. Applicaties die het pakket gebruikten, liepen risico.
- 3CX, 2023: een besmette softwarebouwomgeving leidde tot kwaadaardige versies van de desktopapplicatie. Gebruikers werden geraakt via software die zij al vertrouwden.
Deze incidenten tonen verschillende risico’s. Het gaat om manipulatie van een buildomgeving, misbruik van updates, overname van open-sourceonderhoud en besmetting van distributiekanalen. Een voorbeeld maakt niet ieder softwareproduct onveilig. Het laat wel zien waarom controle op herkomst, integriteit, afhankelijkheden en leveranciers nodig is.
Hoe verloopt een software supply chain aanval?
Een software supply chain aanval verloopt vaak in meerdere stappen. De aanvaller richt zich niet alleen op jouw organisatie, maar op een leverancier, ontwikkelaar of dienst die jij vertrouwt. Via die route kan kwaadaardige code jouw systemen bereiken.
De eerste toegang tot een leverancier of ontwikkelomgeving
De eerste stap is toegang krijgen tot een leverancier, repository, buildserver, cloudaccount of softwaredistributieomgeving. Phishing, gestolen wachtwoorden en hergebruikte inloggegevens zijn veelgebruikte routes. Kwetsbare externe systemen en verkeerd ingestelde cloudservices kunnen hetzelfde doel dienen.
Ontwikkelomgevingen zijn aantrekkelijke doelen. Daar staan vaak broncode, certificaten, tokens, pakketregisters en rechten voor softwarepublicatie. Met één account kan een aanvaller invloed krijgen op een groot deel van het ontwikkelproces.
De aanvaller voegt niet altijd direct kwaadaardige code toe. Soms blijft hij langere tijd onopgemerkt aanwezig. In die periode kan hij rechten uitbreiden en onderzoeken hoe software wordt gebouwd en verspreid.
Goede logging helpt je om deze fase te herkennen. Let op ongebruikelijke loginlocaties, nieuwe API-tokens, wijzigingen in buildconfiguraties en onverwachte activiteiten in repositories.
Leveranciers moeten ontwikkelaccounts, secrets, code repositories en CI/CD-pijplijnen streng beveiligen. Multifactor-authenticatie, minimale rechten en gescheiden omgevingen beperken de bewegingsruimte van een aanvaller.
Het verspreiden van kwaadaardige code
Na de eerste toegang kan de aanvaller code, afhankelijkheden, buildscripts of configuraties aanpassen. De gewijzigde software wordt mogelijk verpakt als een normale versie en gepubliceerd. Voor gebruikers lijkt de update betrouwbaar.
De verspreiding kan via verschillende kanalen lopen:
- automatische software-updates;
- pakketregisters en softwarebibliotheken;
- containerimages en plug-ins;
- software-installers;
- een geïntegreerde dienst van een leverancier.
Een digitale handtekening geeft niet altijd volledige zekerheid. Krijgt een aanvaller toegang tot de omgeving die software ondertekent, dan kan een kwaadaardige versie een geldige handtekening dragen. Controle op herkomst, buildprovenance en onafhankelijke validatie blijft nodig.
Sommige kwaadaardige code wordt pas later actief. De code kan zich richten op specifieke organisaties, systemen of omstandigheden. Dat maakt detectie lastiger en kan het onderzoek vertragen.
Afhankelijkheden vormen een extra verspreidingsroute. Een gemanipuleerd pakket kan in meerdere applicaties terechtkomen. Via leveranciersketens bereikt het daarna weer andere organisaties.
Je moet softwareversies, hashes, SBOM-informatie en releasegegevens kunnen vergelijken. Afwijkingen in die gegevens kunnen wijzen op een besmette versie of een onverwachte wijziging.
De impact op jouw organisatie
De gevolgen hangen af van de rechten van de besmette software. De beschikbare gegevens en de verbindingen tussen systemen spelen een grote rol. Een applicatie met brede toegangsrechten kan veel meer schade veroorzaken dan een losstaande tool.
Mogelijke gevolgen zijn:
- ongeautoriseerde toegang tot accounts en systemen;
- diefstal van persoonsgegevens, broncode of bedrijfsgeheimen;
- verstoring van bedrijfsprocessen en productie;
- ransomware en misbruik van bestaande accounts;
- kosten voor onderzoek, herstel en communicatie.
Een incident bij een leverancier kan juridische, contractuele en toezichthoudende gevolgen hebben. Bij persoonsgegevens kunnen meldplichten onder de AVG gelden. Organisaties die onder de NIS2-richtlijn vallen, moeten rekening houden met eisen voor risicobeheer en incidentmelding.
Herstel vraagt vaak veel tijd. Je moet niet alleen je eigen systemen onderzoeken, maar ook vaststellen welke softwareversies, updates en afhankelijkheden zijn gebruikt. Stilgevallen productie, gemiste omzet en reputatieschade kunnen de financiële druk vergroten.
Een bekende leverancier biedt geen automatische garantie. Je moet weten welke software actief is, welke rechten die software heeft en hoe snel je een besmette versie kunt isoleren of vervangen.
Hoe bescherm je jouw organisatie tegen digitale risico’s?
Begin met een actuele inventaris van software, leveranciers, cloudservices, API’s en open-sourcecomponenten. Leg vast welke systemen bedrijfskritisch zijn en welke software toegang heeft tot gevoelige gegevens. Een Software Bill of Materials (SBOM) maakt afhankelijkheden zichtbaar en helpt je sneller risico’s te beoordelen.
Beveilig ontwikkel- en distributieomgevingen met multifactor-authenticatie en minimale toegangsrechten. Scheid ontwikkel-, test- en productieomgevingen en bewaar tokens, secrets en ondertekeningssleutels in een veilige secretsmanager. Gebruik dependency scanning, vulnerability scanning en code reviews. Controleer ook de herkomst van pakketten, digitale handtekeningen, hashes en releasewijzigingen.
Voer updates eerst uit in een afgeschermde omgeving en kies waar mogelijk voor een gefaseerde uitrol. Monitor afwijkend gedrag en houd een getest rollbackscenario klaar. Netwerksegmentatie, zero-trustprincipes, egress-filtering, endpointdetectie en centrale logging beperken de schade als een leverancier of afhankelijkheid wordt misbruikt.
Maak met leveranciers duidelijke afspraken over kwetsbaarheden, patchtermijnen, incidentrespons, auditrechten en toegang tot loggegevens. Bereid je voor op een besmette update door systemen te kunnen isoleren, tokens en certificaten in te trekken en klanten of toezichthouders tijdig te informeren. Gebruik richtlijnen van het NCSC, ENISA, CISA en NIST als basis en test je plan regelmatig. Zo blijft beveiliging een doorlopend proces van inventariseren, controleren, monitoren en verbeteren.
