COLUMN
De onzichtbare schakel in de Europese weerbaarheidsketen
In de aanstaande European Resilience Summit in Den Haag bespreken we hoe we onze elektriciteitsnetten, onze grenzen en onze financiële systemen stresstesten. Maar de software die ze allemaal aanstuurt? Die nemen we nog steeds grotendeels op vertrouwen voor lief.
Wanneer we in Europa spreken over weerbaarheid, gaat de aandacht doorgaans uit naar het tastbare. Elektriciteitsnetten, grensbeveiliging, financiële stabiliteit en bijvoorbeeld ons klaarmaken voor een pandemie. Dit zijn systemen die we kunnen zien, meten en onder druk kunnen testen. Ze hebben fysieke aanwezigheid en politiek gewicht. En terecht. De verstoringen van de afgelopen vijf jaar hebben duidelijk gemaakt dat de kritieke infrastructuur van Europa op elk niveau versterkt moet worden.
Alles draait op software
Maar onder al deze systemen ligt een laag die zelden onderdeel is van het weerbaarheidsdebat, terwijl juist alles ervan afhankelijk is: de software. Het elektriciteitsnet draait op software. Ziekenhuissystemen draaien op software. Defensiecommunicatie, luchtverkeersleiding, bancaire infrastructuur en overheidsadministratie: alles rust op een fundament van code. En toch stellen we bij het bespreken van de weerbaarheid van deze systemen, zelfs na alle aandacht voor digitale soevereiniteit, nog steeds bijna nooit de meest fundamentele vraag over de software die ze aandrijft. Want waar komt die eigenlijk vandaan?
Beschouw dit als een gedachte-experiment. Stel je een ziekenhuis voor dat al zijn voedsel inkoopt bij een niet-geregistreerde straatverkoper. De maaltijden smaken goed. Ze worden op tijd geleverd. Niemand wordt ziek, totdat dat op een dag wel gebeurt. En wanneer het onderzoek start, is er geen ingrediëntenlijst, geen keuringsrapport van de keuken, geen manier om te achterhalen welke batch besmet was. Het ziekenhuis heeft geen terugroepmogelijkheid, omdat het nooit inzicht in de toeleveringsketen heeft gehad.
Gedreven door crises
Voor voedsel klinkt dit absurd. Elk Europees land kent strikte regelgeving rond herkomst, verwerking, etikettering en terugroepacties. Dit probleem hebben we decennia geleden opgelost, gedreven door crises die de kosten van ondoorzichtigheid onacceptabel maakten.
Miljoenen downloads worden behandeld als een proxy voor veiligheid
Maar in werkelijkheid is dit precies hoe de meeste organisaties vandaag software consumeren. Engineeringteams halen hun afhankelijkheden uit publieke repositories en registries: Maven-pakketten, GitHub-bibliotheken, NPM-modules, containerimages. Miljoenen downloads worden behandeld als een proxy voor veiligheid.
Software gebouwd door vrijwilligers
Een groot deel van deze software wordt gebouwd door vrijwilligers die de ruggengraat vormen van open-sourcegemeenschappen. Hun werk drijft innovatie en houdt het ecosysteem in leven. Maar supply chain security, langdurig onderhoud en enterprise-grade verificatie zijn lasten die niet uitsluitend op hun schouders zouden moeten rusten. Daar komen curatie, professioneel lifecycle management en gecontroleerde build-processen om de hoek kijken.
Iemand moet de poort vormen tussen de ruwe output van de community en wat uiteindelijk in productieomgevingen draait. Op dit moment hebben de meeste organisaties die poort niet. Ze implementeren software zonder te weten hoe deze is gecompileerd, door wie en of de build-omgeving zelf wel veilig was. Het werkt, tot het niet meer werkt. En wanneer dat gebeurt, zijn de gevolgen niet hypothetisch.
Probleem in keten eromheen
De xz/liblzma-backdoor. Log4Shell. SolarWinds. Kwaadaardige containerimages op Docker Hub, meer dan 20 miljoen keer gedownload voordat iemand het doorhad. Vier totaal verschillende incidenten, één patroon. In alle gevallen werkte de software op zichzelf prima. Ze werd breed gebruikt. En in alle gevallen zat het probleem niet in de code zelf, maar in de keten eromheen.
- Een alleen werkende maintainer onder druk.
- Een afhankelijkheid die niemand volgde.
- Een build-proces dat werd vertrouwd, maar nooit werd geverifieerd.
- Een containerimage die legitiem leek, maar dat niet was.
Dit is geen falen van open source. Dit is falen door het ontbreken van verantwoordelijkheid voor de poort tussen community-innovatie en productie-implementatie. In voedseltermen: de ingrediënten waren in orde; het probleem was dat niemand de keuken controleerde.
Betekenisvolle stappen
Europa begint dit inmiddels op waarde te schatten en te adresseren. De Cyber Resilience Act verplicht software bills of materials (SBOM’s) en kwetsbaarheidsbeheer voor producten met digitale componenten. NIS2 breidt supply-chainverplichtingen uit naar essentiële entiteiten. DORA brengt toezicht op ICT-afhankelijkheden in de financiële sector. Dit zijn betekenisvolle stappen en ze weerspiegelen een groeiend besef dat software infrastructuur is, en dat infrastructuur transparantie vereist.
Als er morgen iets kapotgaat, helpen mijn SBOM’s mij dan echt?
Ik zie dit direct terug in de praktijk. In gesprekken met IT-leiders uit de publieke sector in heel Europa is de vraag verschoven van ‘hebben we supply-chainzichtbaarheid nodig?’ naar ‘hoe snel kunnen we dit krijgen?’. Die verschuiving is reëel en versnelt. Maar de scherpere vraag die ik steeds vaker hoor is operationeel van aard. Als er morgen iets kapotgaat, helpen mijn SBOM’s mij dan echt om te herstellen, of dienen ze alleen om de audit te doorstaan?
Vragen die het verschil maken
Maar wetgeving alleen zal de kloof niet dichten. Organisaties moeten de vragen veranderen die zij stellen over de software die zij gebruiken. ‘Werkt het?’ is niet langer voldoende. Kan ik verifiëren hoe het is gemaakt? Kan ik een kwetsbaarheid terug volgen door de volledige keten die dit binaire bestand heeft geproduceerd?
Dit zijn de vragen die het verschil maken tussen papieren compliance en echte weerbaarheid in de praktijk. En de prikkel is helder, want organisaties die deze vragen kunnen beantwoorden herstellen sneller wanneer iets misgaat, krijgen minder verrassingen vanuit toezichthouders en nemen inkoopbeslissingen op basis van kennis in plaats van hoop. Wie dat niet kan, is één incident verwijderd van het ontdekken van wat men niet wist. 