AI nám bere kontrolu nad vývojem, bezpečností a daty!
A bere práci programátorům.
AI nám nic nesebrala. Nemůže. Tu moc nemá. Ale i kdyby měla, nemusela by. My jsme jí kontrolu nad vývojem, bezpečností a daty předali sami. Protože je to pohodlné, rychlé a často to překvapivě dobře funguje.
Problém není, když kód nefunguje. To poznáme hned a můžeme ho opravit. Problém je, když kód nějak funguje, ale v pozadí dělá něco jiného, než by se nám líbilo. V bezpečnosti totiž to, že něco nějak funguje vůbec nestačí.
Měli bychom vědět, jak to funguje, a když se něco změní, tak co to bylo a kde.
Nový aktér
O AI často mluvíme jako o nástroji. Podobně jako o textovém editoru, vyhledávači nebo „autocomplete“.
Jenže AI není jen obyčejný nástroj.
AI:
- čte zadání
- interpretuje záměr
- navrhuje architekturu
- píše kód
- upravuje konfiguraci
- doporučuje knihovny
- vysvětluje chyby
- a často i spouští příkazy
Takže v bezpečnostním modelu už to není pasivní kladivo. Je to další aktér, který se účastní rozhodování – threat model se rozšířil.
Když držím v ruce kladivo jako nástroj, já se rozhoduji o tom, jakou silou, do čeho a jestli vůbec do něčeho praštím.
AI je kladivo, které si o tom všem rozhoduje samo, jen na základě našich instrukcí (promptů). A je nutné si uvědomovat, že my jsme ti, kdo nese zodpovědnost.
Můžu kladivu zadat úkol – "Zatloukej hřebíky!".
AI kladivo „vidí“ hřebík. Vyhodnocuje – "Hm, hřebík, zatluču ho. A je velkej, dám do toho větší sílu".
A vy pak koukáte, jak AI kladivo mlátí do háčku ve zdi. Do háčku v sádrokartonové zdi. Do háčku, na kterém jsou klíče od auta.
AI udělala chybu. My máme problém.
Delegovali jsme na AI nejen vývoj, ale i kontrolu. A dost často jen zdání kontroly. V chatu nám AI tvrdí, že vše je bezpečné. Ale je to tak opravdu?
Když AI vygeneruje kód, který umožní útočníkům získat data našich uživatelů, reputační problém máme my, nikoli AI agent. Těžko můžeme při úniku dat ukázat prstem na AI agenta s tím, že „za to může on!“
Našeho (teď již dost možná bývalého) zákazníka většinou nezajímá, jak byla aplikace vytvořena. Vy ji nabízíte, můžete si za ni i účtovat peníze, tak je vaše zodpovědnost, že data uživatelů zůstanou tam, kde mají být.
Cesta už není cíl
Možnosti vibe codingu umožnily vytvářet aplikace i těm, kteří nikdy nic neprogramovali. Není problém to, že někdo nezná konkrétní syntaxi nějakého programovacího jazyka. To je totiž jen malá část celého programování.
Mezi další důležité součásti vývoje patří např. algoritmizace, propojení jednotlivých částí, nakládání s pamětí, daty a další. Před nástupem vibe coding nástrojů se často programovalo tak, že se jednotlivé části kódu prostě kopírovaly ze stránek typu StackOverflow. Nebylo to ideální, ale autor měl alespoň představu, jakým způsobem funguje např. přihlašování k aplikaci, protože věděl, že musel vytvářet (nebo kopírovat) kód pro běh databáze, přihlašovací formulář na webu a také kód pro server, který data z formuláře porovnával, případně ukládal do té databáze. Takže autor aplikace si možná nepamatoval konkrétní příkaz pro uložení hesla do databáze, ale alespoň věděl, jaká ta cesta hesla do databáze byla a jestli bylo heslo{:cs}Heslo je obecný prostředek k ověření totožnosti (... Více uloženo bezpečně. Dnes? Zadáme „Vytvoř přihlašování pro moji aplikaci“. Enter. A během chvilky máme přihlašování.
Nová funkce -> nové dveře
Takže máme přihlašování. Ale je heslo{:cs}Heslo je obecný prostředek k ověření totožnosti (... Více v databázi uloženo bezpečně nebo je normálně čitelné? Co když zadám do přihlašovacího formuláře něco, co se tam normálně neočekává, například kus kódu? Nebudu schopen přečíst si všechna data z vaší databáze? Nebo se změnou nějakého parametru přihlásit jako jiný uživatel bez toho, že bych znal jeho/její heslo{:cs}Heslo je obecný prostředek k ověření totožnosti (... Více?
Možná si na přihlašování dáme větší pozor, protože tak nějak tušíme, že nakládání s přihlašovacími údaji je kritická část.
Ale co další, na první pohled nevinné funkce?
„Přidej upload souborů“. Zní jako běžná funkce. Ale najednou řešíte:
- Kdo soubor vidí?
- Kde je uložený?
- Jde stáhnout bez přihlášení?
- Může někdo nahrát něco nečekaného?
- Zůstane tam soubor i po smazání účtu?
Upload není jen „ulož soubor“. Je to nové skladiště cizích dat.
„Přidej sdílení odkazem“
Zní to jako jednoduchá pohodlná funkce.
- Kdo ten odkaz může otevřít?
- Dá se odkaz uhodnout?
- Jde později zneplatnit?
- Zobrazí víc dat, než by měl?
- Indexuje ho někde crawler?
Sdílecí odkaz je v podstatě druhé přihlášení. Jen je bez hesla.
Ještě?
„Přidej export do PDF“
- Zní neškodně, protože uživatel si jen stáhne vlastní data.
- Co všechno se do PDF dostane?
- Jsou tam metadata?
- Je PDF někde dočasně uložené?
- Může si někdo stáhnout cizí export?
- Zůstávají exporty na serveru?
Export často vytvoří druhou kopii dat. A ta druhá kopie už nemusí mít stejnou ochranu jako originál.
Příklady by se daly vymyslet asi na většinu funkcí vaší aplikace. A víte jistě, že tohle vaše AI řeší?
Neudělá tu novou funkci prostě rychle a jednoduše, aby vám udělala radost?
AI nevymýšlí nové chyby, vyrábí je ve větším tempu.
U vibe codingu často nejde o úplně nové typy chyb. Jsou to věci, které známe už dlouho: uživatel vidí data někoho jiného, soubor je dostupný bez přihlášení, citlivé údaje skončí v databázi v čitelné podobě, aplikace zapomene ověřit, kdo má k čemu přístup, nebo se do projektu přidá knihovna, které nikdo nerozumí.
Nové je hlavně tempo. Dřív člověk takovou chybu napsal ručně v jedné části aplikace. Dneska AI během pár minut přidá login, upload, export, sdílení a API – a stejný typ chyby se může objevit na více místech najednou.
AI není nový druh chyby. AI je zrychlovač starých chyb.
(Téměř) Fuck Up ze života
Nejsem programátor. Sice už jsem v životě několik málo věcí naprogramoval, ale nikdy jsem se tomu dlouhodobě nevěnoval. A podle toho to vypadalo. Moje výtvory „nějak“ fungovaly, ale spíše jen pro moje osobní použití, peníze bych si za to brát asi nemohl.
S nástupem AI nástrojů jsem se rozhodl „přepsat“ jeden můj starší projekt do obecně použitelné podoby. A protože to znamenalo i nakládání s daty uživatelů, chtěl jsem to mít nastavené tak, že ani já jako provozovatel serveru nemám být schopný data uživatelů číst.
Takže jedno ze základních zadání nebylo jen „nějak tam dej šifrování“. Byl to konkrétní požadavek na koncové (end-to-end) šifrování. Protože nejenom, že mě data uživatelů nezajímají. Já je nechci mít v čitelné podobě i pro případ, že by ze serveru unikly, což je riziko, které nesou všichni, kdo nakládají s daty uživatelů, ať jde o malý projekt jednoho autora, nebo velké mezinárodní korporace. Stát se to prostě může – a stává se to.
Vývoj pokračoval poměrně dobře, AI programovala jak divá, všechno tak nějak fungovalo podle očekávání.
Později jsem přidal export do internetového kalendáře. Praktická funkce, celkem normální požadavek. AI funkci naprogramovala. Fungovalo to.
Po nějaké době jsem chtěl vědět, jestli je opravdu vše v databázi zašifrováno. Data z aplikace šifrovaná byla. Ale vedle těch dat byla tabulka s daty pro export do internetového kalendáře. V čitelné podobě. Ta samá data, která byla „vedle“ bezpečně šifrovaná.
Export do kalendáře totiž není možné koncově šifrovat. Můj požadavek (z mojí neznalosti) šel proti jednomu ze základních pravidel.
AI implementovala funkci, splnila úkol. Ale že tím porušila jedno ze základních pravidel, mi jaksi zapomněla oznámit.
Je to jako dát na dveře kvalitní zámek, ale pak kvůli pohodlí udělat vedle druhé dveře bez zámku. Ten první zámek pořád existuje. Jen už nechrání celou cestu.
Šifrování nebylo prolomené. Bylo obejité. Ne hackerem. Vývojářem.
Mojí výhodou je, že se bezpečností zabývám. Takže nejenže vím, jak si to zkontrolovat, ale hlavně vím, co si mám kontrolovat. A že si to mám kontrolovat. Takže jsem se s tím mohl vypořádat a automatický export do kalendáře jsem vypnul.
Ale pokud bych to neudělal, sliboval bych svým zákazníkům něco, co není pravda. A pravděpodobně by se na to časem přišlo. A to bych vážně nerad:)
Don’t vibe. Verify.
Nechci tím říct, že nemáme vibe codovat. Já to taky dělám. AI je skvělá na rychlé prototypy, refactoring, hledání řešení, generování částí kódu nebo vysvětlování problémů. Problém není vibe coding. Problém je, když zůstane jen vibe – když přijmu výsledek, protože vypadá dobře, ale neověřím, co se změnilo.
V kryptu známe „Don’t trust, verify“. Neznamená to „nikdy nikomu nevěř, nikdy nic nepoužívej“. Znamená to: důvěra není kontrola.
A přesně to samé platí pro AI. Don’t vibe. Verify neznamená „nepoužívej AI“. Znamená to: nepřijímej výsledek jen podle dojmu. Ověř sliby, data, oprávnění a nové dveře, které jsi právě vytvořil.
Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?
— Brian Kernighan, The Elements of Programming Style, 2nd edition, chapter 2
