Een SaaS-product bouwen met AI-codingtools gaat over meer dan werkende functies. Voordat u betalende klanten accepteert, controleert u hoe de applicatie klantgegevens scheidt, rechten afdwingt, betalingen verwerkt en kritieke handelingen beschermt.
Deze SaaS security checklist behandelt zeven gebieden om te controleren, de problemen die een lancering kunnen blokkeren, het bewijs dat zakelijke klanten kunnen vragen en wanneer een onafhankelijke technische review helpt. De checklist gaat over de risico’s van het zelf exploiteren van een AI-gebouwd SaaS-product, niet over het beoordelen van SaaS-leveranciers als koper.
TL;DR
Een AI-gebouwde SaaS security review controleert of een product dat grotendeels met AI-codingtools is gebouwd klantgegevens scheidt, rechten op de server afdwingt, betalingen veilig verwerkt en kritieke handelingen beschermt voordat betalende klanten komen.
- De SaaS security checklist met zeven gebieden dekt inloggen en herstel, tenantisolatie, secrets en omgevingen, betalingen en invoer, AI-functies (als het product die heeft), logging en herstel, en misbruiklimieten. Niet elke maatregel geldt voor elk product.
- Een bevinding blokkeert de lancering als die een onaanvaardbaar risico vormt voor klantgegevens, accountbeveiliging, de integriteit van betalingen of kritieke processen, bijvoorbeeld als één tenant bij de gegevens van een andere tenant kan of als een server-credential in browsercode staat.
- Zakelijke klanten in de EU kunnen bewijs vragen, zoals een verwerkersovereenkomst als u voor hen persoonsgegevens verwerkt (artikel 28 AVG), een lijst met subverwerkers, waar gegevens staan en hoe u incidenten afhandelt.
- Een onafhankelijke review helpt vóór het eerste zakelijke contract waarin persoonsgegevens meegaan, omdat tenantisolatie, rollen en betaalde rechten afhangen van bedrijfsregels die geautomatiseerde tools niet altijd begrijpen.
Wat verandert er als u SaaS met AI bouwt en klanten gaan betalen?
Als u SaaS met AI bouwt, kan het product in de demo werken lang voordat het klaar is voor veel klanten tegelijk. Een AI-gebouwd SaaS-product is grotendeels gebouwd met AI-codingtools; het bevat niet per se AI-functies zoals chat, samenvattingen of agents. Gebied 5 van de checklist geldt alleen als dat wel zo is.
Met de eerste betalende klant veranderen drie dingen. Meerdere klanten gebruiken nu één systeem: in een multi-tenant product delen klantorganisaties (tenants) dezelfde applicatie, en in het gangbare model met een gedeelde database ook dezelfde tabellen. Eén ontbrekend filter kan dan records van andere tenants blootstellen. Er gaat geld door het product, dus abonnementen, credits en betaalevents worden doelwit. En er komen contracten waarin om bewijs wordt gevraagd.
Functies die met AI-codingtools zijn gegenereerd, moeten nog worden gecontroleerd: zijn er autorisatieregels, rate limits en tests omheen gebouwd? Een nieuwe route kan werken voor degene die de prompt schreef, zonder dat een tweede klant hem ooit heeft geprobeerd. Dat gat hoort bij het eerste risico in de OWASP API Security Top 10 (2023): broken object level authorization (API1).
Als één betalende klant zou vertrekken na het zien van gegevens van een andere klant, is tenantisolatie het eerste wat u controleert.
Staat uw eerste factuur klaar? Een AI-built product review controleert rechten, toegang tussen gebruikers, blootgestelde secrets en databaseregels samen met de code eromheen, en legt in begrijpelijke taal uit wat u eerst oplost.
Wat moet u eerst beschermen?
Een SaaS security review begint bij wat u moet beschermen, niet bij een tool. Vijf groepen assets zijn een goed startpunt:
- Klantgegevens: records, bestanden, exports, berichten en bijlagen bij supportvragen.
- Identiteit: wachtwoorden, sessies, resetlinks, API-keys en instellingen voor single sign-on.
- Geld: abonnementen, credits, facturen, terugbetalingen, kortingscodes en rechten.
- Operatie: productiedatabase, cloudconsole, CI/CD-pipeline, DNS, e-mailprovider en back-ups.
- AI-specifieke assets (als het product AI-functies heeft): keys van de modelaanbieder, prompts met klantgegevens, geüploade documenten, retrieval-indexen, rechten van agent-tools en generatiequota.
Controles horen op de vertrouwensgrenzen: waar iets van buitenaf het systeem binnenkomt. Denk aan browserinvoer, een ID in een URL, een webhook, het antwoord van een externe API of een supporttool die als gebruiker kan optreden.
Schrijf voor elke belangrijke workflow vier regels: actor, asset, misbruik en maatregel. Voor een functie “alle contacten exporteren”: de actor is een lid of een overgenomen account; de asset is klantgegevens; het misbruik is het exporteren van gegevens die alleen de eigenaar mag zien, of rekenkracht verbruiken met herhaalde exports; de maatregelen zijn een recht op organisatieniveau, opnieuw inloggen, een exportlimiet, een downloadlink die verloopt en een auditlog.
Doe dit voor uw drie belangrijkste workflows. De risico’s die u vindt, bepalen welke onderdelen van de checklist voor uw product het zwaarst wegen.
De SaaS security checklist voor AI-gebouwde producten
Deze checklist behandelt zeven gebieden die ertoe doen bij het exploiteren van een AI-gebouwd SaaS-product. Niet elke maatregel geldt voor elke architectuur of elk verdienmodel. Stel per onderdeel eerst vast of het product de betreffende functie, gegevensstroom of blootstelling heeft.
Behandel een bevinding als launch blocker als die een onaanvaardbaar risico vormt voor klantgegevens, accountbeveiliging, de integriteit van betalingen of kritieke processen. Andere maatregelen rondt u af voordat de bijbehorende functie live gaat, of u prioriteert ze op basis van de risicoanalyse van het product. Elk onderdeel heeft een van drie labels:
| Label | Betekenis |
|---|---|
| Blokkeert lancering indien van toepassing | Een bevestigde zwakte kan hier leiden tot een onaanvaardbaar risico in een kritieke workflow |
| Verplicht voordat de functie live gaat | De maatregel moet er zijn voordat de bijbehorende functie wordt aangezet |
| Prioriteren op risico | De prioriteit hangt af van de gegevens, de blootstelling en de impact op het bedrijf |
Leg per onderdeel vast wat er is gecontroleerd, welk bewijs er is, welk risico overblijft en wie de volgende actie oppakt.
1. Inloggen en accountherstel
Inlog- en herstelflows bepalen of iemand een account kan overnemen zonder uw database aan te raken. Een volwassen identity provider of authenticatiebibliotheek regelt resettokens, sessies en multifactorauthenticatie (MFA), zodat dit niet afhangt van eigen code die per prompt is geschreven.
| Controle | Wat u controleert | Van toepassing als | Label |
|---|---|---|---|
| Resetlinks | Verlopen, werken één keer en verraden niet of een e-mailadres een account heeft | U uw eigen wachtwoordreset beheert | Blokkeert lancering indien van toepassing |
| MFA voor beheerders | MFA verplicht voor beheer- en medewerkersaccounts, beschikbaar voor gebruikers | Beheeraccounts bij klantgegevens of instellingen kunnen | Prioriteren op risico (hoog als beheerders alle tenants zien) |
| Sessies intrekken | Uitloggen, een lid verwijderen of een gebruiker wissen beëindigt de toegang binnen de tijd die uw sessie- of tokenontwerp toelaat (bijvoorbeeld kortlevende tokens of een intrekkingslijst) | Gebruikers kunnen worden verwijderd of van rol wisselen | Prioriteren op risico |
| Gevoelige wijzigingen | Bij het wijzigen van e-mail, wachtwoord, betaalgegevens of API-keys moet de gebruiker opnieuw inloggen | Deze instellingen bestaan in het product | Prioriteren op risico |
| Uitnodigingen en callbacks | Verlopen uitnodigingen werken niet meer; OAuth-callbacks accepteren alleen uw eigen redirectadressen | U uitnodigingen of OAuth-login gebruikt | Verplicht voordat de functie live gaat |
De Amerikaanse Cybersecurity and Infrastructure Security Agency noemt multifactorauthenticatie in haar Secure by Design-richtlijnen als een van de standaardbeschermingen. Met verplichte MFA opent een gestolen beheerderswachtwoord alleen het account niet meer.
2. Multi-tenant isolatie en autorisatie
Multi-tenant isolatie heeft de grootste gevolgen in deze checklist als het product meerdere klantorganisaties bedient: een fout kan de gegevens van de ene klant zichtbaar maken voor een andere. Isolatie betekent dat elke keer lezen, wijzigen, exporteren en delen beperkt blijft tot wat de tenant en rol van de ingelogde gebruiker toestaan. In een product voor individuele gebruikers gelden dezelfde controles tussen gebruikersaccounts.
| Controle | Wat u controleert | Van toepassing als | Label |
|---|---|---|---|
| Autorisatietests tussen tenants | Probeer met minstens twee testtenants en meerdere rollen via de applicatie en de API resources van een andere tenant te openen, wijzigen, exporteren of delen. Elke niet-toegestane handeling wordt geweigerd en er worden geen beschermde gegevens teruggegeven of gewijzigd | Meerdere organisaties of accounts het product delen | Blokkeert lancering indien van toepassing |
| Controles op de server | Elk endpoint dwingt sessie, tenantlidmaatschap en rol af op de server; de tenant volgt uit de geauthenticeerde sessie, niet uit een waarde die de browser meestuurt | Altijd, voor endpoints die klantgegevens teruggeven of wijzigen | Blokkeert lancering indien van toepassing |
| Drie niveaus | Een gebruiker kan geen ander record bereiken door een ID te wijzigen, kan geen beschermde velden zetten zoals rol, tenant, prijs of status, en kan geen actie aanroepen die alleen voor beheerders is | Objecten, beschermde velden of beheerfuncties via een API bereikbaar zijn | Blokkeert lancering indien van toepassing |
| Matrix van rollen en abonnementen | Beheerroutes en betaalde functies getest als niet-ingelogde bezoeker, lid, beheerder en gebruiker met een verlopen abonnement | Het product rollen of betaalde abonnementen heeft | Verplicht voordat de functie live gaat |
| Verborgen gedeelde plekken | Bestandsopslag, achtergrondtaken, exports, caches en zoekindexen houden de tenantcontext vast | Deze onderdelen klantgegevens bevatten | Prioriteren op risico |
Afhankelijk van het API-ontwerp kan een niet-toegestaan verzoek 403, 404, een leeg gefilterd resultaat of een ander bewust gekozen antwoord opleveren. De test moet aantonen dat de gebruiker geen gegevens kan lezen, wijzigen of afleiden waar hij geen toegang toe heeft. Herhaal de controles voor de relevante objecttypen, handelingen en toegangspaden: geslaagde tests zijn bewijs voor de geteste scenario’s, geen bewijs dat de autorisatie volledig is.
De drie niveaus volgen de OWASP API Security Top 10 (2023): objectniveau (API1), niveau van objecteigenschappen (API3) en functieniveau (API5). OWASP beschrijft het eerste niveau als aanvallers die het ID van een object in het verzoek manipuleren. Combineer functionele tests zoals deze met een review van de code die de regels afdwingt.
Onze gids over broken access control in AI-gebouwde apps legt de oplossingen uit. AI-gebouwde applicaties testen legt uit waarom het vermogen van een testsuite om een echte fout te vangen belangrijker is dan het aantal geslaagde tests.
Eén losse test overleeft de volgende prompt niet. Vraag uw developer om de controles tussen tenants om te zetten in geautomatiseerde API-tests die vóór elke deploy draaien. Begin met deze vijf:
1. Tenant A kan geen record van tenant B lezen.
2. Tenant A kan geen record van tenant B wijzigen, verwijderen, exporteren of delen.
3. Een lid kan geen beheeractie aanroepen.
4. Een verzoek kan rol, tenant of prijs niet wijzigen.
5. Een verwijderd lid verliest de toegang binnen de tijd die uw sessieontwerp toelaat.
Geef elke test de naam van het risico, bijvoorbeeld member_cannot_export_another_workspace_invoices, zodat een fout zichzelf verklaart.
Een kwetsbaarheid in de toegangscontrole waardoor een tenant bij persoonsgegevens van een andere tenant kan, vormt een mogelijk risico onder de AVG (GDPR). Vindt er daadwerkelijk ongeautoriseerde toegang of verstrekking plaats, dan kan het incident een inbreuk in verband met persoonsgegevens zijn volgens artikel 4, punt 12, AVG. De meldplicht hangt dan af van de rol van de organisatie en de omstandigheden van het datalek. Volgens artikel 33 meldt een verwerkingsverantwoordelijke het datalek zonder onredelijke vertraging en zo mogelijk binnen 72 uur nadat hij ervan kennis heeft genomen aan de bevoegde toezichthouder, tenzij het datalek waarschijnlijk geen risico inhoudt voor de rechten en vrijheden van personen. Een verwerker meldt een datalek zonder onredelijke vertraging aan de verwerkingsverantwoordelijke zodra hij ervan op de hoogte is. In Nederland is de toezichthouder de Autoriteit Persoonsgegevens.
Twijfelt u of uw tenantisolatie standhoudt? Toegang tussen gebruikers, rechten en databaseregels vallen onder het onderdeel security en data van een AI-built product review. U krijgt bevindingen met het bewijs erachter en een geprioriteerd plan voor wat u eerst oplost.
3. Secrets, configuratie en omgevingen
Een server-credential in browsercode of in de git-geschiedenis kan de vinder toegang geven binnen de rechten van die key. Bouwen met AI voegt één specifieke route toe: credentials die tijdens de ontwikkeling in prompts, chats en testbestanden zijn geplakt.
| Controle | Wat u controleert | Van toepassing als | Label |
|---|---|---|---|
| Geen server-credentials in de browser | Gebouwde JavaScript en netwerkverzoeken bevatten geen private API-keys, database-URL’s of geheime tokens | Altijd | Blokkeert lancering indien van toepassing |
| Blootgestelde credentials beoordelen en vervangen | Breng in kaart welke credentials tijdens de ontwikkeling zijn gebruikt en of ze zijn gecommit, in prompts of chatlogs stonden, in client-side code zaten of via niet-goedgekeurde kanalen zijn gedeeld. Trek credentials in en vervang ze als ze bekend of redelijkerwijs vermoedelijk zijn blootgesteld | Er tijdens het bouwen met AI credentials zijn gebruikt | Blokkeert lancering indien van toepassing (voor blootgestelde credentials) |
| Afgebakende productie-credentials | Productie gebruikt aparte credentials met passende rechten; verouderde ontwikkeltoegang is verwijderd | Vóór de lancering | Verplicht voordat de functie live gaat |
| Geschiedenis scannen | Een secret scanner (bijvoorbeeld git-secrets of TruffleHog) scant de git-geschiedenis en CI-logs, niet alleen de huidige code | De repository credentials bevat of bevatte | Prioriteren op risico |
| Restanten van de bouw opruimen | Debug-endpoints, uitgebreide foutmeldingen, open CORS-regels, publieke opslagbuckets, preview-deployments en oude subdomeinen zijn afgesloten; publieke source maps zijn nagekeken op secrets en gevoelige implementatiedetails | Deze onderdelen in de deployment bestaan | Prioriteren op risico |
| Gescheiden omgevingen | Ontwikkeling, staging en productie gebruiken verschillende credentials; staging bevat geen ongemaskeerde productiegegevens | U een stagingomgeving gebruikt | Prioriteren op risico |
Een key die uit de code is verwijderd, kan nog in een eerdere commit staan. Daarom heeft de scan van de geschiedenis zin, ook als de huidige code schoon lijkt. Onze gids over gelekte API-keys in AI-producten behandelt vervangen en scannen.
4. Betalingen, webhooks, invoer en API
Zwakke plekken in betalingen en webhooks kunnen een gebruiker een betaald abonnement, een terugbetaling of credits opleveren zonder te betalen. De regel voor dit gebied: vertrouw niets van buitenaf voordat het is geverifieerd.
| Controle | Wat u controleert | Van toepassing als | Label |
|---|---|---|---|
| Gehoste betaalvelden | Kaartgegevens gaan naar de gehoste checkout of getokeniseerde velden van de betaalprovider, niet via uw servers | U kaartbetalingen accepteert | Verplicht voordat de functie live gaat |
| Geverifieerde webhooks | Handtekeningen worden geverifieerd; events worden gecontroleerd op replay en herkend aan hun event-ID; waar de integratie het toelaat, worden rechten op de server bij de betaalprovider bevestigd voordat een abonnement, credit of terugbetaling verandert | Webhooks abonnementen, credits of terugbetalingen wijzigen | Verplicht voordat de functie live gaat |
| Bestand tegen dubbele events | De verwerking van events is idempotent: een herhaald event geeft niet twee keer een abonnement of terugbetaling | U betaalevents ontvangt | Verplicht voordat de functie live gaat |
| Beperkte API-antwoorden | Antwoorden bevatten alleen de velden die het scherm nodig heeft: geen wachtwoordhashes, credentials of gegevens van andere tenants | Altijd | Blokkeert lancering indien van toepassing (als ze credentials of gegevens van andere tenants tonen) |
| Invoervalidatie | De server controleert type, lengte, formaat, paginagrootte en het type en de omvang van uploads; queries zijn geparametriseerd | Altijd | Prioriteren op risico |
| Onbetrouwbare integraties | URL-imports, bestandsconverters en antwoorden van externe API’s kunnen geen interne adressen bereiken | U URL’s importeert of geüploade bestanden verwerkt | Verplicht voordat de functie live gaat |
De integration security guide van Stripe stelt dat betaalgegevens die rechtstreeks naar Stripe gaan, zonder via uw servers te lopen, uw verplichtingen onder PCI DSS (de beveiligingsstandaard van de kaartindustrie) verkleinen. De webhookdocumentatie van Stripe zegt dat u events verifieert voordat u erop handelt, en waarschuwt dat een endpoint hetzelfde event meer dan eens kan ontvangen. De laatste rij gaat over server-side request forgery (SSRF), waarbij uw server wordt misleid om een intern adres aan te roepen (OWASP API7:2023). Ons artikel over authenticatie en betalingen in AI-gebouwde SaaS gaat dieper in op dit gebied.
5. Maatregelen voor AI-functies
Maatregelen voor AI-functies gelden alleen als het SaaS-product AI-functies heeft, zoals chat, samenvattingen of agents; een product dat met AI-codingtools is gebouwd, heeft die misschien niet. Deze maatregelen begrenzen wat het model namens een gebruiker kan zien en doen.
| Controle | Wat u controleert | Van toepassing als | Label |
|---|---|---|---|
| Gegevensbereik | De AI-functie leest alleen gegevens die de huidige gebruiker mag zien; nooit met beheerdersrechten op de database of systeemlogins | De functie klantgegevens leest | Verplicht voordat de functie live gaat |
| Rol en voorwaarden van de aanbieder | De rol van de modelaanbieder is beoordeeld (bijvoorbeeld verwerker of subverwerker) en de voorwaarden voor bewaren en trainen zijn schriftelijk bevestigd; verwerkt de aanbieder namens u persoonsgegevens, dan staat hij op uw lijst met subverwerkers | Persoonsgegevens bij een modelaanbieder komen | Verplicht voordat de functie live gaat |
| Dataminimalisatie | Alleen de persoonsgegevens die de toepassing nodig heeft gaan naar het model, met een rechtmatige grondslag en contractuele waarborgen | Prompts persoonsgegevens kunnen bevatten | Verplicht voordat de functie live gaat |
| Waarborgen voor ingrijpende acties | Bevestiging, limieten of menselijke goedkeuring voor acties zoals massamails, terugbetalingen of verwijderingen, naar gelang het risico | Een AI-functie deze acties kan starten | Prioriteren op risico |
| Tests op prompt injection | Eenvoudige tests met verborgen of misleidende instructies in gebruikersinhoud | Het model inhoud van gebruikers leest | Prioriteren op risico |
| Generatiequota | Limieten per gebruiker of abonnement, zodat één account de modelkosten niet kan opdrijven | U per generatie betaalt | Prioriteren op risico |
Prompt injection komt aan bod in het onderdeel over de OWASP Top 10 voor LLM-toepassingen in onze gids over beveiligingsstandaarden. Agents die zelfstandig handelen, hebben strengere grenzen nodig; dat behandelen we in AI agent security voor teams die hun eerste agent lanceren.
6. Dependencies, logging, back-ups en herstel
Logging en herstel bepalen hoe snel u een probleem opmerkt en of u het kunt terugdraaien.
| Controle | Wat u controleert | Van toepassing als | Label |
|---|---|---|---|
| MFA op infrastructuur | Accounts voor coderepository, cloudconsole, databaseplatform en e-mailprovider gebruiken MFA | Deze accounts productie kunnen wijzigen | Prioriteren op risico (hoog bij toegang tot productie) |
| Schone logs | Logs bevatten geen wachtwoorden, volledige tokens, ruwe request bodies of onnodige persoonsgegevens; toegang tot logs is beperkt | Altijd | Prioriteren op risico |
| Geteste restore | Eén back-up is teruggezet in een aparte omgeving; back-ups zijn beschermd zoals productie | U voor herstel op back-ups vertrouwt | Prioriteren op risico |
| Auditevents | Inloggen en mislukte pogingen, wijzigingen in MFA en rollen, wachtwoordresets, aangemaakte API-keys, exports, betaalwijzigingen en verwijderingen worden gelogd met wie, welke tenant en wat er veranderde | Deze acties in het product bestaan | Prioriteren op risico |
| Dependencies en CI | Kwetsbare packages bijgewerkt, te beginnen bij code die het product gebruikt; deploy-keys en CI-workflows hebben alleen de rechten die ze nodig hebben | Altijd | Prioriteren op risico |
| Levenscyclus van gegevens | Een vastgelegd proces verwijdert of anonimiseert de gegevens van een klant op verzoek of aan het einde van het contract, met uitzonderingen voor gegevens die u moet bewaren, zoals factuurgegevens onder wettelijke bewaarplichten | U persoonsgegevens van klanten opslaat | Verplicht voordat de functie live gaat |
Wat u na de go-live monitort, staat in onze go-live checklist voor AI-apps.
7. Misbruiklimieten en kostbare acties
Een betalende gebruiker met geldige rechten kan u nog steeds geld kosten: massamails, bulkexports, AI-generatie en terugbetalingen zijn kostbaar, ook als elke rechtencontrole slaagt. Misbruiklimieten bepalen hoeveel één account kan doen.
| Actieniveau | Voorbeelden | Mogelijke maatregelen |
|---|---|---|
| Laag | Bladeren, zoeken, concepten maken | Normale limieten |
| Gemiddeld | Een collega uitnodigen, publiceren, beperkte API-aanroepen | Rate limits per account |
| Hoog | Gegevens exporteren, inloginstellingen wijzigen, API-keys vervangen, betaalgegevens wijzigen, een integratie toevoegen, een campagne versturen | Opnieuw inloggen, bevestigingsscherm, auditlog |
| Moeilijk terug te draaien | Verwijderen, terugbetalen, uitbetalen, massaal versturen, eigendom overdragen, beheerdersrechten geven | Bevestiging, limieten, verwerking die bestand is tegen dubbele events en, als het risico dat rechtvaardigt, goedkeuring door een mens of een tweede persoon (ook als een AI-agent de actie start) |
Stel limieten in voordat kostbaar werk in de wachtrij komt: per account, tenant, abonnement en API-key in plaats van alleen per IP-adres, met quota per abonnement voor AI-generatie, exports en e-mail, lagere limieten voor nieuwe accounts en meldingen bij pieken in gebruik en modelkosten. OWASP noemt dit risico unrestricted resource consumption (API4:2023). Uw developer bouwt de limiet; de founder bepaalt per abonnement wat normaal gebruik en aanvaardbaar verlies is. Of het product een drukke dag overleeft, is een andere vraag; die behandelen we in load testing voor AI-gebouwde apps.
Wat vraagt uw eerste zakelijke klant u aan te tonen?
Uw eerste zakelijke klant kan om bewijs vragen in plaats van geruststelling. Zodra u SaaS aan andere bedrijven verkoopt, bent u de leverancier wiens beveiliging zij beoordelen. Verzoeken kunnen bestaan uit:
- Een ingevulde security-vragenlijst.
- Een verwerkersovereenkomst als u namens uw klant persoonsgegevens verwerkt. Artikel 28 AVG bepaalt de contractvoorwaarden voor die verwerkersrelatie; of het artikel van toepassing is, hangt af van de feitelijke rollen bij de verwerking.
- Een lijst met subverwerkers: bijvoorbeeld hosting, databaseplatform, e-mailprovider en, als die namens u persoonsgegevens verwerkt, de aanbieder van het AI-model.
- Waar klantgegevens zijn opgeslagen en of ze de EU verlaten.
- Versleuteling tijdens transport en in opslag.
- Hoe u incidenten detecteert, afhandelt en meldt.
- Hoe klantgegevens worden verwijderd of teruggegeven als het contract eindigt.
Klanten die onder de NIS2-richtlijn vallen, moeten in hun eigen beheer van cybersecurityrisico’s aandacht geven aan de beveiliging van de toeleveringsketen (artikel 21). Ze kunnen softwareleveranciers daarom in hun due diligence om beveiligingsinformatie vragen. Zo’n verzoek maakt uw bedrijf niet automatisch onderworpen aan artikel 21 van NIS2; of NIS2 rechtstreeks op u van toepassing is, hangt af van uw sector en omvang.
Voor een eerste vragenlijst hebt u geen certificering nodig, wel schriftelijke antwoorden met bewijs. Eist een klant ISO/IEC 27001 of SOC 2, plan dat dan als apart project en bereid de antwoorden op de vragenlijst voor vóór het salesgesprek.
Hoe past dit bij de readiness- en go-live-checklist?
Deze checklist behandelt wat alleen een SaaS toevoegt: tenants, abonnementen, facturatie en zakelijke klanten. Voor controles die voor elk AI-gebouwd product gelden, inclusief persoonsgegevens onder artikel 25 AVG, gebruikt u de production readiness checklist; voor de releasedag en rollback gebruikt u de go-live checklist voor AI-apps.
Zelfcheck, geautomatiseerde tools of een onafhankelijke review?
Een zelfcheck, geautomatiseerde securitytools en een onafhankelijke review dekken verschillende dingen af. Een schone scan is op zichzelf geen bewijs dat het product veilig is.
Geautomatiseerde securitytools kunnen kwetsbare dependencies, blootgestelde secrets, configuratieproblemen en sommige autorisatiezwaktes vinden. Hoeveel ze afdekken, hangt af van de tools, de authenticatie-instellingen, de testgevallen en de context van de applicatie.
Tenantisolatie, rollen en betaalde rechten hangen ook af van bedrijfsregels die een geautomatiseerde tool niet altijd begrijpt. Combineer passende geautomatiseerde controles met gerichte autorisatietests en een menselijke review van kritieke workflows, in plaats van een schone scan te zien als bewijs dat het product veilig is.
| Optie | Wat het afdekt | Waar de dekking van context afhangt | Wanneer te gebruiken |
|---|---|---|---|
| Zelfcheck met deze lijst | Ontbrekende basis: blootgestelde credentials, ongeverifieerde webhooks, geen tests tussen tenants | Beperkt tot wat het team weet te zoeken | Altijd, als eerste stap |
| Geautomatiseerde tools (scanners voor dependencies, secrets, statische en dynamische analyse) | Kwetsbare dependencies, blootgestelde secrets, configuratieproblemen en sommige autorisatiezwaktes | Bedrijfsregels, rollen en rechten waarvoor de tool geen testgeval of accountinstelling heeft | In uw CI-pipeline en vóór releases |
| Onafhankelijke review | Code, gegevenstoegang en deployment beoordeeld aan de hand van de bedrijfsregels van het product, met bewijs en een volgorde van oplossen | Wijzigingen na de review | Vóór het eerste zakelijke contract met persoonsgegevens, vóór een security-vragenlijst van een enterprise-klant, na een grote herbouw via prompts |
Onze gids over de AI code audit legt uit wat een onafhankelijke review omvat en hoe die verloopt.
AI-securityagents inzetten zonder ze blind te vertrouwen
AI-securityagents helpen routes op te sommen, tests op te stellen en aan te wijzen waar u moet kijken, maar een mens reproduceert elke bevinding en beoordeelt de impact op het bedrijf. Geef de agent een smalle opdracht: een testomgeving met synthetische gegevens en zonder productie-credentials, twee tenants en meerdere rollen, de lijst met routes, wat hij niet mag doen, de rechtenregels die u verwacht en het bewijs dat u per bevinding wilt. Stel daarna specifieke vragen in plaats van “is dit veilig?”:
1. Kan een gebruiker van een tweede tenant bij elk endpoint dat een object-ID accepteert dat object lezen of wijzigen?
2. Welke endpoints wijzigen facturatie, rollen, API-keys, exports, integraties of bewaarinstellingen?
3. Kunnen velden in een verzoek rol, tenant, prijs, status of goedkeuring overschrijven?
4. Kan een webhook, URL-import of documentparser interne adressen bereiken?
5. Welke endpoints die kostbaar werk starten, hebben geen rate limit?
6. Welke acties hebben geen auditevent of bescherming tegen dubbele verwerking?
Welke bevindingen blokkeren de lancering?
Een bevestigde bevinding blokkeert de lancering als die een onaanvaardbaar risico vormt voor klantgegevens, accountbeveiliging, de integriteit van betalingen of kritieke processen. Voorbeelden zijn bevestigde toegang tussen tenants tot klantgegevens, accountovername via een fout in reset of sessies, het verkrijgen van beheerdersrechten, manipulatie van betalingen of rechten, blootgestelde productie-credentials en endpoints die beheerhandelingen uitvoeren zonder authenticatie.
| Bevinding | Wie kan erbij | Wat staat op het spel | Besluit | Eigenaar en datum |
|---|---|---|---|---|
| Voorbeeld: exportendpoint accepteert het ID van een andere tenant | Elke ingelogde gebruiker | Klantgegevens | Oplossen vóór de lancering | Lead developer, vóór de lancering |
Elke bevinding krijgt een van drie besluiten: nu oplossen, volgens planning oplossen, of accepteren tot een vastgelegde datum met een reden. “Daar komen we later op terug” is geen besluit. Een AI code audit-rapport dat elke bevinding vastlegt met bewijs, ernst, eigenaar en oplossing geeft u dat besluitspoor.
Wanneer is uw SaaS voldoende afgedekt voor de eerste betalende klant?
Geen certificering of audit garandeert dat een product geen kwetsbaarheden heeft. “Redelijk afgedekt” betekent dat u voor de workflows die voor uw product tellen zes dingen kunt laten zien:
1. U weet welke gegevens en workflows het meest waard zijn.
2. Rechten en tenantisolatie zijn voor die workflows getest via de echte API.
3. Ingrijpende acties hebben limieten, waar nodig goedkeuring, logs en een herstelroute.
4. Secrets, dependencies en omgevingen hebben elk een eigenaar en een terugkerende controle.
5. Elke opgeloste bevinding heeft een test of waarborg achtergelaten, niet alleen een patch.
6. Afwijkend gedrag leidt tot een melding, en iemand heeft de reactie geoefend.
Om dit na de lancering zo te houden, schrijft u een korte misbruiknotitie voordat u exports, delen, facturatie, beheertools, uploads of AI-functies bouwt, en laat u de tenanttests in CI draaien. Als het product groeit, geeft OWASP ASVS 5.0 beveiligingseisen om naartoe te groeien, en beschrijft NIST SP 800-218 (het Secure Software Development Framework) hoe u deze werkwijzen in de delivery inbouwt.
Kunt u punt 1 tot en met 3 niet laten zien voor de workflows met klantgegevens, betalingen of beheertoegang, leg dat dan vast als open risico: los het op, of accepteer het expliciet met een eigenaar en een datum, voordat u een zakelijke klant laat betalen.
Hoe Sunbytes AI-gebouwde SaaS-producten reviewt
Tenantisolatie laat zien waarom een SaaS-review engineering en security in dezelfde ronde nodig heeft: de fout zit in de bedrijfslogica, maar het gevolg kan een datalek zijn. De AI-built product review van Sunbytes omvat vijf gebieden: security en data, code en architectuur, betrouwbaarheid en kritieke flows, deployment en operatie, en onderhoudbaarheid en eigenaarschap van de code. Het gebied security en data omvat authenticatie, rechten, toegang tussen gebruikers, blootgestelde secrets en databaseregels, en sluit daarmee aan op gebied 1 tot en met 3 van deze checklist.
U krijgt bevindingen met het bewijs erachter, een geprioriteerd actieplan voor wat u nu oplost en wat kan wachten, en een technische overdracht waarmee uw team of uw AI-codingtool aan de slag kan. Toegang en informatieverwerking vallen onder het ISO 27001-gecertificeerde managementsysteem voor informatiebeveiliging van Sunbytes, met klantgovernance vanuit Nederland en engineering in Vietnam. Daarachter staan 15+ jaar ervaring in softwaredelivery en meer dan 300 opgeleverde projecten.
Tekent u binnenkort uw eerste zakelijke klant? Bespreek met ons een review van uw SaaS-product. De scope hangt af van uw stack, gegevens en integraties; daarom adviseren we per situatie.
