Een gids van SevenLab
Een werkend AI-prototype laat een proces zien, maar bewijst niet dat je software klaar is voor echte gebruikers en productiegegevens. Of je code nu met Claude Code, Cursor of Lovable is gemaakt, laat de beoogde inzet en risico's beoordelen. De Governed Build-pagina van SevenLab is het startpunt voor een aanvraag rond softwarebeoordeling. Spreek de beoordelingsomvang, verantwoordelijkheid voor herstel en het bewijs voor vrijgave af in het voorstel.
Bepaal wat je laat beoordelen en wat er verandert
Begin een AI-codeaudit of vibe-codingaudit met een vaste repositoryversie, uitrolconfiguratie en beschrijving van de beoogde gebruikers. Neem afhankelijkheden, databasewijzigingen, externe diensten en code buiten de gegenereerde interface mee. Vraag de beoordelaar onderscheid te maken tussen broncodeonderzoek, het uitvoeren van de applicatie en beoordeling van de uitgerolde omgeving. Een controle van geselecteerde bestanden beantwoordt niet alle vragen over de beveiliging van je volledige applicatie.
Illustratief scenario, hypothetische scope: een team wil een Lovable-app laten controleren voordat die van een interne demonstratie naar productie voor klanten gaat. De opdracht moet de echte repository, authenticatie, gegevenseigenaarschap en uitrolroute omvatten, niet alleen de zichtbare schermen. Stel als startvoorwaarden een reproduceerbare build en een overzicht van diensten en inloggegevens. Kunnen essentiële onderdelen niet worden onderzocht, laat die beperking dan in het rapport vastleggen en laat geen vrijgaveconclusies trekken die het onderzoek niet ondersteunt.
- Zet de repositoryversie vast en inventariseer diensten, afhankelijkheden en databasewijzigingen.
- Beschrijf gebruikers, gevoeligheid van gegevens en de beoogde productieomgeving.
- Eis duidelijke beoordelingsgrenzen en vermelding van ontoegankelijke onderdelen.
Vraag beveiligingsbewijs, niet alleen nette code
Een AI-codereview, een bredere AI-codeaudit en een softwarebeveiligingsaudit kunnen verschillende opdrachten zijn. Vraag bij een beveiligingsbeoordeling van Claude Code-code of een Cursor-codereview of alleen recente wijzigingen worden bekeken of ook de omliggende toegangsgrenzen. Laat autorisatie op de server, invoerverwerking, geheimen en risico's in afhankelijkheden meenemen. Automatische bevindingen moeten op relevantie worden beoordeeld. Geen meldingen krijgen is geen bewijs dat je software veilig is.
Illustratief scenario, hypothetische scope: een klantportaal verbergt gegevens van andere klanten in de interface, maar accepteert hun recordnummer in een API-verzoek. Test bij acceptatie rechtstreekse verzoeken naar gegevens van een ander account en laat aantonen dat de server toegang weigert. Voeg daarna een regressietest toe. Gebruikt de app ook een taalmodel, test dan apart of niet-vertrouwde inhoud handelingen met extra rechten kan beïnvloeden. Een overtuigende demonstratie van het scherm vervangt deze controles niet als je een AI-app wilt beveiligen.
- Vraag een beoordelingsplan voor applicatiegrenzen, niet alleen gegenereerde coderegels.
- Test onbevoegde verzoeken rechtstreeks tegen serverfuncties en gegevenstoegang.
- Eis reproduceerbare bevindingen, een eigenaar voor herstel en hertests van blokkerende fouten.
Test uitrol, gegevenswijzigingen en herstel
Een AI-prototype naar productie brengen vraagt operationeel bewijs naast codeonderzoek. Vraag om een schone uitrol, gescheiden inloggegevens voor test en productie, zichtbare foutmeldingen en gedocumenteerd herstel. Beoordeel databasemigraties, herhaalde verzoeken en uitval van externe diensten aan de hand van het echte proces. Een voorstel voor beveiliging van AI-gebouwde software moet aangeven welke controles zijn inbegrepen, waarvoor een andere specialist nodig is en wat jouw beheerresponsabiliteit blijft.
Illustratief scenario, hypothetische scope: een gegenereerde databasemigratie verandert hoe orderstatussen worden opgeslagen. Alleen de applicatiecode terugzetten herstelt mogelijk niet de eerdere gegevensstructuur of waarden. Test de migratie op een representatieve kopie buiten productie, controleer of een back-up echt terug te zetten is en leg vast wanneer je terugdraait of vooruit herstelt. Bepaal wie verwerking mag pauzeren en hoe betrokken orders worden gecontroleerd en rechtgezet. Dat is een bruikbaarder vrijgavecriterium dan alleen aantonen dat de app opstart.
- Herhaal de uitrol zonder afhankelijk te zijn van de lokale ontwikkelomgeving.
- Test migraties, onderbroken schrijfacties en uitval van externe diensten.
- Controleer back-upherstel en wijs bevoegdheid toe voor pauzeren en herstellen.
Koppel vrijgave aan het daadwerkelijk beoordeelde werk
Governance voor AI-code hoort een beoordeelde versie te verbinden met testbewijs, openstaande bevindingen en een aangewezen verantwoordelijke voor vrijgave. Vergelijk je een vibe-codingbureau of beoordelingspartner, vraag dan wie problemen oplost, wie de oplossing controleert en wanneer de eerdere beoordeling vervalt. Gebruik je Governed Build-aanvraag om die opleverpunten af te spreken. Neem niet aan dat een standaardpakket ieder risico dekt. Een beoordeling kan een vrijgavebesluit ondersteunen, maar garandeert geen veiligheid of wettelijke naleving.
Illustratief scenario, hypothetische scope: na goedkeuring genereert een team een nieuwe wijziging rond betalingen en wil die onder de eerdere goedkeuring uitrollen. Het beheerproces moet gewijzigde onderdelen aanwijzen, relevante hertests vereisen en de vrijgave opnieuw aan de bevoegde eigenaar voorleggen. Eis bij acceptatie een overdracht met de beoordeelde commit, status van bevindingen, beheerinstructies en verantwoordelijkheid voor toekomstige wijzigingen. Spreek de planning voor onderzoek en herstel af op basis van de werkelijke omvang, niet vanuit de verwachting van onmiddellijke goedkeuring.
- Koppel vrijgave aan een specifieke commit, testregistratie en status van bevindingen.
- Bepaal welke wijzigingen een nieuwe beoordeling vragen en wie uitrol mag goedkeuren.
- Vraag beheerinstructies en benoem eigenaren voor herstel en toekomstig onderhoud.