De architectuur is niet het probleem. De economie van onderhoud wel.
De beveiligingspatch is er. Wie zorgt dat hij werkelijk wordt gebruikt?
Op 21 oktober 2026 publiceerde Google beveiligingsreleases voor drie onderhouden versielijnen van zijn Brotli-compressiebibliotheek: v1.0.10, v1.1.1 en v1.2.1. De releases zijn publiek beschikbaar. Onder identificatie CVE-2026-111497 bleek dat speciaal geconstrueerde gecomprimeerde invoer een schrijfactie buiten de grenzen van een interne buffer in de Brotli-decoder kon veroorzaken. De mogelijke gevolgen omvatten procescrashes, geheugenlekken en, afhankelijk van de omstandigheden, uitvoering van willekeurige code.
De kwetsbare decoder bevond zich niet in één specifiek product, maar in de breed gebruikte open-sourceimplementatie van Google's Brotli-compressiealgoritme, die door browsers, servers, package managers en andere software wordt ingebouwd.
Dat laatste is essentieel. Het zou feitelijk onjuist zijn om te stellen dat Google uitsluitend de hoofdbranch repareerde en de beveiligingspatch niet als release beschikbaar stelde. Upstream is daadwerkelijk gehandeld.
Maar een gerepareerde upstreamrepository betekent nog geen veilig digitaal ecosysteem.
Tussen een codecorrectie en een veilig eindproduct ligt een volledige distributieketen: broncode, releases, package registries, vendored libraries, forks, containerimages, runtimeversies, softwareleveranciers en uiteindelijk de systemen die organisaties daadwerkelijk gebruiken.
Iedere schakel kan vertraging veroorzaken. Iedere vertraging kan economisch rationeel zijn voor de afzonderlijke partij, terwijl zij maatschappelijk schadelijk blijft.
Hier begint het werkelijke probleem.
We behandelen software supply-chain security doorgaans als een vraagstuk van technische architectuur, tooling en beheersmaatregelen. Welke afhankelijkheden gebruiken we? Welke versies draaien er? Welke CVE's zijn bekend? Wie is technisch verantwoordelijk?
Maar deze vragen verklaren niet waarom essentiële afhankelijkheden structureel onvoldoende worden onderhouden, waarom gebruikers weinig teruggeven aan upstreamprojecten en waarom herstel na een beveiligingsincident zo moeizaam door de waardeketen beweegt.
Daarvoor moeten we niet primair naar Enterprise Architecture kijken, maar naar de economische prikkels achter softwareproductie en softwareconsumptie.
De centrale these van dit artikel is dat digitale infrastructuur een structurele mismatch kent tussen de partijen die economische waarde ontvangen en de partijen die onderhoud, beveiligingsrisico's en continuïteitskosten dragen.
De Cyber Resilience Act probeert een deel van die mismatch te corrigeren door afdwingbare verplichtingen te verbinden aan het op de Europese markt brengen van digitale producten.
Daarmee verandert niet alleen het beveiligingsbeleid.
Het verandert de economische betekenis van een softwaredependency.
1. Nadia Eghbal zag het probleem tien jaar geleden al
In 2016 publiceerde Nadia Eghbal, met steun van de Ford Foundation, het 143 pagina's tellende rapport Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure.
De centrale analogie was eenvoudig en fundamenteel. Een samenleving kan niet functioneren zonder wegen, bruggen, elektriciteitsnetwerken en riolering. Iedereen begrijpt dat dergelijke infrastructuur regelmatig onderhoud vereist. Daarom bestaan er eigendomsstructuren, budgetten, contracten, verantwoordelijkheden en instituties om dat onderhoud te organiseren.
Voor digitale infrastructuur ontbreekt die koppeling vaak.
Softwarebedrijven, overheden en maatschappelijke organisaties bouwen complete bedrijfsprocessen op bibliotheken die gratis toegankelijk zijn, zonder dat hun gebruik automatisch een bijdrage oplevert aan de continuïteit van die bibliotheken.
De economische waarde van de infrastructuur is daardoor vele malen groter dan de inkomsten die de infrastructuur zelf genereert.
Eghbal illustreerde dat onder andere met OpenSSL.
Voor Heartbleed in 2014 ontving de OpenSSL Software Foundation volgens haar onderzoek niet meer dan ongeveer 2.000 dollar per jaar aan donaties. Er waren inkomsten uit contractwerk, maar onvoldoende middelen voor een groot permanent ontwikkelteam. Eén ontwikkelaar werkte voltijds aan software waarvan een enorm deel van het web afhankelijk was.
Dat was geen constatering dat de ontwikkelaars onvoldoende professioneel waren.
Het was een constatering dat het financieringsmechanisme niet in verhouding stond tot de maatschappelijke functie van de software.
Eghbal beschreef expliciet het free-riderprobleem: individuele gebruikers en grote ondernemingen profiteren van beschikbare software zonder noodzakelijkerwijs de kosten van instandhouding te dragen.
De aantrekkingskracht van haar rapport is dat het dit probleem niet reduceert tot een morele beschuldiging aan individuele bedrijven.
Ook wie volledig rationeel en volgens de geldende regels handelt, kan bijdragen aan een collectief inefficiënte uitkomst.
Dat is precies het terrein van de welvaartseconomie.
Het rapport leverde daarmee in 2016 niet alleen een diagnose van achterstallig digitaal onderhoud. Het leverde de empirische basis voor een belangrijkere vraag:
Waarom zou een individuele onderneming vrijwillig betalen voor onderhoud waarvan ook al haar concurrenten profiteren, wanneer zij dezelfde software zonder betaling kan blijven gebruiken?
2. Google's Brotli laat zien dat open source ook een concurrentiestrategie is
Het is verleidelijk om de open-sourcepublicatie van Brotli te presenteren als een voorbeeld van bedrijfsmatig altruïsme.
Google ontwikkelde een compressietechniek en maakte die beschikbaar voor iedereen. Daardoor konden browsers, servers en softwareontwikkelaars dezelfde technologie toepassen.
Het publieke voordeel is reëel: kleinere bestanden, efficiëntere overdracht en potentieel snellere websites.
Maar publieke voordelen sluiten private economische motieven niet uit.
Op 22 september 2015 kondigde Google Brotli publiekelijk aan. Daarbij sprak het bedrijf expliciet de hoop uit dat grote browsers het nieuwe formaat zouden ondersteunen.
Die ambitie was noodzakelijk voor de verspreiding van Brotli als interoperabele webtechnologie.
Een compressieformaat dat alleen door één partij wordt ondersteund, heeft beperkte economische waarde. Hetzelfde formaat wordt aanzienlijk aantrekkelijker zodra browsers, servers en content delivery networks het breed ondersteunen.
Door de technologie open beschikbaar te maken, verlaagt de oorspronkelijke ontwikkelaar de adoptiedrempel voor andere marktpartijen.
Dit is consistent met de strategie die Joel Spolsky in zijn essay Strategy Letter V uit 2002 beschreef als commoditize your complements.
Het principe is dat ondernemingen voordeel kunnen behalen door complementaire technologieën goedkoper, toegankelijker en uitwisselbaarder te maken.
Een organisatie die verdient aan een digitaal ecosysteem kan economisch profiteren van efficiëntere technologie waarop dat ecosysteem functioneert. Voor Google konden snellere webpagina's, efficiënter dataverkeer en bredere ondersteuning van webtechnologie strategisch aantrekkelijk zijn.
Dat bewijst niet dat Google Brotli uitsluitend om commerciële redenen open-sourcete. Daarvoor ontbreekt in de aangehaalde bronnen direct bewijs over interne besluitvorming.
Het laat wel zien waarom open source en commerciële rationaliteit uitstekend samen kunnen bestaan.
Hier is een theoretische precisering noodzakelijk.
De formulering commoditize your complements is rechtstreeks verbonden aan Spolsky's essay. Het werk van Joshua Lerner en Jean Tirole, Some Simple Economics of Open Source (2002), biedt een bredere economische onderbouwing van commerciële deelname aan open source, reputatieprikkels en de kosten-batenafweging van ontwikkelaars.
Beide perspectieven vullen elkaar aan, maar zijn niet identiek.
Spolsky helpt verklaren waarom een onderneming code gratis verspreidt.
Lerner en Tirole helpen verklaren waarom ondernemingen en individuen überhaupt in open source investeren.
Geen van beide theorieën garandeert echter dat die investering gedurende de volledige levensduur van een breed geadopteerde dependency op het maatschappelijk gewenste niveau blijft.
En precies daar ontstaat het onderhoudsvraagstuk.
3. Brotli is niet de negatieve externaliteit. Het ongeprijsde risico is dat wel.
De stelling dat Brotli een negatieve externaliteit is, vraagt om economische precisie.
Brotli zelf is geen negatieve externaliteit. De beschikbaarheid van herbruikbare compressiesoftware levert juist positieve externe effecten op: derden ontvangen voordelen zonder daarvoor noodzakelijkerwijs aan de ontwikkeling te betalen.
De negatieve externaliteit ontstaat wanneer beslissingen over ontwikkeling, adoptie of onderhoud risico's en kosten veroorzaken die niet volledig worden gedragen door degene die de betreffende beslissing neemt.
Daarmee lopen in de software-economie twee vormen van marktfalen door elkaar.
De eerste is de positieve externaliteit van onderhoud.
Een ontwikkelaar die een beveiligingsfout oplost, creëert waarde voor veel meer partijen dan uitsluitend zichzelf.
De verbetering kan tegelijkertijd ten goede komen aan browsers, webservers, dienstenleveranciers en eindgebruikers. Het maatschappelijke rendement van die patch kan daardoor aanzienlijk groter zijn dan het private rendement van de partij die het werk betaalt.
Als die partij haar onderhoudsinvestering baseert op uitsluitend het rendement dat zij zelf ontvangt, kan haar investeringsniveau lager liggen dan het maatschappelijk optimale niveau.
De tweede is de negatieve externaliteit van onvolledig geïnternaliseerd beveiligingsrisico.
Een fabrikant kan besluiten een goedkope dependency te integreren zonder de volledige verwachte kosten van langdurig onderhoud en kwetsbaarheidsafhandeling mee te nemen.
Een deel van die kosten kan terechtkomen bij eindgebruikers, afnemers, andere organisaties of partijen die door een beveiligingsincident worden geraakt.
Het product lijkt op het moment van aanschaf of integratie goedkoper dan het maatschappelijk daadwerkelijk is.
Het onderscheid is belangrijk, omdat beide mechanismen verschillende beleidsinterventies vereisen.
Onderinvestering in een publiek goed vraagt om betere financiering of collectieve coördinatie.
Ongeprijsde schade vraagt om internalisering van risico's door bijvoorbeeld contracten, veiligheidsverplichtingen, verzekeringen of regulering.
De twee problemen versterken elkaar, maar zijn analytisch niet hetzelfde.
4. Samuelson verklaart waarom onderhoud structureel tekort kan schieten
Paul Samuelsons klassieke artikel The Pure Theory of Public Expenditure (1954) beschrijft waarom marktmechanismen moeite hebben om publieke goederen op een efficiënt niveau voort te brengen. De economische eigenschappen van onderhoud aan breed herbruikbare open-sourcecode lijken sterk op die van een publiek goed.
Wanneer een beveiligingspatch eenmaal beschikbaar is, kan die door meerdere organisaties worden gebruikt zonder dat de technische werking voor één organisatie daardoor vermindert.
Dat maakt de baten van onderhoud in belangrijke mate niet-rivaliserend.
De financiering en uitvoering van datzelfde onderhoud zijn daarentegen allesbehalve kosteloos.
Om het probleem formeel te benaderen, definiëren we:
- m: de hoeveelheid geïnvesteerd onderhoud.
- C(m): de totale onderhoudskosten.
- pᵢ(m): de kans op een relevante beveiligingsschade voor afnemer i, gegeven het onderhoudsniveau.
- Lᵢ: de verwachte schadeomvang voor afnemer i wanneer het relevante incident optreedt.
Neem aan dat meer effectief onderhoud de betreffende risicokans verlaagt, dat de marginale onderhoudskosten stijgen en dat de verwachte baten voldoende regulier zijn voor een inwendig optimum.
Een vereenvoudigde maatschappelijke optimalisatie luidt dan:
Minimaliseer:
C(m) + Σᵢ pᵢ(m) × Lᵢ
De sociaal efficiënte hoeveelheid onderhoud, m*, voldoet onder deze aannames aan:
C′(m*) = Σᵢ [−pᵢ′(m*) × Lᵢ]
De marginale onderhoudskosten moeten dus worden afgewogen tegen de som van de marginale risicoreductie voor alle betrokken afnemers.
Een afzonderlijke ontwikkelaar of onderneming maakt doorgaans een andere afweging.
Die houdt rekening met eigen kosten, eigen beveiligingsrisico's, reputatie, concurrentievoordelen en eventuele commerciële opbrengsten.
Niet automatisch met alle voordelen die andere partijen ontvangen.
Wanneer de totale maatschappelijke marginale baten structureel groter zijn dan de baten die de investeerder zelf kan realiseren, ontstaat onderinvestering ten opzichte van het maatschappelijke optimum.
Dat is geen bewijs dat iedere open-sourcebibliotheek ondergefinancierd is. Er bestaan projecten met sterke commerciële ondersteuning en goed georganiseerde gemeenschappen.
Het is wel een theoretische verklaring waarom brede adoptie op zichzelf geen garantie vormt voor evenredig onderhoud.
Sterker nog: naarmate meer producten dezelfde dependency gebruiken, kunnen de totale maatschappelijke baten van preventief onderhoud toenemen zonder dat de oorspronkelijke ontwikkelaar proportioneel meer inkomsten ontvangt.
Het aantal partijen dat van een bibliotheek afhankelijk wordt, kan sneller groeien dan de middelen die beschikbaar zijn om haar veilig te houden.
Dat is het fundamentele verschil tussen economische adoptie en economische duurzaamheid.
5. Olson verklaart waarom iedereen wacht op iemand anders
Mancur Olson onderzocht in The Logic of Collective Action (1965) waarom groepen met een gezamenlijk belang niet vanzelf collectief handelen.
Zijn analyse is direct relevant voor organisaties die open-sourcecomponenten gebruiken.
Stel dat honderd commerciële partijen profiteren van hetzelfde beveiligingsonderhoud.
Iedere partij heeft belang bij een veilige dependency.
Maar een afzonderlijke bijdrage van bijvoorbeeld een ontwikkelaar gedurende enkele maanden levert ook voordelen op aan alle andere partijen.
Een onderneming kan daarom concluderen dat het financieel aantrekkelijker is te wachten totdat iemand anders investeert.
De collectieve uitkomst is vervolgens dat meerdere partijen hun bijdrage uitstellen.
Er bestaat een gedeeld belang, maar niet noodzakelijkerwijs een individueel voldoende sterke prikkel om dat belang te realiseren.
Dit gedrag hoeft niet voort te komen uit onwil.
Een CISO kan correct vaststellen dat een kwetsbare dependency een bedrijfsrisico vormt. Een CTO kan correct constateren dat extra upstreamonderhoud een waardevolle maatregel zou zijn. Een CFO kan eveneens rationeel besluiten dat structurele financiering van een publiek project niet direct binnen het bedrijfsbudget past.
Alle drie kunnen vanuit hun afzonderlijke verantwoordelijkheid rationeel handelen. Toch kan het gecombineerde resultaat economisch inefficiënt zijn.
Hieruit volgt een ongemakkelijke conclusie voor vrijwel iedere commerciële en publieke softwaregebruiker.
Wie essentiële open-sourcesoftware consumeert zonder bij te dragen aan de instandhouding, kan zelf onderdeel zijn van het free-riderprobleem dat hij bij een beveiligingsincident bekritiseert.
Dat geldt voor grote technologiebedrijven, softwareleveranciers en overheden, maar ook voor kleinere organisaties die hun complete technologieplatform op gratis componenten baseren.
De mate waarin een specifieke organisatie bijdraagt, is uiteraard een empirische vraag. Het gebruik van open source bewijst op zichzelf geen free-riding.
Maar de economische mogelijkheid ontstaat zodra collectieve onderhoudsbaten losstaan van individuele financieringsverplichtingen.
6. Ostrom laat zien waarom governance het verschil maakt
Het derde perspectief komt van Elinor Ostrom.
In Governing the Commons: The Evolution of Institutions for Collective Action (1990) onderzocht zij onder welke omstandigheden gemeenschappen gedeelde hulpbronnen duurzaam kunnen beheren.
Ostrom wordt regelmatig aangehaald als onderbouwing voor de onvermijdelijke degradatie van onbeheerde commons.
Dat doet haar werk tekort.
Haar belangrijkste bijdrage was juist dat gemeenschappen onder bepaalde voorwaarden zelf effectieve instituties kunnen ontwikkelen om collectieve problemen op te lossen.
Dat inzicht is relevanter voor open source dan een simplistische verwijzing naar de tragedy of the commons.
Softwarecode is immers geen klassiek gemeenschappelijk visbestand of weiland.
Het kopiëren van code vermindert de beschikbaarheid voor anderen niet.
De schaarse hulpbronnen bevinden zich rondom de code: onderhoudstijd, deskundigheid, beveiligingsonderzoek, beoordelingscapaciteit, vertrouwensrelaties en releasecoördinatie.
Een repository kan onbeperkt worden gekloond.
Een ervaren maintainer kan zijn aandacht niet onbeperkt verdelen.
Een effectief digitaal commonsmodel moet daarom vooral de duurzame productie, financiering en bescherming van die schaarse onderhoudscapaciteit organiseren.
Ostroms institutionele principes zijn daarvoor bruikbaar: duidelijk afgebakende verantwoordelijkheden, regels voor collectieve bijdragen, controle op naleving, werkbare conflictoplossing en governance op meerdere niveaus.
Toegepast op een softwaredependency betekent dit bijvoorbeeld dat vastligt wie beveiligingsmeldingen ontvangt, wie releasebevoegdheden bezit, wie onafhankelijke beoordelingen uitvoert, hoe langdurig onderhoud wordt gefinancierd en welke organisaties welke middelen bijdragen.
Dat is meer dan een beveiligingsproces.
Het is een institutioneel arrangement dat individuele bijdragen koppelt aan collectieve continuïteit.
Ook hier geldt een belangrijke theoretische beperking: Ostroms onderzoek bewijst niet dat elk open-sourceproject met zulke regels succesvol zal zijn.
Het laat zien dat de kwaliteit van instituties een verklaring kan zijn voor het verschil tussen duurzame samenwerking en collectief falen.
7. Heartbleed, Log4Shell, xz en Brotli: vier verschillende fouten, één terugkerende systeemvraag
De beveiligingsgeschiedenis van open source bevat verschillende incidenten die de verborgen afhankelijkheid tussen publieke code en private producten zichtbaar hebben gemaakt.
Ze zijn technisch niet identiek en mogen niet als één rechtstreeks bewezen causale reeks worden voorgesteld.
Wat ze delen, is een terugkerende vraag over de verdeling van verantwoordelijkheid in de softwareketen.
Heartbleed, 2014: de discrepantie tussen maatschappelijk belang en onderhoudscapaciteit
Heartbleed, CVE-2014-0160, betrof een implementatiefout in OpenSSL waardoor gevoelige gegevens uit procesgeheugen konden worden gelezen.
De kwetsbaarheid maakte zichtbaar hoe groot de afhankelijkheid van een relatief klein project inmiddels was geworden. Eghbals onderzoek documenteerde de financiële kwetsbaarheid van de onderhoudsstructuur rond OpenSSL.
Het incident bewijst niet dat meer financiering de specifieke programmeerfout noodzakelijkerwijs had voorkomen.
Het demonstreert wel hoe een maatschappelijk kritieke component kan bestaan zonder dat de financieringscapaciteit overeenkomt met de schaal van haar gebruik.
De oorspronkelijke Heartbleed-documentatie benadrukte bovendien dat het verspreiden van de correctie een verantwoordelijkheid was van besturingssysteemleveranciers, appliancefabrikanten en dienstenaanbieders.
Daarmee was de downstreamverantwoordelijkheid al zichtbaar, lang voordat de CRA werd aangenomen.
Log4Shell, 2021: de onzichtbare vermenigvuldiging van afhankelijkheden
Log4Shell, CVE-2021-44228, bevond zich in Apache Log4j, een veelgebruikte loggingbibliotheek voor Java.
De kwetsbaarheid illustreerde dat een component met een beperkte functionele rol toch een omvangrijke aanvalsvector kon worden.
Voor veel organisaties was de grootste operationele uitdaging niet uitsluitend de vraag of Apache een beveiligingsupdate had gepubliceerd.
Het probleem was vaststellen in welke eigen, ingekochte of indirect afhankelijke softwareproducten kwetsbare versies aanwezig waren.
De Apache Security Advisories tonen dat correcties beschikbaar kwamen, terwijl softwaregebruikers hun eigen blootstelling en migratiepaden moesten beoordelen.
Log4Shell laat daarmee zien dat een upstreamcorrectie en downstreamremediatie fundamenteel verschillende economische en operationele activiteiten zijn.
xz Utils, 2024: vertrouwen en onderhoudscapaciteit als aanvalsvlak
Bij xz Utils, CVE-2024-3094, ging het niet om een gewone programmeerfout.
Een aanvaller wist via een langdurig proces van bijdragen en vertrouwensopbouw kwaadaardige code in distributieartefacten te introduceren. De poging werd ontdekt voordat de getroffen versies breed in stabiele productieomgevingen terechtkwamen.
Hier was de integriteit van het ontwikkel- en releaseproces zelf het doelwit.
De Open Source Security Foundation en de OpenJS Foundation waarschuwden in april 2024 voor vergelijkbare pogingen tot sociale manipulatie en overname van onderhoudsrechten.
Het causale mechanisme verschilde dus wezenlijk van Heartbleed.
Maar de institutionele kwetsbaarheid was herkenbaar: een kleine groep personen beheerde software waarop een veel grotere groep organisaties vertrouwde.
Het incident illustreert vooral dat onderhoudscapaciteit niet uitsluitend een kwestie van financiering is. Vertrouwen, bevoegdheden, release-integriteit en opvolging zijn eveneens schaarse governancebronnen.
Brotli, 2026: een snelle upstreampatch is niet het einde van de verantwoordelijkheid
De Brotli-kwetsbaarheid van oktober 2026 maakt een vierde onderscheid zichtbaar.
De upstreambeheerders publiceerden beveiligingsreleases voor drie versielijnen.
Dat is bewijs van daadwerkelijk onderhoud, niet van de afwezigheid daarvan.
Toch blijft de vervolgvraag bestaan: welke softwareproducten gebruiken nog kwetsbare, vastgepinde, gekopieerde of aangepaste varianten van de decoder?
Een beveiligingscorrectie kan volledig beschikbaar zijn, terwijl andere partijen nog tijd nodig hebben voor inventarisatie, regressietesten, compatibiliteitsonderzoek, deployment en verificatie.
De impact van die vertraging hangt af van bereikbaarheid, configuratie en daadwerkelijke exploitability. Het bestaan van de CVE betekent niet automatisch dat iedere toepassing met Brotli op afstand kan worden overgenomen.
De economische observatie is specifieker.
De kosten van upstreamontwikkeling, releasepublicatie, distributie en daadwerkelijke toepassing bevinden zich bij verschillende partijen.
De afzonderlijke partijen hebben uiteenlopende belangen, verplichtingen en risicotoleranties. Deze vier gebeurtenissen zijn dus geen bewijs van één technische oorzaak. Ze tonen vier manieren waarop de maatschappelijke afhankelijkheid van gedeelde software groter kan zijn dan de organisatorische coördinatie die nodig is om haar veilig te houden.
8. Waarom Enterprise Architecture het verkeerde verklaringsframe is
Enterprise Architecture is ontworpen om de samenhang tussen bedrijfsdoelen, processen, informatie, applicaties en technologische infrastructuur inzichtelijk en bestuurbaar te maken.
Dat is waardevol.
Architectuurmodellen kunnen laten zien welke bedrijfscapabilities afhankelijk zijn van een bepaalde applicatie, welke applicaties afhankelijk zijn van een softwarecomponent en welke systemen risico lopen wanneer een dependency kwetsbaar blijkt.
Maar zo'n model verklaart nog niet waarom de onderliggende software in eerste instantie onvoldoende wordt gefinancierd.
Het verklaart evenmin waarom een externe leverancier, een individuele maintainer en een grote afnemer verschillende economische belangen hebben bij dezelfde component.
Het centrale probleem ligt immers niet uitsluitend binnen één onderneming.
Het ligt tussen ondernemingen, open-sourcegemeenschappen, leveranciers en afnemers.
Daarmee overstijgt het de organisatorische grenzen waarop klassieke Enterprise Architecture zich primair richt.
Een dependency kan technisch correct in een architectuurrepository zijn vastgelegd en toch onderdeel blijven van een economisch onhoudbare onderhoudsstructuur.
Een enterprise architect kan vaststellen dat applicatie A afhankelijk is van bibliotheek B.
Een CISO kan die dependency classificeren als kritisch.
Een product owner kan een herstelactie prioriteren.
Maar geen van deze activiteiten creëert automatisch een financieringsmechanisme dat garandeert dat bibliotheek B ook over drie jaar voldoende onderhoudscapaciteit heeft.
Daarom is EA als primaire verklaring een categoriefout.
Het vraagstuk is eerst economisch en institutioneel, daarna architecturaal.
Architectuur kan risico's zichtbaar maken, afhankelijkheden modelleren en beheerafspraken operationaliseren. Het kan echter geen collectieve prikkels vervangen die buiten de organisatie ontbreken.
De noodzakelijke verschuiving is daarom van een dependencyregistratie naar een verantwoordelijkheidsmodel over de volledige softwarewaardeketen.
Niet uitsluitend: welke component gebruiken wij?
Maar ook: wie profiteert ervan, wie onderhoudt haar, wie betaalt voor die instandhouding, wie kan herstel afdwingen en wie draagt de schade wanneer herstel uitblijft?
9. De Cyber Resilience Act als correctie van marktfalen
De Europese Cyber Resilience Act, Verordening (EU) 2024/2847, introduceert een relevante institutionele verandering.
De verordening koppelt cybersecurityverplichtingen aan producten met digitale elementen die binnen het toepassingsgebied op de Europese markt worden aangeboden.
Daarmee verschuift de juridische aandacht naar economische actoren die verantwoordelijkheid dragen voor de veiligheid van de producten die zij in de handel brengen.
Een fabrikant kan zich niet zonder meer aan zijn productverplichtingen onttrekken door te stellen dat een kwetsbare component oorspronkelijk gratis beschikbaar was.
Artikel 13, lid 5, vereist dat fabrikanten passende zorgvuldigheid betrachten wanneer zij componenten van derden integreren, uitdrukkelijk inclusief relevante open-sourcecomponenten.
Nog interessanter is artikel 13, lid 6.
Wanneer fabrikanten een kwetsbaarheid identificeren in een geïntegreerde component, moeten zij deze onder de daar beschreven voorwaarden terugmelden aan de partij die de component ontwikkelt of onderhoudt, de kwetsbaarheid adresseren en verhelpen, en relevante eigen correcties waar van toepassing upstream delen.
Dat creëert een wettelijke relatie tussen downstreamproductverantwoordelijkheid en upstreamonderhoud.
Ook de ondersteuningsperiode verandert de economische afweging. Artikel 13, lid 8, verplicht fabrikanten tot effectieve kwetsbaarheidsafhandeling gedurende een passende ondersteuningsperiode. Als uitgangspunt geldt minimaal vijf jaar, behalve wanneer de verwachte gebruiksduur van het product korter is. Producten met een langere verwachte gebruiksduur kunnen ook langer onderhoud vereisen.
Een fabrikant moet daardoor verder kijken dan de ontwikkelkosten op het moment van marktintroductie.
Het gebruik van een externe component brengt ook toekomstige verplichtingen met zich mee.
De fasering is juridisch relevant
De CRA is op 10 december 2024 in werking getreden.
Sinds 11 september 2026 gelden de meldverplichtingen van artikel 14 voor fabrikanten met betrekking tot actief uitgebuite kwetsbaarheden en ernstige beveiligingsincidenten binnen het toepassingsgebied. De meldprocedure kent onder meer een eerste waarschuwing binnen 24 uur en een verdere melding binnen 72 uur.
De belangrijkste overige productverplichtingen worden vanaf 11 december 2027 van toepassing.
Dat betekent dat niet iedere nieuw gepubliceerde CVE nu al automatisch een verplichte CRA-melding veroorzaakt. Daarvoor zijn de specifieke wettelijke meldcriteria bepalend.
Ook geldt de CRA niet ongedifferentieerd voor alle open-sourceontwikkelaars en softwaregebruikers.
Niet-commerciële open-sourceontwikkeling kent een bijzondere behandeling. Voor erkende open-source software stewards bestaat een afzonderlijk, lichter regime. Hun specifieke meldverplichtingen beginnen volgens de wettelijke fasering in december 2027.
En een organisatie die uitsluitend software voor intern gebruik afneemt, wordt niet automatisch fabrikant in de zin van de CRA.
Die nuances beperken de directe juridische reikwijdte van de centrale stelling.
De juiste claim is daarom niet dat iedere gebruiker wettelijk onderhoudsplichtig wordt. De juiste claim is dat de CRA marktdeelnemers binnen haar toepassingsgebied verplicht de beveiligingskosten van hun digitale producten, inclusief geïntegreerde componenten, veel explicieter te dragen en te organiseren.
Dat is een wezenlijke verandering van de prikkelstructuur.
De Europese Commissie beschrijft deze verantwoordelijkheid expliciet als een verplichting die zich uitstrekt over de productlevenscyclus en de softwareleveringsketen.
10. De CRA internaliseert kosten, maar financiert de commons niet automatisch
Hier ligt een belangrijk onderscheid tussen regulering en een volledige welvaartseconomische oplossing.
De CRA kan fabrikanten dwingen meer aandacht en middelen te besteden aan productbeveiliging, documentatie, updates en kwetsbaarheidsafhandeling.
Daarmee verhoogt zij de private kosten van het onvoldoende beheersen van bepaalde beveiligingsrisico's.
Een fabrikant die voorheen uitsluitend keek naar de aanschafprijs van een component, moet nu ook rekening houden met toekomstige productverplichtingen.
In economische termen wordt een groter deel van de lifecyclekosten meegenomen in de individuele productbeslissing.
Maar dat betekent niet automatisch dat de oorspronkelijke open-sourcemaintainer meer geld ontvangt.
Een onderneming kan aan wettelijke verplichtingen voldoen door kwetsbaarheden intern te verhelpen, een eigen fork te onderhouden, aanvullende beveiligingsmaatregelen te treffen of commerciële ondersteuning in te kopen.
Ook kan regulering ertoe leiden dat fabrikanten terughoudender worden bij het opnemen van kleine, slecht onderhouden componenten.
Dat kan de veiligheidsprikkels verbeteren, maar eveneens marktdrempels verhogen of extra lasten veroorzaken voor kleine softwareleveranciers.
De maatschappelijke uitkomst hangt af van de verhouding tussen vermeden schade, extra onderhoudsinvesteringen, nalevingskosten en mogelijke effecten op innovatie.
Er is dus geen theoretische garantie dat de CRA zelfstandig het maatschappelijk optimale onderhoudsniveau realiseert. Het is nauwkeuriger om haar te beschrijven als een gedeeltelijke internalisering van softwareketenrisico's, niet als een volledige financieringsoplossing voor digitale infrastructuur.
Dit onderscheid maakt de analyse sterker.
Waar Eghbal het financieringsprobleem zichtbaar maakte, verplicht de CRA specifieke marktdeelnemers om beter rekening te houden met de beveiligingsgevolgen van hun componentkeuzes.
Maar de stap van productverantwoordelijkheid naar structureel onderhoud van gemeenschappelijke software vereist aanvullende institutionele afspraken.
De wet verandert de prikkels.
De markt en de betrokken gemeenschappen moeten vervolgens nog bepalen hoe ze daarop reageren.
11. Van compliance naar een duurzame onderhoudseconomie
Als de oorzaak gedeeltelijk economisch is, kan een organisatie het probleem niet oplossen door alleen meer kwetsbaarheidsscanners, architectuurdiagrammen of SBOM-bestanden te produceren.
Die instrumenten blijven noodzakelijk, maar ze zijn op zichzelf onvoldoende.
Een structurele aanpak vraagt om vier samenhangende mechanismen.
Ten eerste: economische transparantie over afhankelijkheden.
Een organisatie moet niet alleen weten welke componenten in haar producten aanwezig zijn, maar ook welke onderhoudsafspraken, ondersteuningsperioden, releaseprocedures en afhankelijkheidsrisico's eraan verbonden zijn.
Een Software Bill of Materials kan de technische basis leggen. Vulnerability Exploitability eXchange (VEX) kan helpen om bekende kwetsbaarheden te koppelen aan hun daadwerkelijke toepasbaarheid in een product. Provenance en verifieerbare builds kunnen inzicht bieden in de herkomst van distributieartefacten.
Maar de uiteindelijke vraag blijft wie bevoegd en in staat is om een product binnen de afgesproken termijn te herstellen.
Ten tweede: structurele financiering in plaats van incidentele donaties.
Wanneer een organisatie economisch afhankelijk is van een kritieke open-sourcecomponent, kan structurele ondersteuning een rationele risicobeperkende investering zijn.
Denk aan langdurige onderhoudscontracten, gedeelde financieringsconstructies, betaalde ontwikkelcapaciteit, bijdragen aan foundationstructuren of afspraken over gezamenlijk beveiligingsonderzoek.
De financiering hoeft niet uitsluitend naar de oorspronkelijke auteurs te gaan. Het relevante doel is dat de benodigde onderhoudscapaciteit aantoonbaar beschikbaar blijft.
Onderhoud moet worden behandeld als een terugkerende kostenpost van digitale productie, niet als vrijblijvende liefdadigheid.
Ten derde: institutionele governance voor onderhoud en releases.
Ostroms perspectief betekent dat organisaties afspraken nodig hebben over reviewbevoegdheden, maintaineropvolging, coordinated vulnerability disclosure, release signing, betrouwbare distributie en het beheersen van conflicterende belangen.
Juist de xz-aanval laat zien waarom een formeel veilige CI/CD-pijplijn onvoldoende is wanneer de sociale en bestuurlijke structuur achter de releases kan worden gemanipuleerd.
Goed functionerende governance moet niet uitsluitend controleren welke code wordt toegevoegd, maar ook hoe vertrouwen en bevoegdheden ontstaan.
Ten vierde: meten of correcties daadwerkelijk hun bestemming bereiken.
Een organisatie zou het verschil moeten kunnen vaststellen tussen het moment waarop een kwetsbaarheid bekend wordt, een upstreamcorrectie beschikbaar komt, een beveiligingsrelease verschijnt, een productleverancier de correctie integreert en de afnemer daadwerkelijk beschermd is.
Dat zijn verschillende gebeurtenissen.
Een groene CI/CD-status bewijst geen veilige supply chain wanneer een kwetsbare component nog steeds in een productieartefact aanwezig is.
En een gepubliceerde upstreampatch bewijst geen maatschappelijke risicoreductie wanneer een groot deel van de afhankelijke systemen de correctie niet heeft ontvangen.
Een bruikbare governance-indicator is daarom niet uitsluitend time to patch, maar de aantoonbare tijd tussen ontdekking en effectieve remediatie bij de relevante afnemers.
12. Wat zou deze economische verklaring daadwerkelijk bewijzen?
De vier besproken kwetsbaarheden illustreren de probleemstelling, maar vormen op zichzelf geen statistisch bewijs dat onderinvestering de gemeenschappelijke oorzaak was.
Daarvoor is systematisch empirisch onderzoek nodig.
Een toetsbare onderzoeksopzet zou kritieke open-sourcecomponenten gedurende meerdere jaren kunnen volgen en onderscheid maken tussen commerciële ondersteuning, individuele onderhoudsinspanningen, releasekwaliteit en downstreamgebruik.
De belangrijkste hypothese is dat projecten met een relatief grote maatschappelijke afhankelijkheid, maar beperkte internalisering van onderhoudsbaten, onder vergelijkbare omstandigheden minder onderhoudscapaciteit hebben dan projecten waarbij financiering en gebruik beter op elkaar aansluiten.
Een tweede hypothese is dat collectieve governancearrangementen met duidelijke besluitvorming, financieringsafspraken en controlemechanismen bijdragen aan stabielere onderhouds- en releaseprocessen.
Een derde hypothese betreft de CRA.
Als de verordening de verwachte kosten van onvoldoende beveiligingsonderhoud daadwerkelijk verschuift naar betrokken fabrikanten, zou na implementatie onder vergelijkbare omstandigheden een verandering zichtbaar moeten worden in hun investeringen, componentselectie, upstreambijdragen en herstelprocessen.
Dat effect kan echter niet uitsluitend worden afgeleid uit het aantal gemelde kwetsbaarheden of geproduceerde SBOM's.
Meer meldingen kunnen immers duiden op een verslechtering van de veiligheid, maar ook op betere detectie en transparantie.
Evenmin betekent een sneller upstreampatchproces automatisch dat de afhankelijkheidsketen veiliger is geworden.
Een gedegen evaluatie vraagt om meetbare blootstellingsduur, daadwerkelijke componentadoptie, correctiekwaliteit, exploitability en onderbouwde vergelijking tussen organisaties en perioden.
Zonder zulke metingen blijft de economische these een plausibel verklaringsmodel, geen bewezen monocausale verklaring.
Dat is geen zwakte van het model, maar een noodzakelijke grens tussen wetenschappelijke theorie en empirische vaststelling.
13. De digitale brug is nooit gratis geweest
Tien jaar na Eghbals Roads and Bridges is de fundamentele paradox nog altijd herkenbaar.
We hebben een digitale economie opgebouwd waarin organisaties zeer grote economische waarde ontlenen aan componenten die zonder gebruiksvergoeding kunnen worden gekopieerd.
Dat is een van de belangrijkste productiviteitsvoordelen van open source.
Maar de afwezigheid van een licentieprijs betekent niet dat ontwikkeling, onderhoud, beveiliging en continuïteit geen economische kosten kennen.
Die kosten verdwijnen niet.
Ze komen terecht bij vrijwilligers, werknemers, foundations, leveranciers, afnemers of uiteindelijk de samenleving.
De fout ontstaat wanneer de voordelen systematisch op één plek worden gerealiseerd, terwijl de onderhoudskosten en risico's elders terechtkomen zonder passend financierings- of verantwoordelijkheidsmechanisme.
Dat kan zich manifesteren als onderprovisie van onderhoud, free-riding, onduidelijke bevoegdheden, kwetsbare maintainerstructuren of langdurig achterblijvende beveiligingsupdates.
Heartbleed, Log4Shell, xz en Brotli zijn technisch verschillende gebeurtenissen.
Maar gezamenlijk maken ze zichtbaar hoe kwetsbaar een digitale infrastructuur kan worden wanneer de maatschappelijke waarde van een component niet wordt weerspiegeld in de instituties die haar veilig moeten houden.
De CRA is een belangrijke wijziging in die institutionele omgeving.
Niet omdat zij iedere kwetsbaarheid zal voorkomen.
Niet omdat zij open-sourceprojecten automatisch financiert.
Maar omdat zij voor producten binnen haar reikwijdte een explicietere verbinding legt tussen het economische besluit om software op de markt te brengen en de verplichting om de beveiliging ervan gedurende de productlevenscyclus te organiseren. Daarmee verschuift de discussie van de goede of slechte bedoelingen van technologiebedrijven naar de vraag welke actor economisch en juridisch verantwoordelijk is voor de risico's die hij binnen zijn productketen introduceert.
Dat is uiteindelijk ook waarom Enterprise Architecture niet het juiste primaire verklaringsframe is.
Architectuur beschrijft de brug, haar verbindingen en de systemen die ervan afhankelijk zijn.
Welvaartseconomie verklaart waarom niemand vrijwillig voldoende wil bijdragen aan het onderhoud ervan.
Institutionele economie laat zien hoe collectieve afspraken die uitkomst kunnen veranderen.
En de Cyber Resilience Act legt een deel van de verantwoordelijkheid juridisch vast bij de partijen die digitale producten op de markt brengen.
Het probleem was nooit dat open source gratis was. Het probleem was dat de prijs van het gebruik los kon staan van de verantwoordelijkheid voor instandhouding.
De volgende fase van digitale volwassenheid vraagt daarom om meer dan veilige code en gedocumenteerde architectuur.
Zij vraagt om een onderhoudseconomie waarin economische voordelen, bevoegdheden, kosten en verantwoordelijkheden beter op elkaar aansluiten.
Want een digitale brug kan door iedereen worden gebruikt.
Maar niet iedereen kan ervan blijven uitgaan dat iemand anders haar onderhoud betaalt.
Wetenschappelijke en primaire bronnen
Digitale infrastructuur en economische theorie
- Eghbal, N. (2016). Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure. Ford Foundation.
- Lerner, J., & Tirole, J. (2002). Some Simple Economics of Open Source. The Journal of Industrial Economics, 50(2), 197-234.
- Spolsky, J. (2002). Strategy Letter V.
- Samuelson, P. A. (1954). The Pure Theory of Public Expenditure. The Review of Economics and Statistics, 36(4), 387-389.
- Olson, M. (1965). The Logic of Collective Action: Public Goods and the Theory of Groups. Harvard University Press.
- Ostrom, E. (1990). Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge University Press.
Brotli, softwarebeveiliging en supply chain
- Google Open Source Blog (2015). Introducing Brotli: a new compression algorithm for the internet.
- Alakuijala, J., & Szabadka, Z. (2016). RFC 7932: Brotli Compressed Data Format. IETF.
- Google Brotli. Official releases and security updates. Geraadpleegd op 25 oktober 2026.
- Apache Software Foundation. Log4j Security Advisories.
- OpenSSF & OpenJS Foundation (2024). Alert for Social Engineering Takeovers of Open Source Projects.
Europese regelgeving
- Europees Parlement en Raad (2024). Verordening (EU) 2024/2847, Cyber Resilience Act.
- Europese Commissie (2026). Cyber Resilience Act: Manufacturers.
- Europese Commissie (2026). Cyber Resilience Act: Open source.
- Europese Commissie (2026). Cyber Resilience Act: Reporting obligations.
Methodologische verantwoording: dit artikel combineert primaire historische bronnen, theoretische economische modellen, openbare security-advisories en geldende Europese regelgeving. De economische interpretatie van Google's Brotli-strategie is een toetsbare hypothese, geen bewezen interne intentie. De besproken incidenten illustreren verschillende typen systeemrisico en zijn niet gepresenteerd als bewijs van één gemeenschappelijke technische oorzaak. De CRA-analyse beschrijft de stand van de regelgeving op 25 oktober 2026 en vormt geen productspecifiek juridisch conformiteitsoordeel.
Zie ook
AI & Security Intelligence
Wekelijkse nieuwsbrief met AI updates, security alerts en compliance inzichten, direct in uw inbox.
Security & AI Operating Model
Advisory met executiekracht
Van BIO2 en NIS2 tot EU AI Act, embedded in uw operating model, niet als extern project. Maandelijks opzegbaar, met assessments als bewijsvoering.