Bij een bank, verzekeraar of vermogensbeheerder is de discussie over kwetsbaarheden een terugkerend patroon: beveiliging wil een klasse problemen uitbannen, engineering wijst op de impact van upgrades, en de planning wordt druk door regressietesten en wijzigingsfreeze. Het gevolg is vaak hetzelfde: uitzonderingen, compensatiemaatregelen en een roadmap die maanden (of jaren) opschuift. Dat klinkt logisch—maar volgens recente inzichten is het probleem verschoven.
Waar het vroeger verdedigbaar was om een backlog met bekende CVE’s te accepteren, verandert de realiteit. Frontier AI-modellen versnellen het vinden en combineren van zwakheden, waardoor de kloof tussen “bekend” en “praktisch misbruikbaar” kleiner wordt. Daardoor komt vooral het risico rond de software supply chain op de voorgrond. In dit artikel lees je hoe software supply chain moderniseren kan helpen om minder kwetsbaarheden in je omgeving te krijgen, zonder meteen je hele applicatielandschap te verplaatsen.
Waarom een kwetsbaarheden-backlog niet meer “gewoon kan”
Jarenlang was het voor veel financiële organisaties een bewuste trade-off om kwetsbaarheden te erkennen, maar te accepteren zolang ze niet actief werden uitgebuit. De aanname was dat exploitatie tijd, expertise en incentives vereist—en dat jouw geplande upgradecyclus genoeg buffer bood. Bovendien waren veel kwetsbaarheden aanwezig in legacycomponenten, maar bleven ze in de praktijk “slapend”.
Die redenering wordt kwetsbaar wanneer aanvalsmethoden sneller worden. Frontier modellen kunnen code lezen, zwakheden sneller identificeren en ketenaanvallen uitvoeren die eerder te omslachtig waren. Daardoor kan een CVE die ooit onwaarschijnlijk leek, ineens binnen bereik komen. Nog belangrijker: die versnelling treft precies het gebied waar financiële organisaties veel uitgestelde risico’s hebben—de keten van leveranciers, libraries, containers en bouwtools die je applicaties voeden.
Exploitatie haalt phishing in: wat betekent dat voor je prioriteiten?
Er is een duidelijke verschuiving in het type initial access dat bij inbraken wordt gebruikt. Volgens de bron haalt exploitatie van kwetsbaarheden inmiddels phishing in als belangrijkste ingang bij breaches binnen financiële dienstverlening. Daarnaast hebben meer dan de helft van leveranciers in die sector ten minste één kwetsbaarheid met hoge ernst. Voor een gereguleerde organisatie betekent een gecompromitteerd pakket niet alleen technisch falen: het kan uitmonden in operationele incidenten, gesprekken met toezichthouders en reputatieschade richting klanten.
Praktisch gezien betekent dit dat een uitzondering die 18 maanden geleden is goedgekeurd, mogelijk gebaseerd is op een dreigingsbeeld dat inmiddels achterhaald is. Met andere woorden: het probleem is niet dat teams onredelijk zijn geweest, maar dat het model waarop “uitstel” was gebouwd, niet meer klopt.
Van applicaties naar inputs: het verschil tussen moderniseren en investeren
Wanneer security teams roepen dat een organisatie moet moderniseren, horen engineeringleiders vaak een heel pakket aan applicatie-werk: refactoring, runtime-upgrades, datalaag-migraties en uitgebreide her-testen van downstream afhankelijkheden. Dat is inderdaad een meerjarige, kapitaalintensieve operatie met echt operationeel risico. Daardoor is weerstand bij platform- en engineeringteams begrijpelijk.
Maar de kern van het nieuwe risico ligt niet primair in de applicatiecode zelf. Het zit onder de applicatie: de software supply chain die de applicatie-omgeving vormt. Denk aan basisimages met veel kwetsbaarheden, open source libraries die uit publieke registries komen zonder heldere herkomst, en build tooling die onvoldoende geïnventariseerd is. In deze benadering is de “input” (wat je bouwt en wat je invoert) blootgesteld, terwijl je “consumer” (de applicatie die die input gebruikt) mogelijk dezelfde functionaliteit kan blijven behouden.
Het belangrijkste inzicht is daarom eenvoudig: je kunt je inputs verbeteren zonder dat je meteen je businesslogica hoeft te herschrijven. Dat maakt software supply chain moderniseren een andere—en vaak beheersbaardere—vorm van modernisatie.
Wat software supply chain moderniseren in de praktijk inhoudt
1) Beveilig wat je bouwt, niet alleen wat je later repareert
Een aanpak die aansluit bij dit nieuwe denken is “secure-by-design”: minimalistische en geharde containerimages en open source componenten die continu opnieuw worden opgebouwd. Het doel is om vermijdbare kwetsbaarheden niet in de omgeving te laten komen. Door minder componenten te gebruiken, verklein je ook het werk dat security teams later moeten doen: minder te scannen, minder te triageren en minder aanvalsoppervlak “door constructie”.
Deze werkwijze verschuift de focus van handmatige remediation naar preventie in de bouwstroom.
2) Patch oudere versies met behoud van compatibiliteit
Niet alle software staat klaar om direct geüpgraded te worden. Daarom is het relevant dat beveiligingsfixes kunnen worden “teruggeporteerd” naar de versies die financiële instellingen nog gebruiken. Zo kan een team met een ouder runtime- of frameworkniveau toch beveiligde en vertrouwde artifacts toepassen, zonder de migratieplanning te verstoren.
Het resultaat: ook teams die nog niet aan een upgrade toe zijn, verminderen hun blootstelling aan kwetsbaarheden—zonder dat ze hun traject moeten omgooien.
3) Laat platformteams centraal de basis bijwerken
Voor platformteams kan de operationele wijziging kleiner zijn dan vaak wordt gedacht. Veel grote financiële organisaties werken met interne “golden image”-programma’s om fundamenten te standaardiseren voor talloze applicatieteams. Het onderhouden daarvan kan echter traag en kostbaar zijn.
Door upstream bronmateriaal te vervangen door geharde, vertrouwde varianten, kan een platformteam die geharde artifacts één keer klaarzetten. Vervolgens worden ze via registries en pipelines als goedgekeurde bouwblokken gedeeld met bestaande teams. Daarmee verandert vulnerability management van “elk team zoekt en bouwt zelf” naar “één platformteam beheert een trusted set”. Applicatieteams erven fixes, in plaats van er zelf aan te moeten sleutelen.
SBOM en herleidbaarheid: sneller antwoorden bij audits
Een extra voordeel van moderne supply chain-beveiliging is dat bouwartefacten verifieerbare context mee kunnen krijgen. In de bron wordt genoemd dat elke artifact Software Bills of Materials (SBOMs) en verifieerbare provenance kan bevatten. Dat maakt het beantwoorden van auditvragen praktischer en minder ad-hoc.
Vragen zoals “Wat draait er precies?”, “Waar komt het vandaan?” en “Hoe wordt het onderhouden?” worden eenvoudiger te onderbouwen. Daardoor kunnen platform- en securityteams weer meer tijd besteden aan hun kernwerk: het leveren van betrouwbare software aan klanten, in plaats van steeds opnieuw documentatie- en onderzoekslast af te handelen.
De verborgen kosten van “we laten het zo”
Het vasthouden aan de status quo is zelden een echte zero-risk keuze. Het risico zit alleen anders verdeeld. In de bron worden meerdere kosten genoemd die je pas ziet wanneer je ze bij elkaar optelt.
- Engineeringcapaciteit verdwijnt in repetitieve CVE-triage in plaats van in roadmap-werk.
- Noodresponse cycli nemen tijd en aandacht weg, vooral wanneer campagnes zich richten op veelgebruikte pakketten.
- Auditbevindingen worden moeilijker af te sluiten door herhaling van dezelfde typen issues en de vermoeidheid die daarbij ontstaat.
- Modernisering kan stagneren wanneer teams te druk zijn met patchen om nieuwe systemen daadwerkelijk te implementeren.
Daartegenover staat dat het beveiligen van een softwarefundament vaak een afgebakende en relatief omkeerbare stap kan zijn. Je raakt vooral de build-keten, niet direct de logica die omzet genereert. In de bron wordt bovendien benadrukt dat het kunt beginnen met één platformteam en een beperkte set images, waarna je kunt opschalen.
De roadmap blijft van jullie: beveiliging tijdens de transitie
Een belangrijk misverstand is dat securityvoordelen pas komen wanneer de modernisering “af” is. De bron benadrukt juist het tegenovergestelde: security verbetert al tijdens het traject wanneer je eerst de software supply chain aanpakt.
Door steeds meer van het softwarelandschap te bouwen op vertrouwde defaults, verschuift het bredere risicoprofiel. Je komt minder in de reactieve modus (continu patchen achteraf) en meer in de preventieve modus (meestal de kwetsbaarheden niet meekrijgen). Dat is in de bron beschreven als secure-by-default in de praktijk.
Conclusie: moderniseren begint bij de keten
Financiële organisaties hebben begrijpelijkerwijs lang ingezet op stabiliteit, omdat downtime en grootschalige wijzigingen in hun context zwaar wegen. Maar de dreigingsomgeving is veranderd: sneller misbruik, minder marge tussen “bekend” en “praktisch exploiteerbaar”, en een duidelijke toename van aanvallen via kwetsbaarheden.
Daarom is het verstandig om software supply chain moderniseren centraal te stellen. Door basisimages, libraries en bouwartefacten te hardenen en waar nodig oudere versies te blijven patchen met compatibiliteit, verklein je je blootstelling zonder meteen je volledige applicatielandschap te herschrijven. Bovendien maken SBOM’s en herleidbaarheid je auditwerk lichter—en geef je engineering en security weer ruimte voor hun echte prioriteiten.
Wil je je begrip van dit thema verdiepen, dan zijn ook deze artikelen relevant: wat 500.000 actieve credentials op GitHub kunnen betekenen voor je supply chain en risicobeheer en hoe agentic security je benadering van kwetsbaarheidsrisico kan veranderen. Door die inzichten te combineren met supply chain modernisering krijg je een robuuster verdedigingsmodel tegen het tempo van moderne aanvallen.
Bron: https://thehackernews.com/2026/10/how-financial-services-companies-can.html
