Veiligheid (NL)

De meeste mensen die apps bouwen met Coodoo zijn geen beveiligingsexpert. Daarom denkt Coodoo als een ervaren ontwikkelaar: bij elk doel, bij elke taak, en zo nu en dan voor het hele project. Je hoeft er zelf niets voor te doen.

Bij het plannen: wat vraagt zorg?

Bij het plannen schrijft de ontwikkelaar op wat de app doet dat extra zorg vraagt:

Onderdeel	Voorbeelden van waar Coodoo op let
Website of web-app	Geen kwaadaardige code via invoer (XSS), beveiligingsheaders, bescherming tegen vervalste verzoeken
Inloggen en accounts	Wachtwoorden veilig opslaan, sessies die verlopen, alleen je eigen gegevens zien, limiet op inlogpogingen
Betalen	Prijzen altijd op de server berekenen, de betaalpagina van de provider gebruiken, betalingen alleen via een gecontroleerd bericht van de provider goedkeuren
Database	Geen zoekopdrachten samenstellen uit invoer (SQL-injectie), gegevens afschermen per gebruiker
Persoonsgegevens	Alleen bewaren wat nodig is (AVG), gebruikers kunnen hun gegevens zien en wissen, niets in logboeken
Bestanden uploaden	Soort en grootte controleren, nooit uploads uitvoeren
Openbare API	Elke ingang beveiligen, limieten op verzoeken
AI-functies	Invoer van gebruikers wantrouwen (prompt injection), sleutels alleen op de server, kosten per gebruiker begrenzen
Mobiele app	Geen geheimen in de app, tokens in de beveiligde opslag van de telefoon

Hij schrijft ook de risico's op met hoe het doel ze voorkomt, en de veilige keuzes die hij maakte waar jij geen keuze over gaf. Voor elk onderdeel krijgen de ontwikkelaar en de reviewer een controlelijst mee.

Altijd, voor elk project

• Geen wachtwoorden of sleutels in de code; die komen uit omgevingsvariabelen (een .env-bestand).
• .env-bestanden gaan nooit mee in git. Coodoo vult .gitignore aan bij het begin van elk doel als dat nodig is, en laat een voorbeeldbestand .env.example met lege waarden wel toe.
• Bekende, onderhouden bibliotheken voor beveiliging; nooit zelf versleuteling schrijven.
• Alle invoer van buiten controleren.
• Gebruikers vriendelijke foutmeldingen tonen, geen technische details.

Coodoo's eigen scanners

Naast het oordeel van de reviewer laat Coodoo eigen controles lopen, die niet van een AI afhangen:

Scanner	Zoekt naar
Sleutels in de code	API-sleutels van onder meer AWS, Stripe, GitHub, OpenAI, Anthropic, Google en Slack, privésleutels, en wachtwoorden die vast in de code staan. Ook een .env-bestand dat in git staat
Kwetsbare onderdelen	Bekende lekken in de pakketten die je project gebruikt (npm audit en pip-audit)
Bekende foute patronen	Code die tot een lek kan leiden, met de regels van Semgrep: onveilige HTML, gevaarlijke functies, zwakke versleuteling en meer. Semgrep wordt vanzelf opgehaald
De draaiende app	Of je app .env of .git weggeeft aan wie erom vraagt, en welke beveiligingsheaders hij stuurt

De scanners kijken naar wat het doel veranderde. Bij de controle van het hele project kijken ze naar alles.

De draaiende app

Tijdens App starten en bekijken vraagt Coodoo je app om /.env, /.env.local, /.env.production en /.git/config. Geeft de app een echt bestand terug, dan is dat een kritiek probleem: iedereen zou je wachtwoorden kunnen lezen. Ontbrekende beveiligingsheaders worden als aandachtspunt aan de reviewer doorgegeven; tijdens het ontwikkelen is dat normaal, maar de echte site moet ze wel sturen.

Ernst en wat er dan gebeurt

Ernst	Betekenis	Gevolg
Kritiek	Direct misbruik mogelijk, zoals een gelekte sleutel	Moet opgelost; blokkeert mergen
Hoog	Ernstig lek	Moet opgelost; de review keurt niet goed
Middel	Moet beter	Advies aan de ontwikkelaar
Laag	Kleinigheid	Ter informatie

Een kritiek of hoog probleem wordt nooit goedgekeurd, ook niet als de reviewer dat zou willen. De ontwikkelaar lost het op en de review volgt opnieuw.

Staat er bij het mergen nog een kritiek probleem open, dan waarschuwt Coodoo. Je kunt pas verder als je bewust aanvinkt: Ik begrijp het risico en wil het toch mergen.

Het hele project controleren

Een ervaren ontwikkelaar kijkt niet alleen naar het nieuwste werk, maar zo nu en dan naar alles. Coodoo zet daarvoor periodiek een doel Veiligheidscontrole van het hele project vooraan in de wachtrij. Het team loopt dan alle code na met de controlelijst, de scanners kijken naar het hele project, kritieke en hoge problemen worden opgelost en kleinere punten opgeschreven.

• Hoe vaak, stel je in bij Autopilot-instellingen → Hele project controleren: Elke dag, Elke week (standaard), Elke maand of Alleen als ik erom vraag.
• Er komt alleen een controle als er sinds de vorige iets veranderd is.
• Zelf starten: klik op het dashboard bij Veiligheid van je app op Nu controleren.

Het overzicht: Veiligheid van je app

Op het dashboard staat de kaart Veiligheid van je app met:

• de open problemen per ernst, met bij elk het doel waarin het gevonden is (houd je muis erop voor de technische uitleg);
• wat je app doet dat zorg vraagt (inloggen, betalen…);
• wanneer het hele project voor het laatst is gecontroleerd, en hoe vaak dat gebeurt.

Na een controle van het hele project tellen de problemen van eerdere doelen niet meer mee: die controle keek naar alles.

Dependabot: lekken in onderdelen

GitHub houdt met Dependabot bij of de pakketten in je project bekende lekken hebben. Coodoo leest die meldingen.

• De kaart Beveiliging op het dashboard toont de open meldingen, met de versie waarin het lek is opgelost (Opgelost in …) of Nog geen patch beschikbaar.
• Staan er kritieke of hoge meldingen open, dan verschijnt bovenaan een rode balk Eerst oplossen met de knop Nu oplossen.
• Met Beveiliging eerst aan (standaard) zet Coodoo zelf een doel om ze op te lossen vooraan in de wachtrij.
• Onder de meldingen staat … meldingen oplossen. Daarmee pak je alle open meldingen in één keer aan, ook die van gemiddeld en laag niveau. Coodoo zet één doel met voorrang in de wachtrij, met de kritieke meldingen eerst. De autopilot werkt de packages bij en controleert dat build en tests slagen.
• GitHub sluit een melding pas een tijd nadat de fix op de standaardbranch (meestal main) staat, soms pas na een paar uur. Coodoo kijkt daarom zelf welke versies GitHub op die branch ziet. Valt een package niet meer in het kwetsbare bereik, dan staat er Opgelost, wacht op GitHub. Zo'n melding telt niet meer mee en krijgt geen nieuw doel.
• Heeft je project een flow, dan staat een fix eerst op de eerste branch, bijvoorbeeld development. Coodoo toont dan Opgelost op development, met Naar de Flow. Pas na Promote naar main sluit GitHub de melding.
• Staat Dependabot uit voor je repository, dan zie je Aanzetten op GitHub.

Zie ook

• Failsafes: wat de agents nooit mogen, wat er ook gebeurt.
• Projectkluis: sleutels veilig bewaren.