Aanvallen op de software‑keten vormen een fundamentele verschuiving in de manier waarop kwaadwillenden organisaties binnendringen. In plaats van rechtstreeks de – vaak redelijk goed verdedigde – netwerken van een organisatie aan te vallen, richten zij zich op de leveranciers van software waarop tientallen of zelfs duizenden klanten vertrouwen. Als één softwareleverancier wordt gecompromitteerd, kan één geïnfecteerde update in één klap toegang verschaffen tot een groot deel van de afnemersbasis. Dat maakt supply‑chain‑aanvallen bijzonder verraderlijk: de besmette software lijkt afkomstig van een vertrouwde bron, is voorzien van een geldige digitale handtekening en wordt verspreid via de normale update‑mechanismen die beheerders gewend zijn te vertrouwen.
De SolarWinds‑aanval – ook bekend als SUNBURST en toegeschreven aan de groep APT29 – is het bekendste voorbeeld van zo’n ketencompromittering. Aanvallers wisten de build‑omgeving van de leverancier te manipuleren en een achterdeur in de Orion‑monitoringsoftware te injecteren. Die gemanipuleerde updates werden vervolgens uitgerold naar circa 18.000 klanten, waaronder overheidsinstanties, multinationals en aanbieders van kritieke infrastructuur. Pas maanden later werd de afwijkende activiteit ontdekt, waardoor de aanvallers lange tijd ongestoord verkenning konden uitvoeren en gegevens konden buitmaken. Ook Nederlandse organisaties, inclusief overheidsinstellingen, bleken de getroffen software te gebruiken en werden gedwongen tot langdurige herstel‑ en onderzoekstrajecten.
Deze gebeurtenis heeft wereldwijd geleid tot een herbezinning op het vertrouwen in softwareleveranciers en het onderliggende ecosysteem van open‑source componenten, pakketbronnen, container‑registries en cloud‑gebaseerde CI/CD‑platformen. Moderne softwareontwikkeling is sterk modulair en leunt zwaar op hergebruik van pakketten en diensten. Daarmee is de software‑keten niet langer een abstract risico, maar een concreet aanvalsoppervlak dat integraal moet worden beschermd. In deze gids bekijken we hoe organisaties hun software‑keten kunnen beveiligen met behulp van onder meer GitHub Advanced Security, Microsoft Defender for DevOps en de container‑beveiligingsmogelijkheden van Azure. Daarbij sluiten we aan op het NIST Secure Software Development Framework en het SLSA‑raamwerk voor supply‑chain‑zekerheid, zodat de aanpak ook aansluit op internationale best practices en Nederlandse compliance‑eisen.
In deze uitgebreide gids over supply‑chain‑beveiliging leer je hoe je de volledige softwareontwikkelketen – van broncode tot productie – weerbaar maakt. We gaan in op hoe je afhankelijkheden beheert en risico’s in open‑source pakketten beperkt, hoe code‑scanning kwetsbaarheden in de broncode blootlegt en hoe secret‑scanning voorkomt dat wachtwoorden en sleutels in repositories belanden. Ook behandelen we het scannen van container‑images op kwetsbaarheden en malware, het ondertekenen van artefacten om de integriteit van builds te waarborgen, het hardenen van CI/CD‑pipelines tegen ongeautoriseerde wijzigingen, het gebruik van een Software Bill of Materials voor transparantie in gebruikte componenten en het bewaken van draaiende workloads op verdachte activiteiten. De voorbeelden zijn gericht op Nederlandse (overheids)organisaties en sluiten aan op DevSecOps‑werkwijzen, inclusief praktische playbooks, pijplijn‑templates en relevante compliance‑kaders.
Gebruik automatische updates voor afhankelijkheden, maar voer die altijd gefaseerd en getest uit. Een Nederlandse overheidsorganisatie had Dependabot zo ingesteld dat updates voor alle repositories automatisch rechtstreeks naar productie werden uitgerold. Een beschadigd npm‑pakket zorgde ervoor dat een cruciaal burgerportaal ineens niet meer functioneerde. De dienst lag ruim zes uur uit de lucht en de herstel‑ en reputatieschade bedroeg naar schatting € 85.000. Een veel betere aanpak is om automatische updates eerst naar een ontwikkel‑ of testomgeving uit te rollen, daar geautomatiseerde testsets te draaien en pas na expliciete goedkeuring door een beheerder de productieomgeving bij te werken. Zo combineer je snelle patching van kwetsbaarheden met gecontroleerde implementatie, waarbij zowel beveiliging als stabiliteit volwaardig worden geborgd.
Software Supply Chain Dreigingslandschap: Van SolarWinds tot Moderne Attacks
Supply‑chain‑aanvallen grijpen in op de vele schakels waaruit moderne softwareontwikkeling bestaat. In een typisch ontwikkelproces wordt broncode beheerd in versiebeheersystemen, worden builds uitgevoerd op gedeelde build‑servers, worden pakketten opgehaald uit publieke en private registries en worden container‑images opgeslagen in een registry en vervolgens uitgerold naar verschillende omgevingen. Elke stap in deze keten biedt een gelegenheid voor een aanvaller om ongemerkt kwaadwillende code in te brengen of bestaande componenten te manipuleren. Wie de software‑keten wil beveiligen, moet daarom niet alleen naar het eindproduct kijken, maar naar het hele traject dat daaraan voorafgaat.
Een eerste categorie aanvallen richt zich op de ontwikkel‑ en build‑omgeving zelf. Als een aanvaller erin slaagt toegang te krijgen tot een build‑server of de onderliggende infrastructuur, kan deze de broncode of de build‑scripts aanpassen en een achterdeur toevoegen. De uiteindelijke binaries worden dan nog steeds netjes ondertekend met de vertrouwde certificaten en gedragen zich aan de buitenkant alsof ze legitiem zijn. Voor de afnemende organisatie is het nauwelijks zichtbaar dat er tijdens het build‑proces iets is misgegaan. Pas wanneer er ongebruikelijke netwerkverbindingen of gegevensstromen worden ontdekt, blijkt dat de keten al veel eerder is aangetast.
Een tweede type aanval speelt zich af rond afhankelijkheden. Organisaties combineren eigen pakketten met een groot aantal open‑source bibliotheken. Aanvallers misbruiken dit door pakketten aan te bieden die dezelfde naam hebben als interne componenten, maar met een hogere versienummering, in de hoop dat de pakketbeheerder automatisch hun kwaadaardige variant kiest. Ook typosquatting – pakketten met namen die sterk lijken op populaire bibliotheken maar subtiel verkeerd gespeld zijn – is een bekende techniek. Een ontwikkelaar die zich typt, haalt zo onbedoeld een pakket binnen dat naast legitieme functionaliteit ook verborgen malware bevat.
Daarnaast zijn de beheerders van open‑source projecten zelf een interessant doelwit. Veel veelgebruikte bibliotheken worden onderhouden door kleine teams of individuele ontwikkelaars. Zodra een aanvaller de inloggegevens van zo’n beheerder weet te bemachtigen, kan hij via de reguliere publicatie‑kanalen een gemanipuleerde versie van het pakket uitbrengen. Omdat deze update ogenschijnlijk van de oorspronkelijke beheerder afkomstig is, wordt hij zonder argwaan overgenomen in CI/CD‑pijplijnen en uiteindelijk in productieomgevingen.
Voor Nederlandse organisaties – en zeker voor overheidsinstellingen, vitale aanbieders en defensie‑gerelateerde partijen – zijn deze scenario’s geen theoretische dreigingen. Incidenten zoals de ransomware‑aanval via de Kaseya‑beheeroplossing, de compromittering van het Codecov‑platform en de manipulatie van veelgebruikte npm‑pakketten hebben aangetoond dat één zwakke schakel grote keteneffecten kan hebben. Wanneer een leverancier van beheersoftware of een clouddienstverlener wordt getroffen, kan dat in één keer doorwerken naar ministeries, gemeenten, zorginstellingen en bedrijven in de energiesector.
Om grip te krijgen op de kwaliteit van de eigen software‑keten is een gestructureerd raamwerk nodig. Het SLSA‑model (Supply‑chain Levels for Software Artifacts) biedt hiervoor een praktisch groeipad. Op het meest basale niveau draait het om het vastleggen en automatiseren van het build‑proces en het beschikbaar maken van herleidbare informatie over hoe een artefact is gebouwd. In vervolgstappen wordt geëist dat de herkomstinformatie cryptografisch wordt ondertekend, zodat achteraf kan worden gecontroleerd of een bestand sinds de build‑fase ongemoeid is gebleven. Nog verderop in het model worden eisen gesteld aan de hardening van het platform, de isolatie tussen verschillende builds en de volledigheid van audit‑logging.
Op het hoogste niveau worden veranderingen alleen nog na het vier‑ogen‑principe doorgevoerd en worden builds uitgevoerd in strikt afgeschermde omgevingen zonder netwerktoegang, zodat tijdens het bouwproces geen onverwachte externe afhankelijkheden kunnen binnensluipen. Zulke maatregelen zijn niet in één keer overal realiseerbaar, maar bieden wel een richting: organisaties kunnen beginnen met basale transparantie en ondertekening van artefacten en zich vervolgens stap voor stap ontwikkelen naar robuuste, sterk geïsoleerde build‑ketens. Door die ontwikkeling te koppelen aan concrete Nederlandse normen en wetgeving – zoals de BIO en NIS2 – ontstaat een realistisch meerjarenpad dat past bij de risico’s van de eigen organisatie.
Beveiliging van de software‑keten is in korte tijd uitgegroeid van een specialistisch aandachtspunt tot een essentieel onderdeel van volwassen beveiligingsbeleid. Incidenten als SolarWinds, Kaseya en compromitteringen in pakketregistries laten zien dat zelfs organisaties met een degelijk intern beveiligingsniveau alsnog slachtoffer kunnen worden als zij onvoldoende zicht hebben op de herkomst en integriteit van de software die zij gebruiken. Voor organisaties die zelf applicaties ontwikkelen of intensief gebruikmaken van externe componenten, cloud‑diensten en containers is het risico reëel en groeiende.
Platformen als GitHub Advanced Security, Microsoft Defender for DevOps en de beveiligingsfuncties rond containers en registries in Azure bieden krachtige mogelijkheden om die risico’s te verkleinen. Zij helpen kwetsbare afhankelijkheden op te sporen, fouten in broncode te identificeren, geheimen buiten repositories te houden, beelden te scannen op kwetsbaarheden en malware en de integriteit van builds aantoonbaar te maken. Toch bepalen uiteindelijk de processen en de cultuur binnen de organisatie of deze middelen effectief worden ingezet. Zonder duidelijke afspraken over review‑processen, release‑beleid en incidentrespons blijven zelfs de beste tools onderbenut.
Een volwassen aanpak vraagt om een DevSecOps‑mindset waarin veiligheid vanaf het eerste ontwerp tot en met de exploitatie in productie is ingebed. Ontwikkelaars moeten begrijpen welke impact hun keuzes in afhankelijkheden hebben, pipeline‑beheerders moeten builds en deploys beschermen tegen manipulatie en operations‑teams moeten productieworkloads continu bewaken op afwijkend gedrag. Security‑specialisten hebben de taak om deze teams te ondersteunen met richtlijnen, tooling en training, zonder onnodige vertraging in het ontwikkelproces te veroorzaken.
Voor Nederlandse overheidsorganisaties en vitale aanbieders komt daar een extra dimensie bij: de maatschappelijke en vaak ook nationale veiligheidsbelangen die met hun systemen zijn gemoeid. De NIS2‑implementatie en de BIO‑normenkaders benadrukken expliciet het belang van veilige ontwikkeling en beheer van software, inclusief aandacht voor de keten. Investeren in supply‑chain‑beveiliging is daarmee geen vrijblijvende luxe, maar een randvoorwaarde om verantwoord digitale diensten te kunnen leveren. Wie wacht tot een ernstig incident de urgentie pijnlijk duidelijk maakt, betaalt uiteindelijk een veel hogere prijs dan organisaties die nu al gestructureerd aan de slag gaan met zichtbaarheid, controle en borging in de gehele software‑keten.