Vibe coding ako nová bezpečnostná hrozba: keď sa dodávateľom softvéru stáva ktokoľvek

Generatívne modely odstránili vstupnú bariéru do vývoja softvéru aj hardvéru. Do pozície dodávateľa sa tak dostáva ktokoľvek — bez vzdelania, bez znalosti odboru a bez procesov, ktoré z kódu robia produkt. Analýza rizík a odporúčania pre objednávateľov aj tvorcov.

Abstrakt

Príspevok analyzuje bezpečnostné dôsledky tzv. vibe codingu — vývoja softvéru, pri ktorom autor formuluje zámer v prirodzenom jazyku a generatívny model produkuje kód, ktorý autor nedokáže odborne posúdiť. Ťažiskom analýzy nie je kvalita generovaného kódu ako taká, ale posun rolí: odstránenie vstupnej bariéry vedie k tomu, že do pozície dodávateľa informačného systému alebo zariadenia sa dostáva subjekt bez odborného vzdelania, bez znalosti domény a bez procesov riadenia životného cyklu, ktoré z kódu robia produkt. Príspevok predkladá taxonómiu rizík na úrovni kódu, dodávateľského reťazca, prevádzky, hardvéru a právnej zodpovednosti, vysvetľuje, prečo klasické akceptačné mechanizmy tieto riziká nezachytia, a formuluje odporúčania pre objednávateľov, tvorcov aj organizácie. Argumentuje, že ide o systémové riziko: chyby generované z rovnakých modelov sú korelované naprieč tisíckami nezávislých produktov.

Kľúčové slová: vibe coding; generatívna AI; bezpečnosť dodávateľského reťazca; NIS2; Akt o kybernetickej odolnosti; zodpovednosť za produkt; SBOM; riadenie životného cyklu.

1. Úvod a vymedzenie problému

Pojem vibe coding zaviedol začiatkom roka 2025 Andrej Karpathy na označenie spôsobu práce, pri ktorom sa vývojár „úplne oddá pocitu, prijme exponenciály a zabudne, že nejaký kód vôbec existuje”^[1]. Autor opisuje postup, v ktorom zadáva zámer v prirodzenom jazyku, prijíma vygenerované zmeny bez čítania a chyby rieši tým, že chybové hlásenie skopíruje späť modelu. Pre prototypy, jednorazové skripty a víkendové projekty ide o legitímnu a mimoriadne produktívnu techniku.

Bezpečnostným problémom sa vibe coding stáva až v okamihu, keď takto vzniknutý artefakt prekročí hranicu medzi experimentom a dielom dodaným tretej strane. Táto hranica bola historicky strážená vstupnou bariérou: kto chcel dodať informačný systém, musel sa najprv naučiť programovať, a cestou k tejto zručnosti nadobudol — hoci aj mimovoľne — predstavu o testovaní, verziovaní, autentifikácii, správe tajomstiev či o tom, čo znamená nasadenie do produkcie. Bariéra bola neefektívna a vylučujúca, ale plnila vedľajšiu funkciu filtra kompetencie.

Generatívne modely túto bariéru odstránili. Odstránili však len bariéru tvorby, nie požiadavky prevádzky. Práve v tejto asymetrii vzniká nová trieda rizika, ktorej sa venuje tento príspevok.

2. Posun rolí: od používateľa nástroja k dodávateľovi

2.1 Zánik vstupnej bariéry

Vývoj funkčnej webovej aplikácie, mobilnej aplikácie alebo firmvéru pre mikrokontrolér je dnes dosiahnuteľný za niekoľko hodín pre osobu bez formálneho vzdelania v odbore a bez predchádzajúcej praxe. To samo osebe nie je defekt — je to demokratizácia s významným pozitívnym potenciálom. Kritická zmena nastáva vtedy, keď takáto osoba ponúkne výsledok na trhu: mestu ako evidenčný systém, ambulancii ako objednávkový portál, prevádzke ako pokladničné riešenie, výrobcovi ako riadiacu jednotku.

V tom okamihu preberá rolu, s ktorou sú spojené povinnosti nezávislé od spôsobu vzniku diela: povinnosť zabezpečiť dôvernosť a integritu spracúvaných údajov, povinnosť odstraňovať zraniteľnosti počas celej životnosti produktu, povinnosť oznamovať incidenty, povinnosť preukázať, z čoho je produkt zložený. Nadobúdateľ tieto povinnosti spravidla predpokladá — a zvyčajne sa ani nepýta, či ich dodávateľ vie splniť.

2.2 Kompetenčná asymetria a ilúzia hotového diela

Podstatou rizika nie je to, že model napíše zlý kód. Modely píšu kód, ktorý je v priemere porovnateľný s priemerom svojich trénovacích dát, a v mnohých úlohách kvalitnejší než kód začiatočníka. Podstatou rizika je, že autor nemá aparát na posúdenie toho, čo dostal. Nevie rozlíšiť medzi troma stavmi, ktoré sú z pohľadu demonštrácie nerozoznateľné:

1. systém funguje — na šťastnej ceste, s očakávanými vstupmi, pri jednom používateľovi;
2. systém je správny — obstojí aj pri neočakávaných vstupoch, súbežnom prístupe a chybových stavoch;
3. systém je bezpečný a udržateľný — odolá zámernému zneužitiu a dá sa opraviť aj o dva roky.

Vibe coding poskytuje spoľahlivo prvý stav a vytvára presvedčivú ilúziu, že ide o tretí. Demonštrácia je pritom jediný dôkazný prostriedok, ktorý má laický dodávateľ k dispozícii — a zároveň jediný, ktorému laický objednávateľ rozumie. Vzniká tak transakcia, v ktorej ani jedna strana nedokáže posúdiť predmet plnenia, čo je z hľadiska riadenia rizík výrazne horšia konfigurácia než klasická informačná asymetria, kde aspoň dodávateľ vie, čo dodáva.

3. Taxonómia rizík

3.1 Riziká na úrovni kódu

Generovaný kód systematicky inklinuje k funkčnosti na úkor obranyschopnosti, pretože trénovacie dáta obsahujú prevažne ukážkový kód orientovaný na zrozumiteľnosť, nie na produkčné nasadenie. V praxi ide najmä o:

• autentifikáciu a autorizáciu, ktorá overuje totožnosť, ale nie oprávnenie na konkrétny záznam (chýbajúca kontrola vlastníctva objektu);
• tajomstvá v zdrojovom kóde — API kľúče, heslá k databázam a tokeny zapísané priamo v súbore, ktorý neskôr skončí vo verejnom repozitári;
• nesprávne použitú kryptografiu — vlastné „šifrovanie”, zastarané hašovacie funkcie pri heslách, statické inicializačné vektory;
• injekčné zraniteľnosti pri skladaní dotazov a príkazov z reťazcov;
• chýbajúce obmedzenie rýchlosti a veľkosti vstupu, čím sa banálny endpoint stáva vektorom odopretia služby;
• ladiace a diagnostické režimy ponechané zapnuté v produkcii, vrátane podrobných chybových hlásení odhaľujúcich vnútornú štruktúru systému;
• absenciu testov — kód, ktorý nemá test, nemá ani definíciu správneho správania, a teda ho nemožno bezpečne zmeniť.

Osobitným javom je strata koherencie pri raste. Kým generovaný celok je malý, model si ho udrží „v hlave”. Po prekročení určitého rozsahu vznikajú duplicitné implementácie tej istej logiky, ktoré sa pri opravách rozchádzajú — chyba sa opraví na jednom mieste a v troch ďalších pretrvá. Autor bez prehľadu o štruktúre kódu túto divergenciu nezaznamená.

3.2 Riziká dodávateľského reťazca

Model navrhuje závislosti na základe štatistickej pravdepodobnosti, nie overenej existencie. Dôsledkom je halucinácia balíkov — odporučenie knižnice, ktorá neexistuje. Útočníci tento jav systematicky zneužívajú tak, že často halucinované názvy registrujú vo verejných repozitároch a napĺňajú škodlivým obsahom (technika označovaná ako slopsquatting)^[2]. Laický dodávateľ nemá dôvod pochybovať: príkaz na inštaláciu prebehne úspešne a aplikácia sa spustí.

K tomu sa pridáva nepripnuté verziovanie závislostí, absencia rozpisu komponentov (SBOM) a nekontrolované licenčné riziko — model reprodukuje aj vzory pochádzajúce z projektov s copyleft licenciami bez toho, aby na licenčný režim upozornil. Objednávateľ tak preberá dielo, o ktorom nikto nevie povedať, z čoho je zložené a za akých podmienok ho smie používať.

3.3 Prevádzkové riziká a životný cyklus

Najzávažnejšia skupina rizík sa prejaví až po odovzdaní. Vibe-coded dodávka spravidla nemá:

• kanál na aktualizácie — neexistuje mechanizmus, ktorým by sa oprava dostala k nasadeným inštanciám;
• auditné a bezpečnostné logovanie — po incidente neexistuje záznam, z ktorého by sa dal rekonštruovať priebeh;
• zálohovanie a overený postup obnovy;
• monitorovanie zraniteľností závislostí — o zverejnení kritickej zraniteľnosti v použitej knižnici sa dodávateľ nedozvie;
• dokumentáciu a prevádzkové postupy — inštitucionálna pamäť diela neexistuje ani u autora, pretože kód nikdy nečítal;
• kapacitu na reakciu — jediná osoba bez zástupu, bez SLA a bez postupu pri incidente.

Vzniká tak systém, ktorý je funkčný v momente odovzdania a od tohto momentu už len degraduje, pretože prostredie sa mení a dielo sa nemení s ním.

3.4 Riziká na strane hardvéru a firmvéru

V hardvérových projektoch sú dôsledky ešte menej reverzibilné. Vygenerovaný firmvér pre bežne dostupné vývojové dosky býva nasadený bez zabezpečeného zavádzania (secure boot), bez šifrovania pamäte, s ladiacim rozhraním ponechaným prístupným a bez akejkoľvek možnosti aktualizácie na diaľku. Zariadenie inštalované v teréne — v rozvádzači, vo výrobnej linke, v domácnosti klienta — sa tak stáva trvalým a neopraviteľným prvkom útočnej plochy. K tomu pristupujú povinnosti, o ktorých laický tvorca spravidla nevie vôbec: posúdenie zhody, označenie CE, požiadavky na rádiové zariadenia vrátane kybernetickobezpečnostných delegovaných aktov a technická dokumentácia, ktorú musí vedieť predložiť orgánu dohľadu.

3.5 Právne a regulačné riziká

Spôsob vzniku diela nemá vplyv na rozsah povinností. Relevantné sú najmä:

• NIS2 — smernica (EÚ) 2022/2555 ukladá povinným subjektom riadiť riziká dodávateľského reťazca vrátane bezpečnosti u priamych dodávateľov^[3]. Ak mesto, nemocnica alebo prevádzkovateľ kritickej infraštruktúry obstará vibe-coded systém, zodpovednosť za neposúdeného dodávateľa zostáva na ňom.
• Akt o kybernetickej odolnosti — nariadenie (EÚ) 2024/2847 zavádza pre výrobky s digitálnymi prvkami povinnosť bezpečnosti už v návrhu, riadenia zraniteľností počas podpornej lehoty a poskytovania SBOM; oznamovacie povinnosti pri aktívne zneužívaných zraniteľnostiach nadobúdajú účinnosť od 11. septembra 2026 a plná aplikovateľnosť nastáva 11. decembra 2027^[4]. Príležitostný tvorca uvádzajúci produkt na trh sa dostáva do pozície výrobcu so všetkými dôsledkami.
• Zodpovednosť za chybné výrobky — nová smernica (EÚ) 2024/2853 výslovne zahŕňa softvér medzi výrobky a za chybu považuje aj nedostatočnú kybernetickú bezpečnosť či neposkytovanie aktualizácií^[5].
• GDPR — čl. 25 a 32 vyžadujú ochranu údajov už v štádiu návrhu a primeranú úroveň bezpečnosti spracúvania; pri sprostredkovateľovi je objednávateľ povinný overiť dostatočné záruky^[6].
• Akt o umelej inteligencii — nariadenie (EÚ) 2024/1689 sa uplatní, ak je AI súčasťou samotného dodaného systému, s odstupňovanými povinnosťami podľa rizikovej kategórie^[7].

3.6 Systémové riziko: korelované zlyhanie

Klasický ekosystém softvéru bol z hľadiska chýb heterogénny: tisíc nezávislých tímov robilo tisíc rôznych chýb. Ak je však veľká časť novej produkcie generovaná úzkou skupinou modelov s podobnými trénovacími dátami, chyby prestávajú byť nezávislé — rovnaký chybný vzor sa reprodukuje naprieč tisíckami nesúvisiacich produktov. Jedna objavená zraniteľnosť v často generovanom vzore sa tak stáva univerzálnym kľúčom s plošným dosahom. Tento efekt monokultúry je z hľadiska odolnosti ekosystému závažnejší než ktorákoľvek jednotlivá zraniteľnosť uvedená vyššie.

4. Prečo klasické akceptačné mechanizmy zlyhávajú

Obvyklé preberacie konanie overuje funkčné požiadavky predvedením. Práve túto disciplínu vibe coding spĺňa výborne — dielo je optimalizované presne na to, aby demonštrácia prebehla hladko. Bezpečnostné a prevádzkové vlastnosti sú naopak negatívne definované: sú to tvrdenia o tom, čo sa nesmie stať. Ich overenie vyžaduje cielené hľadanie protipríkladov, nie predvedenie úspešného scenára.

Zlyháva aj druhá obvyklá poistka — odborná recenzia. Recenzia predpokladá recenzenta, ktorý rozumie viac než autor. V modeli, kde autor kód nečítal a objednávateľ mu nerozumie, recenzent v reťazci jednoducho nefiguruje. Kontrola sa presúva na samotný model — ten však hodnotí vlastný výstup rovnakými distribúciami, ktorými ho vytvoril, a systematické slepé miesta si nevšimne.

5. Odporúčania

5.1 Pre objednávateľa

Ťažisko obrany leží na strane toho, kto dielo obstaráva. Odporúčame:

1. Overiť dodávateľa, nie demonštráciu. Položte tri otázky, ktoré laický dodávateľ nedokáže zodpovedať: Ako sa k nasadeným inštanciám dostane bezpečnostná oprava? Z akých komponentov tretích strán je dielo zložené a ako sledujete ich zraniteľnosti? Čo presne sa zaznamená a kde to nájdem, keď dôjde k incidentu?
2. Vyžiadať SBOM (vo formáte CycloneDX alebo SPDX) ako súčasť plnenia, nie ako dodatočnú prílohu.
3. Zaviesť bezpečnostné akceptačné kritériá do zmluvy: absencia tajomstiev v repozitári, žiadne kritické a vysoké nálezy zo statickej analýzy a analýzy závislostí, overenie autorizácie na úrovni jednotlivého záznamu, funkčná obnova zo zálohy predvedená pri preberaní.
4. Zmluvne ošetriť životný cyklus — dĺžku podpornej lehoty, lehoty na opravu podľa závažnosti, povinnosť oznámiť incident v lehote zodpovedajúcej regulácii, prístup k zdrojovému kódu alebo úschovu (escrow), postup pri ukončení spolupráce.
5. Pri systémoch spracúvajúcich osobné údaje alebo dostupných z internetu vyžadovať nezávislý penetračný test pred uvedením do prevádzky — hradený z rozpočtu projektu, nie ako neskorší nadštandard.
6. Uplatniť princíp najmenších oprávnení na úrovni obstarania — nový dodávateľ nedostáva prístup do produkčného prostredia, ale do izolovaného prostredia s testovacími dátami.
7. Zapracovať požiadavku napojenia na centrálny bezpečnostný stack (auditné udalosti v prenositeľnej schéme, odosielanie do SIEM, spúšťanie incidentu) už do zadania — dodatočné doplnenie znamená prestavbu.

5.2 Pre tvorcu, ktorý používa generatívne modely

Vibe coding nie je potrebné zakázať; je potrebné vymedziť, kde končí. Odporúčame:

1. Rozlišovať prototyp a produkt. Prototyp má právo vzniknúť akokoľvek; produkt musí prejsť inou disciplínou. Prechod medzi nimi je vedomé rozhodnutie, nie plynulý sklz.
2. Neodovzdávať kód, ktorý ste nečítali. Ak dielo prekračuje vaše čitateľské schopnosti, prizvite recenzenta — alebo dielo neodovzdávajte.
3. Zaviesť automatické kontroly do zostavovacieho procesu: statická analýza, kontrola závislostí voči databáze zraniteľností, detekcia tajomstiev, kontrola licencií. Ide o hodinu jednorazového nastavenia.
4. Pripnúť verzie závislostí a overiť existenciu každého balíka pred jeho pridaním; balík, ktorý navrhol model a ktorý nepoznáte, overte v oficiálnom registri vrátane počtu vydaní a autora.
5. Vopred navrhnúť aktualizačný kanál a auditné logovanie — nie po prvom incidente. Pri hardvéri to znamená aktualizáciu na diaľku a zabezpečené zavádzanie ako súčasť prvého prototypu.
6. Formulovať hrozbový model v troch vetách: čo chránim, pred kým, a čo sa stane, keď to zlyhá. Model túto úvahu za vás neurobí, pretože ju nemá odkiaľ poznať.
7. Priznať hranicu kompetencie. Odmietnutá zákazka je lacnejšia než incident, za ktorý zodpovedáte.

5.3 Pre organizáciu

1. Zaviesť register interne vyvinutých riešení vrátane tých, ktoré vznikli mimo IT útvaru. Tabuľkový procesor s makrom, ktorý dnes generuje jeden zamestnanec, je zajtra závislosťou procesu.
2. Prijať pravidlo pre používanie generatívnych nástrojov — čo sa smie vkladať do modelu (najmä vo vzťahu k osobným údajom a obchodnému tajomstvu) a čo musí prejsť recenziou pred nasadením.
3. Vzdelávať objednávateľov, nie len vývojárov. Rozhodnutie o riziku robí ten, kto podpisuje zmluvu.
4. Považovať absenciu odpovede na otázky z bodu 5.1 za vylučujúce kritérium, nie za bod na neskoršie doriešenie.

5.4 Minimálny akceptačný štandard

6. Záver

Vibe coding nie je hrozbou preto, že by generatívne modely písali zlý kód — v mnohých ohľadoch píšu kód lepší než priemerný začiatočník. Hrozbou je, že odstránil poslednú prekážku medzi zámerom a dodávkou, pričom nedodal nič, čo by nahradilo funkciu, ktorú táto prekážka plnila: overenie, že ten, kto dodáva, rozumie tomu, čo dodáva, a dokáže sa o to starať po celý čas, čo to bude v prevádzke.

Riešením nie je návrat k vstupnej bariére. Riešením je presunúť dôkazné bremeno z demonštrácie na overiteľné vlastnosti diela — na rozpis komponentov, aktualizačný kanál, auditný záznam, obnovu a určenú zodpovednosť. Tieto požiadavky sú splniteľné aj pre malého dodávateľa a ich formulácia je v rukách objednávateľa. Kým sa nestanú štandardnou súčasťou zadania, bude platiť, že najrýchlejšie vznikajúci softvér je zároveň softvérom s najkratšou bezpečnou životnosťou.

Ilustračné video: Oleg Gamulinskii / Pexels.

Literatúra

1. Karpathy, A. Príspevok na sieti X k pojmu vibe coding, február 2025.
2. OWASP. OWASP Top 10 for LLM Applications 2025 (najmä Supply Chain a Misinformation vrátane halucinácie balíkov). OWASP GenAI Security Project, 2025.
3. Európsky parlament a Rada. Smernica (EÚ) 2022/2555 (NIS2), čl. 21 ods. 2 písm. d). Úradný vestník EÚ, 2022.
4. Európsky parlament a Rada. Nariadenie (EÚ) 2024/2847 (Akt o kybernetickej odolnosti). Úradný vestník EÚ, 2024.
5. Európsky parlament a Rada. Smernica (EÚ) 2024/2853 o zodpovednosti za chybné výrobky. Úradný vestník EÚ, 2024.
6. Európsky parlament a Rada. Nariadenie (EÚ) 2016/679 (GDPR), čl. 25, 28 a 32. Úradný vestník EÚ, 2016.
7. Európsky parlament a Rada. Nariadenie (EÚ) 2024/1689 (Akt o umelej inteligencii). Úradný vestník EÚ, 2024.
8. NIST. Secure Software Development Framework (SP 800-218) a jeho doplnok pre generatívnu AI (SP 800-218A). National Institute of Standards and Technology, 2022 – 2024.