Bolt scant je app automatisch op beveiliging bij publicatie

TL;DR

• Wat: Bolt.new laat bij elke publicatie automatisch een beveiligingsagent je app scannen, kwetsbaarheden patchen en versiebeheer bijhouden.
• Waarom relevant: AI-gegenereerde code bevat tot 2,7 keer vaker beveiligingslekken dan code die mensen schrijven — en als ondernemer wil je niet dat jouw klantdata op straat ligt.
• Wat je ermee kunt: Controleer of het platform waarmee jij apps bouwt (of laat bouwen) automatische beveiligingsscans biedt vóórdat je live gaat.

Ik viel deze week over een tweet van Santiago Valdarrama (@svpino) waarin hij laat zien wat Bolt.new doet zodra je op 'Publish' klikt: een beveiligingsagent scant je app, patcht problemen automatisch, controleert of alles nog werkt en slaat elke wijziging op met versiebeheer. Zijn opmerking erbij: "The only way to get people to build secure apps is to do it automatically for them." Dat vond ik een zin om even bij stil te staan.

Wat doet Bolt precies bij publicatie?

Bolt.new is een AI-platform waarmee je zonder diepgaande programmeerkennis webapplicaties kunt bouwen. Denk aan een interne tool voor je team, een klantportaal of een eenvoudige webshop. Het bijzondere aan de workflow die Santiago beschrijft, zijn vier stappen die automatisch starten wanneer je op 'Publish' klikt:

1. Een beveiligingsagent scant je hele app. Niet alleen de database, maar ook de code die in de browser draait.
2. Gevonden problemen worden automatisch gepatcht. Denk aan ontbrekende toegangscontroles op je database of API-sleutels die per ongeluk zichtbaar zijn in de broncode.
3. Er wordt gecontroleerd of de app nog correct bouwt. Een patch die iets kapotmaakt, is immers erger dan het probleem zelf.
4. Elke wijziging wordt als versie opgeslagen. Gaat er toch iets mis? Dan kun je eenvoudig terugdraaien.

Wat mij hier opvalt: dit is geen optionele stap die je als gebruiker moet onthouden. Het zit ingebakken in het publicatieproces. Je kúnt het niet overslaan. En dat is precies de gedachte achter Santiago's opmerking — beveiliging werkt pas als mensen er niet over na hoeven te denken.

Waarom is dit relevant? De cijfers zijn vrij helder

Om te begrijpen waarom automatische beveiliging bij AI-gebouwde apps belangrijk is, helpt het om naar de cijfers te kijken. En die zijn eerlijk gezegd best ontnuchterend.

Een onderzoek van Escape.tech scande 5.600 gepubliceerde apps die met AI-tools waren gebouwd. Het resultaat: meer dan 2.000 kwetsbaarheden met hoge impact en zo'n 400 gelekte geheimen — denk aan API-sleutels en wachtwoorden. Ruwweg één op de drie apps had een serieus beveiligingsprobleem.

Een analyse van CodeRabbit op bijna 500 open-source projecten liet zien dat AI-gegenereerde code tot 2,74 keer vaker beveiligingslekken bevat dan code die door mensen is geschreven. Logicafouten kwamen 75% vaker voor.

Ik vind het eerlijk gezegd niet verbazend. AI-modellen zijn getraind om werkende code te leveren, niet per se veilige code. Het model optimaliseert voor functionaliteit — "het doet wat je vroeg" — maar denkt niet automatisch na over wie er nog meer bij je database kan, of je wachtwoordbeleid sterk genoeg is, of je API-sleutel niet zichtbaar is voor iedereen die je broncode opent.

Wat zijn de meest voorkomende kwetsbaarheden?

Volgens een analyse van VibeAppScanner zijn dit de vier kwetsbaarheden die in vrijwel elke Bolt-app opduiken:

• Zichtbare API-sleutels: OpenAI-, Stripe- en andere geheime sleutels die gewoon in de JavaScript-code van je website staan. Een aanvaller kan ze zo uitlezen.
• Ontbrekende databasebeveiliging: Geen Row Level Security (RLS) op Supabase-tabellen, waardoor je data in principe voor iedereen toegankelijk is.
• Missende beveiligingsheaders: Zonder headers als Content-Security-Policy en Strict-Transport-Security is je app kwetsbaar voor aanvallen als cross-site scripting.
• Zwakke authenticatie: Geen wachtwoordeisen, geen e-mailverificatie, geen limiet op inlogpogingen.

Kun je je voorstellen wat het betekent als je een klantportaal bouwt met AI en je Stripe-sleutel staat gewoon leesbaar in de broncode? Dat is geen theoretisch risico — dat is wat er bij duizenden apps daadwerkelijk gebeurt.

Wat betekent dit voor je als ondernemer?

Stel dat je als ondernemer een interne tool laat bouwen, of zelf snel iets in elkaar zet met een AI-platform. De drempel om iets te maken is enorm verlaagd — en dat is op zich positief. Maar de drempel om iets veiligs te maken, is niet automatisch mee naar beneden gegaan.

Hier zit de kern van wat Santiago zegt. Als je beveiliging afhankelijk maakt van de discipline van de gebruiker, gaat het mis. De meeste ondernemers die met zo'n tool werken, zijn geen beveiligingsexperts. Ze willen een werkend product. En dat is logisch.

De aanpak van Bolt — beveiliging als automatisch onderdeel van het publicatieproces — is wat mij betreft een stap in de goede richting. Het verschuift de verantwoordelijkheid van "jij moet eraan denken" naar "wij doen het voor je."

Een kanttekening

Ik wil wel iets nuanceren. Bolt's ingebouwde scan richt zich volgens de documentatie vooral op databasebeveiliging — met name Supabase-configuraties zoals RLS-beleid en permissies. Dat is waardevol, maar het is niet hetzelfde als een volledige beveiligingsaudit van je hele applicatie. Externe scanners zoals VibeAppScanner en Vibe Knight bestaan niet voor niets. Ze vinden kwetsbaarheden die buiten de scope van Bolt's eigen scan vallen.

Ik denk dat het eerlijk is om te zeggen: de automatische scan is een goed vangnet, maar het is niet kogelvrij. Als je een app bouwt die gevoelige klantgegevens verwerkt of betalingen afhandelt, zou ik aanraden om ook een onafhankelijke scan te laten doen.

De bredere trend: beveiliging als standaard, niet als optie

Wat ik interessant vind aan deze ontwikkeling, is dat het past in een breder patroon. We zien het ook bij andere platforms: beveiliging wordt steeds vaker ingebouwd als standaardstap in plaats van als iets dat je er achteraf bij moet doen.

Dat is vergelijkbaar met hoe autogordels werken. Je hoeft niet na te denken over of je hem omdoet — het alarm gaat af als je het niet doet. De veiligste aanpak is de aanpak die geen extra moeite kost.

Voor de gemiddelde ondernemer die met AI-tools werkt, is dit een belangrijk selectiecriterium. Als je een platform kiest om iets mee te bouwen, vraag dan niet alleen: "Kan het wat ik nodig heb?" Vraag ook: "Wat gebeurt er met beveiliging als ik op 'publiceren' klik?"

Een signaal, geen eindpunt

Voor mij is dit vooral een signaal dat de markt voor AI-bouwtools volwassener wordt. De eerste golf ging over snelheid — hoe snel kun je iets bouwen? De volgende golf gaat over verantwoordelijkheid — hoe zorg je dat wat je bouwt ook veilig is?

De cijfers laten zien dat er een reëel probleem is. Eén op de drie AI-gebouwde apps met een serieus beveiligingslek is geen statistiek om te negeren. Dat Bolt hier nu een automatische stap van maakt, vind ik een verstandige zet. Maar ik zou het vooral zien als een begin — niet als een reden om achterover te leunen.