Vibe coding, 1. díl: Funkční kód není automaticky bezpečný

Faktem je, že vibe coding zrychluje vývoj. Funguje to však v praxi opravdu tak, že umělá inteligence napíše velký kus aplikace, člověk doladí několik detailů a prototyp je připravený k nasazení do produkce? Tak jednoduché to není, protože v tu chvíli byste mohli otevřít Pandořinu skříňku. 

Rizikem není, že by umělá inteligence kódovala nebo programovala špatně. Riziko spočívá v tom, že umí dodat funkční řešení bez bezpečnostních pojistek. V tomto článku se dozvíte, co si u vibe codingu pohlídat, aby se z něj nestal generátor bezpečnostních hrozeb.

Vyšší rychlost vývoje, ale současně i riziko

Cloud Security Alliance popisuje vibe coding jako AI-asistovaný přístup, kdy zadáváte požadavky v přirozeném jazyce a LLM (Large Language Model) z nich vygeneruje odpovídající kód. Role vývojáře se tak od psaní kódu přesouvá k vedení, testování a dolaďování.

To samo o sobě není problém. Otázkou je, co to udělá s tempem celého vývoje. Vibe coding je skvělý na rychlé iterace a prototypování: během hodin vytvoříte aplikaci, jejíž příprava dříve trvala dny. Jenže právě zařazená vyšší rychlost má i svou stinnou stránku. 

3 věci, které byste měli znát

1. Vibe coding zrychlí vývoj, ale zkrátí čas na kontrolu.
2. AI zvládne vytvořit funkční řešení, ale neřídí se při tom bezpečnostními standardy.
3. Bez mantinelů (co bez seniora nejde) a průběžných kontrol (review, SAST/SCA, secrets) prototyp snadno způsobí např. únik dat, převzetí účtu nebo problém v závislostech.

Prototyp se snadno překlopí do produkce, protože funguje, a bezpečnostní detaily (validace vstupů, oprávnění, session, limity) se odloží na později. Výsledkem je nový typ bezpečnostního rizika: nevzniká jen tím, že něco zanedbáte, ale tím, že do kódu přibývá velké množství změn, které nikdo nekontroluje do hloubky, protože není čas.

Až budete zvažovat, jestli vibe coding ve firmě povolit, berte to spíše jako změnu ve vašem SDLC (Software Development Life Cycle) než jako rozhodnutí o jednom nástroji. Vzniká tak další generátor produkčního kódu – vedle interního vývoje a open-source – a ten je potřeba řídit stejně přísně. Nejen kvůli kvalitě, ale i proto, že samotné dolaďování AI iteracemi je z pohledu bezpečnostní strategie nedostatečné.

Studie na arXivu ukazuje, že po opakovaných „vylepšovacích“ iteracích se počet kritických zranitelností může zvýšit už během několika kol. Pointou tedy je: čím rychleji iterujete, tím důležitější je kontrolní mechanismus v režimu člověk + automatizace.

U vibe codingu je snadné zaměnit funkčnost za bezpečnost. Proto si nastavte základní postup, který bude platit pro AI návrhy.

Jak udělat vibe coding bezpečný už dnes

• Začněte standardem: předem si určete, jak má vypadat autentizace, autorizace, práce se session a logování.
• Nechte AI psát, ale člověka rozhodovat: změny do produkce vždy schvaluje vývojář.
• Vstupy a oprávnění kontrolujte jako první: validace na serveru a autorizace na úrovni objektu jsou nejčastější slabiny.
• Oddělte prototyp a produkci: co vzniklo na zkoušku, nesmí jít ven bez stejné kontroly jako běžný release.
• Když si nejste jistí, zastavte to: kritické části systému (identity, kryptografie, platby) patří do rukou seniora.

Nejčastější přešlapy AI-generovaného kódu

Při vibe codingu se opakují rozšířené kategorie chyb. Vývojáři je sice znají, ale v rychlosti přeskočí „nudné“ části, ty jsou však pro bezpečnost klíčové.

Validace vstupů a injekce

LLM skládají kód tak, aby hezky plynul od formuláře po databázi. Jestliže však není správně nastavená validace na straně serveru a ošetření vstupů, měla by začít blikat červená kontrolka. U webových aplikací se typicky otevírá cesta k injekcím (SQL injection, XSS, command injection, path traversal) – často proto, že aplikace bere vstupy tak, jak přišly, a bez kontroly je použije na kritických místech: v databázovém dotazu, v generovaném HTML nebo v systémovém příkazu.

V prototypu to může vypadat jako detail. V produkci to však znamená zkratku k úniku dat, zneužití účtů a případně i k průniku dál do systému.

Authn/authz: přihlášení není oprávnění

Autentizace (kdo jste) bývá částečně ošetřená, ale autorizace (na co máte právo) je problematičtější. U AI-generovaného kódu mnohdy chybí důsledná kontrola oprávnění na úrovni objektu (typicky IDOR), role jsou příliš široké a hranice mezi „uživatel může“ a „uživatel nesmí“ není striktně vymezená. Uživatel se tak může dostat k cizím datům nebo funkcím, které mu nepatří, a z chyby aplikace je rázem incident s reputačním i regulatorním rizikem.

Session management

Také u session managementu se opakují stejné vzorce: tokeny bez rozumné expirace, chybějící rotace, u klienta uložené tak, že je snadné je ukrást, nebo jen částečně ošetřené CSRF (Cross-Site Request Forgery).

Token se tak dá získat z prohlížeče nebo ze sítě (například přes únik v logu/debugu nebo na nezabezpečeném zařízení), a když má navíc dlouhou platnost, útočník ho jednoduše použije místo uživatele. Dopad je nepříjemný: útočník se zmocní session a chová se jako legitimní uživatel, případně se díky tomu dokáže posouvat dál do dalších systémů a účtů.

Chybějící rate limiting a ochrana proti zneužití

Když se vibe codingem staví API nebo aplikace, často se v rychlosti vynechají některá opatření proti zneužití. Chybějí limity na počet pokusů, zpomalení podezřelého provozu a základní hlídání, co je ještě normální a co už ne. V praxi to znamená, že někdo může zkoušet hesla pořád dokola, hromadně dolovat data nebo službu zahltit tak, že začne padat výkon i dostupnost. A i když nejde o cílený útok, mohou nastat provozní problémy.

Tajná a citlivá data: nejrychlejší cesta k průšvihu

U vibe codingu se citlivé informace snadno zatoulají tam, kde je rozhodně mít nechcete. Občas někdo do kódu vloží klíč nebo token za účelem testu a jeden nebo druhý už tam zůstane. Jindy se do logů omylem dostanou osobní údaje nebo přístupové tokeny. A čím dál častější problém je i samotný prompt: lidé do AI kopírují konfigurace, výpisy chyb nebo ukázky dat, protože chtějí rychle poradit, a tím nevědomky vytvářejí bezpečnostní riziko.

Jednoduché pravidlo zní: API klíče a hesla do kódu ani do promptů nepatří. Umělou inteligenci veďte k tomu, aby pracovala s proměnnými prostředími nebo se secrets managementem, ne s tvrdě zadanými údaji.

Supply chain riziko: závislosti, které si přitáhnete do kódu

Vibe coding svádí k častému přidávání knihoven – protože AI rychle najde balíček, který se hodí. Jenže každá závislost je zároveň cizí kód ve vašem produktu. Riziko nespočívá jen v tom, že je knihovna například zastaralá. Problémem mohou být její známé zranitelnosti nebo vámi nainstalované „cosi“, co nemá důvěryhodnou údržbu.

Řešení je jednoduché a funkční: závislosti se musí řídit stejně disciplinovaně jako například přístupy. Jinak se vám zrychlení vývoje může vymstít v podobě incidentu nebo patchování pod tlakem.

Jak udržet závislosti pod kontrolou

• Před instalací ověřte „kdo a jak“: balíček musí mít jasného správce, aktivní údržbu a dohledatelnou historii.
• Zamkněte verze a skenujte: používejte fixované verze a automatickou kontrolu zranitelností závislostí.
• Pozor na názvy: když balíček neznáte, ověřte, že opravdu existuje a že nejde o podobný název (typosquatting).
• Mějte pravidla pro kritické systémy: u citlivých částí aplikace zvažte povinné schvalování nových závislostí.
• Když už problém nastane: zablokujte balíček/verzi, rychle upgradujte nebo nahraďte a prověřte, jestli se změna nepropsala do dalších projektů.

Prompt a kontext jako šikmá plocha

Nejde jen o to, co umělá inteligence napíše, ale hlavně o to, co jí dáte k dispozici. Jakmile se do promptu nebo kontextu přimíchá nedůvěryhodný obsah, otevírá se nová vrstva problému: prompt injection a nechtěné chování generovaného kódu. V praxi to může skončit tím, že AI navrhne řešení, které tiše obchází bezpečnostní záměry, nebo nabídne „učesaný“ kód, který je chybný přesně v těch místech, jejichž oprava je nejdražší až po incidentu.

Proto se vyplatí držet jednoduché zero-trust pravidlo: s promptem a výstupem AI zacházejte jako s nedůvěryhodným. Berte ho jako návrh, ne jako autoritu. A když AI tvrdí, že je bezpečný, stejně by měl projít stejnými kontrolami jako ručně psaný kód – testy, review a automatizovanými skeny. 

Pomáhá i disciplína v zadávání – tady je nezbytné jasně definovat, co je povolené a co zakázané, chtít konkrétní výstupní strukturu (např. odkud beru vstupy, jak validuji, jak řeším authz) a nenechat AI dovymýšlet části, které nemá ověřené.

Minimum pro bezpečné používání vibe codingu ve firmě

• Zákaz oblastí bez zásahu seniora: identity a přístupová práva, kryptografie, platby, kritické integrace, vysoce citlivá data.
• Povinná kontrolní smyčka: žádné přímé nasazení změn od AI bez kontroly kódu člověkem.
• Automatizované kontroly v CI: statická analýza kódu (SAST), kontrola závislostí a zranitelností knihoven (SCA) a hledání tajných klíčů v kódu (secrets scanning).
• Určení pravidel pro tajné údaje (secrets): žádné klíče a tokeny do promptu ani repozitáře, jasný postup rotace při podezření na únik.
• Důraz na dohledatelnost: u kritických repozitářů vědět, kdo změnu zadal, kdo ji schválil a jak prošla kontrolami.
• Dodržování bezpečného rámce místo zákazu: doporučený nástroj, krátký interní manuál správného postupu.

Governance a Shadow AI: vývoj mimo dohled

Když vibe coding ve firmě jen plošně zakážete, bezpečnost si tím nezaručíte. Vaši zaměstnanci si cestu stejně najdou. Jen s tím rozdílem, že celou situaci nebudete mít pod kontrolou. Toto riziko jsme popsali v článku o Shadow AI: problém není používání samotné umělé inteligence, ale její používání bez pravidel a dozoru – co se do nástrojů zadává a jak se s výstupy následně pracuje. Pro vibe coding platí totéž, protože výsledkem je kód, který může skončit v produkci.

Shadow AI: Tichý pomocník, nebo bezpečnostní riziko?

Zobrazit

Co s tím prakticky?

Místo zákazů zaveďte oficiální bezpečnou cestu: schválený nástroj, jasná pravidla použití, co je povolené a co bez seniora nesmí do kritických oblastí. A hlavně pravidla, která zabrání, aby se AI výstupy dostaly do produkce bokem – kontrola kódu člověkem a automatické testy a skeny. Když lidem dáte jednoduchý, bezpečný postup, snížíte motivaci obcházet pravidla a současně získáte dohled a auditovatelnost.

Co si z článku odnést

• Vibe coding je další způsob, jak vytvářet kód. Když ho nekontrolujete, riskujete tím vznik budoucích bezpečnostních problémů.
• To, že aplikace běží, ještě neznamená, že je bezpečná. U AI-generovaného kódu často chybějí základní pojistky.
• Zásadním rizikem jsou secrety a citlivá data. Jakmile se dostanou do promptu, logů nebo repozitáře, hrozí incident.
• Důležité je řídit se bezpečnostním minimem (např. povinné code review, automatické kontroly v CI, jasně dané oblasti, které se neobejdou bez zásahu seniora).
• Samotný zákaz obvykle nepomůže. Bez pravidel a oficiálního bezpečnostního rámce se vibe coding může změnit v Shadow AI ve vývoji.

Kateřina Dobrá
Marketingový specialista pro B2B

Káťa se věnuje tvorbě článků, O2 CyberCastu a newsletterů na téma kyberbezpečnosti a moderních technologií. Srozumitelně překládá složitá témata do lidské řeči, propojuje technický svět s praxí a ráda jde pod povrch věcí. Zaměřuje se na bezpečnost dat, nové technologické trendy a jejich reálný dopad na firmy i jednotlivce.