Audit vibe-coded aplikací: co hledat, než to přečte due diligence.

Vibe-coding je termín, kterým se v komunitě označuje vývoj, kde zakladatel nebo non-tech tým generuje kód přes AI nástroj a iteruje ho na pocit — bez review, bez testů, bez bezpečnostního pohledu. Výsledek bývá překvapivě funkční na první klik a překvapivě zranitelný na druhý.

Pro early-stage prototyp je to legitimní cesta. Problém začíná v okamžiku, kdy se aplikace dostane do produkce a začne sbírat reálná uživatelská data — emaily, platby, zdravotní údaje, polohu. V tu chvíli platí GDPR stejně jako pro každého jiného. A když přijde investor s due diligence dotazníkem, otázky typu „kde máte audit trail" nebo „jak řešíte rate-limiting" obvykle zodpovědět nedokážete.

U projektu, který jsme přebírali na podzim 2024 — český B2C SaaS startup ze segmentu fitness/wellness, 8 zaměstnanců — investor Series A vyžadoval nezávislý audit jako podmínku investice. Aplikace byla postavená v Next.js, Supabase a TypeScriptu, generovaná převážně přes Cursor a Lovable. Vypadala hotově. Audit trval 4 týdny a vrátil 14 medium a 3 high zranitelnosti.

V naší praxi se na auditech vibe-coded aplikací opakuje pět vzorů. Pořadí přibližně odpovídá frekvenci výskytu.

SQL injection v API endpointech. AI generátory rády skládají dotazy přes string interpolation, pokud nedostanou explicitní prompt na parametrizaci. U zmíněného fitness SaaS jsme našli SQL injection ve dvou endpointech — oba šly přes raw query do Supabase, oba přijímaly user input bez sanitizace. Z pohledu útočníka šlo o přímý přístup k tabulce uživatelů.

Hardcoded secrets a exposed env vars. API klíče k OpenAI, Stripe, SendGrid v public repository nebo v build outputu Next.js. V jednom případě jsme našli čtyři klíče v .next/server/ kompilátu, které se z public assets daly stáhnout přes prohlížeč.

Chybějící rate-limiting. AI endpointy bez throttlingu znamenají, že útočník dokáže za noc protočit OpenAI kredit za desetitisíce korun. U startupu s LLM funkcionalitou je to asi nejčastější finanční riziko.

Neexistující audit trail a logging. Když aplikace pracuje s osobními daty a nemá záznam o tom, kdo kdy kam sáhl, GDPR i ISO 27001 vyžadují vysvětlení. Pro Series A investora je absence audit trailu důvod ke snížení valuace nebo k dodatečným podmínkám.

Authentication a authorization mismatch. Frontend rozlišuje role, backend ne. Klasický nález — admin endpoint je chráněný jen tím, že ho běžný uživatel ve frontendu nevidí. Stačí curl a problém je hotový.

Náš audit má čtyři fáze a typicky trvá 3 až 5 týdnů podle velikosti kódbáze. Ne všechny fáze běží sekvenčně, ale takhle je předáváme klientovi.

Fáze 1 — přístupy a inventarizace. Dostaneme repository, produkční přístupy, dokumentaci (pokud existuje), seznam third-party služeb. Sepíšeme všechno, co aplikace dělá, kde jsou data a kdo k nim má přístup.

Fáze 2 — automatizovaný scan. Pouštíme statickou analýzu, dependency check, secret scanning, OWASP ZAP proti běžící instanci. Tahle fáze odhalí 60 až 70 % nálezů — zbytek vyžaduje ruční čtení kódu.

Fáze 3 — ruční review citlivých částí. Auth flow, payment processing, AI endpointy, file upload, admin panel. Tady se najdou ty zajímavé věci. U fitness SaaS z předchozí sekce jsme v této fázi narazili na druhý pokus o oslovení auditora — první firma audit dělala, ale ruční fázi vůbec neprovedla a SQL injection minula.

Fáze 4 — report a roadmapa nápravy. Klasifikace nálezů (low/medium/high/critical), odhad pracnosti, doporučené pořadí oprav. Důležitá část je překlad pro investora — investorský deck nepotřebuje detail SQL injection, ale potřebuje jasnou odpověď „co s tím a kdy bude opraveno".

U fitness SaaS jsme po auditu měli na refactor 4 týdny — investor souhlasil s tím, že high-severity nálezy musí být opraveny před closingem, medium se mohou řešit do 90 dnů po investici. Tohle je realistický kompromis, který funguje, pokud audit i refactor dělá stejný tým a komunikace s investorem je férová.

Nikdy klientovi nedoporučujeme nález zakrýt nebo odložit „na později po investici". Za prvé to investor většinou pozná — jeho tech advisory dělá kontrolní scan a nálezy si ověřuje. Za druhé to je důvod k pozdějšímu zhoršení podmínek nebo claw-backu.

Pokud refactor nestihnete, lepší cesta je transparentní mitigation plan s vlastníkem, deadline a pre-závazek na konkrétní rozpočet. Series A investoři jsou zvyklí na to, že early-stage produkt má technický dluh — nejsou zvyklí na zakladatele, který ho zatajuje.

Než auditora oslovíte, projděte si těchto šest bodů. Zkrátíte tím audit a snížíte cenu — auditor neplatí za hledání toho, co si můžete přečíst sami.

Inventarizace přístupů. Seznam všech repository, hosting providerů, third-party API, databází, S3 bucketů. Včetně toho, kdo má kam přístup a od kdy.

Rotace secrets. Vyměňte všechny API klíče, které byly někdy v repository nebo v build outputu. Bez toho audit nemá smysl — najde nálezy, které jste mohli sami eliminovat za hodinu.

Závislosti. Pusťte npm audit nebo pip-audit. Kritické zranitelnosti opravte ještě před auditem.

Dokumentace business flow. Auditor potřebuje vědět, co aplikace dělá z pohledu uživatele — kde vznikají platby, kde se ukládají osobní data, jak funguje onboarding. Dvě stránky textu stačí.

Test environment. Audit běží proti staging, ne produkci. Pokud staging neexistuje, počítejte s jeho přípravou jako součást scope.

Termín a budget. Realistický audit pre-Series A SaaS aplikace stojí v naší cenovce 180 až 320 tisíc Kč podle rozsahu, trvá 3 až 5 týdnů. Pokud někdo nabízí audit za 40 tisíc za týden, něco vynechává.

Pokud máte vibe-coded aplikaci a investor po vás chce due diligence dokumentaci, ozvěte se. Úvodní rozhovor nad scope a předběžný odhad ceny děláme zdarma a do týdne dostanete rámcovou nabídku.