Overdag voelt software vaak beheersbaar. De applicatie draait, alles lijkt stabiel en zolang incidenten binnen bekende patronen blijven, ontstaat al snel het idee dat de belangrijkste risico’s onder controle zijn. Zelfs bij complexe systemen gaat dit vaak een lange tijd goed. Er is genoeg ervaring opgebouwd, mensen weten waar de gevoeligheden zitten en zolang veranderingen beperkt blijven, lijkt dat voldoende.
Maar software laat zich pas echt kennen wanneer iemand er zonder terughoudendheid naar kijkt. Niet met bekende context of ervaring, maar puur op basis van wat er feitelijk staat. En dat is precies wat AI nu doet – en veel sneller dan welke beveiligingsexpert dan ook.
Bijvoorbeeld: Geef een model toegang tot een codebase en een duidelijke security-opdracht, en je krijgt steeds vaker geen algemene analyse meer, maar een concrete kwetsbaarheid. Soms zelfs inclusief een exploitpad. Met exploitpad bedoel ik de concrete stappen waarmee een kwetsbaarheid daadwerkelijk misbruikt kan worden – dus niet alleen dát er een probleem zit, maar hoe je er van buitenaf misbruik van maakt (bijv. input > fout > toegang/data). Dat is geen theorie meer, maar praktijk.
Het ongemakkelijke aan deze ontwikkeling
De eerste reflex is logisch: dit is een securityprobleem. En dus volgt al snel de gedachte aan meer tooling, meer scans en strengere controles. Maar daar zit het echte probleem niet.
De vraag is niet hoe AI deze kwetsbaarheden vindt.
De vraag is waarom ze er nog zitten.
Daarmee verandert het gesprek van security naar software zelf. Want kwetsbaarheden staan zelden op zichzelf. Ze ontstaan in systemen die in de loop der tijd moeilijker te begrijpen zijn geworden, waarin aannames zich opstapelen en waar hele stukken code blijven bestaan omdat niemand precies weet wat er gebeurt als je eraan komt.
Een kwetsbaarheid is niet alleen een technisch probleem,
maar een signaal over de staat van het systeem.
Het verschil zit niet in het probleem, maar in de snelheid
Wat AI blootlegt, is niet nieuw. Deze kwetsbaarheden zijn vaak niet gisteren ontstaan. Ze zijn meegegroeid met het systeem, verstopt geraakt in afhankelijkheden of simpelweg nooit meer opnieuw beoordeeld omdat de programmeercode ooit “goed genoeg” leek.
Waar het vroeger veel tijd en expertise kostte om dit soort issues te vinden, gebeurt dat nu veel sneller. Daardoor verandert niet wat er mis is, maar wel hoe snel het zichtbaar wordt. Wat eerst latent was, wordt ineens actueel.
Waar het echt misgaat
In de praktijk worden dit soort problemen vaak gekoppeld aan capaciteit. Alsof het vooral gaat om te weinig security-expertise of te weinig controles.
Maar als een systeem lastig te doorgronden is, veranderingen onvoorspelbaar maakt en alleen veilig voelt voor de mensen die er al jaren mee werken, dan zit het probleem niet alleen in capaciteit. Dan zit het in de software.
Waar oude keuzes diep zijn ingebakken en waar kennis impliciet blijft. Dat soort plekken functioneren vaak “goed genoeg”, totdat er echt druk op komt. AI legt juist daar de zwakke plekken bloot, omdat het zonder aarzeling kijkt naar wat er staat.
Uiteindelijk gaat dit niet over tooling, maar over hoe je met software omgaat.
Zolang software iets is dat je bouwt, oplevert en daarna vooral draaiend houdt, blijven dit soort risico’s bestaan. Onderhoud wordt uitgesteld, kwaliteit schuift naar later en eigenaarschap vervaagt zodra een project klaar is.
Maar bedrijfskritische software gedraagt zich niet als een afgerond project. Het is iets dat beter of slechter wordt over tijd, afhankelijk van hoeveel aandacht het krijgt. Als die aandacht ontbreekt, wordt technische spanning langzaam normaal.
Totdat iets als AI dat ineens zichtbaar maakt en, het slechtste geval, zelfs actief misbruik gaat maken.
AI verandert niet wat goede software is. Het verandert hoe snel je ziet waar de gaten zitten. En dat maakt negeren gevaarlijk. Het maakt duidelijk welke systemen echt gezond en veilig zijn, en welke vooral stabiel lijken zolang je niet té kritisch kijkt.
En nu?
Twijfel je of jouw systemen ook onderdelen bevatten waar niemand echt aan wil komen?
Kijk dan niet alleen naar incidenten of rapportages, maar juist naar waar veranderingen lastig worden. Waar kennis impliciet blijft. Waar teams liever voorzichtig om iets heen werken dan het echt verbeteren. Dat zijn vaak dezelfde plekken waar kwetsbaarheden blijven zitten. En waar software langzaam verschuift van asset naar risico.
