Platform
Security-tests voor serieuze AI-softwarelevering
Elke bevinding wordt bevestigd tegen de draaiende applicatie voordat hij jou bereikt — zodat het dashboard echt risico toont, geen scannerruis.
Ciao Security is de applicatiebeveiligingslaag van het platform: statische scans, dependency-checks en toegangscontrole-probes, met kwetsbaarheden bevestigd tegen de live app voordat ze worden gemarkeerd. In tegenstelling tot ruwe scanneroutput die teams begraaft in false positives, verifieert Ciao elke bevinding tegen de draaiende applicatie en rolt het resultaat op in een safe-to-publish dashboard — zodat teams leveren wanneer de app aantoonbaar veilig is.
Gepubliceerd 2026-07-03 · Laatst bijgewerkt 2026-07-03
Bevindingen waarop je kunt handelen, geen scannerruis
Applicatiebeveiligingstooling heeft een eerlijkheidsprobleem: scanners produceren honderden bevindingen, waarvan de meeste er niet toe doen, en teams leren het rapport te negeren. Ondertussen verhoogt AI-assisted development de inzet — meer wijzigingen, meer oppervlak, meer kansen dat een toegangsregel stilletjes verzwakt.
Ciao Security sluit een ander contract met je aandacht: statische scans, dependency-checks en toegangscontrole-probes draaien continu, en elke kandidaat-kwetsbaarheid wordt bevestigd tegen de live applicatie voordat hij wordt gemarkeerd. Wat het dashboard bereikt is echt.
Deze pagina behandelt de security-tests die in elk Ciao-project zijn ingebouwd. Voor de eigen positie van Ciao als leverancier — SOC 2 Type II, SSO, gegevensverwerking, zero-retention modelcontracten — zie het security- en compliance-overzicht.
Hoe Security werkt
Security-tests draaien continu binnen de delivery-loop, niet als een kwartaalgebeurtenis.
1. Statische scans bij elke wijziging
Code wordt geanalyseerd terwijl hij wordt geschreven — onveilige patronen, injectierisico's en gevaarlijke constructies worden opgevangen bij de wijziging, niet bij de jaarlijkse audit.
2. Dependency-checks
Third-party packages worden gecontroleerd op bekende kwetsbaarheden, zodat de risicovolste code in de meeste applicaties — de code die niemand in het team schreef — ook wordt bekeken.
3. Toegangscontrole-probes
Probes proberen wat een aanvaller zou proberen: gegevens lezen over tenant-grenzen heen, admin-endpoints aanroepen als gewone gebruiker, routes bereiken die authenticatie zouden moeten vereisen.
4. Live bevestiging vóór markering
Kandidaat-issues worden bevestigd tegen de draaiende applicatie voordat ze worden gemarkeerd, wat aantoonbaar risico scheidt van theoretische ruis.
5. Het safe-to-publish dashboard
Eén weergave beantwoordt de releasevraag: is deze applicatie nu veilig om te publiceren? Groen weerspiegelt bevestigd bewijs, niet de afwezigheid van een scan.
6. Fixes stromen terug door de loop
Bevestigde bevindingen komen met opgestelde fixes die uitgaan zoals elke wijziging uitgaat — via Builder, Guardrails-review waar beleid dat vereist, en QA-gates.
Waarom dit ertoe doet
Een bevinding bevestigd tegen de live app verandert het gesprek. Het is niet 'de scanner zegt dat dit patroon risicovol kan zijn' — het is 'dit verzoek, tegen je draaiende applicatie, gaf data terug die het niet had moeten teruggeven.' Teams fixen die.
En omdat de checks binnen de delivery-loop draaien, houdt security gelijke tred met ontwikkeling in plaats van maanden later te auditen. Het safe-to-publish dashboard maakt de releasebeslissing expliciet: groen is bewijs, geen optimisme.
Live bevestiging verandert ook wie op security kan handelen. Een geverifieerde bevinding met bijgevoegd bewijs heeft geen security-engineer nodig om hem te interpreteren — de persoon die het project runt kan zien wat er gebeurde en de opgestelde fix door review sturen. Expertise blijft belangrijk; het stopt alleen het knelpunt te zijn voor elke fix.
Wie gebruikt het
Het safe-to-publish dashboard betekent verschillende dingen voor verschillende lezers.
- Teams zonder security-functie — De meeste teams die interne tools en portals bouwen hebben geen AppSec-engineer. Ze krijgen toch continue tests, met al geverifieerde bevindingen.
- Engineering-leiders die verkopen aan gereguleerde kopers — Security-vragenlijsten worden beantwoord met bewijs van het draaiende product, geen ambities uit een beleidsdocument.
- Bureaus — Elke klantapplicatie wordt getest op dezelfde lat, en 'is het veilig?' heeft een dashboard achter het antwoord.
- Security-teams — AI-gebouwde applicaties zijn vaak een blinde vlek. Ciao houdt ze aan een continue, live-geverifieerde standaard die het team kan inspecteren.
Security- en governance-notities
- ✓ Statische scans, dependency-checks en toegangscontrole-probes draaien op elk project.
- ✓ Kwetsbaarheden worden bevestigd tegen de live applicatie voordat ze worden gemarkeerd.
- ✓ Safe-to-publish-status is zichtbaar per project en over de fleet in Conductor.
- ✓ Bevindingen en hun fixes worden vastgelegd in de append-only audit trail.
- ✓ Row-level security in de Supabase-backend wordt uitgeoefend door toegangscontrole-probes.
- ✓ Probes draaien opnieuw na wijzigingen aan authenticatie en rechten, zodat regressies vroeg naar boven komen.
- ✓ Leverancierszijdige compliance — SOC 2 Type II-rapporten onder NDA, SSO, zero-retention-contracten — wordt behandeld op de security-overzichtspagina.
Ruwe scanneroutput vs live-bevestigde bevindingen
Het verschil is wat je zonder triage kunt vertrouwen.
| Typisch scannerrapport | Ciao Security | |
|---|---|---|
| Volume | Honderden bevindingen per run | Bevindingen bevestigd tegen de live app |
| False positives | Aan jou om te trieren | Onbevestigde kandidaten gaten een release niet |
| Toegangscontrole | Patroon-gematcht in code | Getest tegen de draaiende applicatie |
| Releasebeslissing | Een oordeel uit een PDF | Het safe-to-publish dashboard |
| Fixpad | Een ticket naar een backlog | Een opgestelde fix door review en QA-gates |
Veelgestelde vragen
Hoe verschilt dit van de /security-pagina?
Die pagina behandelt Ciao als leverancier — SOC 2 Type II-rapporten onder NDA, SSO via SAML en OIDC, de audit trail, zero-retention modelcontracten. Deze pagina behandelt wat het platform met je applicaties doet: scannen, testen en kwetsbaarheden bevestigen zodat elke release aantoonbaar veilig is om te publiceren.
Wat houdt live-bevestigd precies in?
Kandidaat-bevindingen worden uitgeoefend tegen de draaiende applicatie. Een cross-tenant-leespoging geeft data terug of niet; een niet-geauthenticeerd verzoek bereikt de route of niet. Bevestiging maakt van een patroon een feit voordat iemand wordt gevraagd erop te handelen.
Vervangt dit een penetratietest?
Dat claimt het niet. Continue, live-bevestigde tests verhogen de dagelijkse lat en vangen regressies tussen formele opdrachten op. Teams met contractuele of regelgevende vereisten geven doorgaans nog steeds periodieke penetratietests op — de twee vullen elkaar aan.
Wat gebeurt er als een echte kwetsbaarheid wordt bevestigd?
Hij verschijnt op het dashboard met het bewijs dat hem bevestigde, samen met een opgestelde fix. De fix gaat uit via de normale loop — Guardrails-review waar beleid dat vereist, QA-gates vóór publicatie — en de trail legt de bevinding en zijn oplossing samen vast.
Ons security-team wil dit evalueren — waar beginnen ze?
Boek een demo en breng je vragenlijst mee. SOC 2 Type II-rapporten zijn beschikbaar onder NDA via het compliance-traject, en serieuze productieprogramma's beginnen bij 10.000 USD per jaar.