
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 modelJednoduchý plán, který říká, co chráníte, před kým a jak by útok mohl proběhnout. Více 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 agentAI systém, který nedává jen odpovědi, ale může samostatně používat nástroje a provádět ... Více. Těžko můžeme při úniku datSituace, kdy se citlivá nebo neveřejná data dostanou k někomu, kdo k nim neměl mít přístup. Více 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 codingVývoj aplikace hlavně pomocí AI nástrojů a rychlého zadávání požadavků, často bez hlubš... Více 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í heslaHeslo je obecný prostředek ověření totožnosti (autentizaci) uživatele, kterým nemusí nutně... Více do databáze, ale alespoň věděl, jaká ta cesta heslaHeslo je obecný prostředek ověření totožnosti (autentizaci) uživatele, kterým nemusí nutně... Více do databáze byla a jestli bylo hesloHeslo je obecný prostředek ověření totožnosti (autentizaci) uživatele, kterým nemusí nutně... 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 hesloHeslo je obecný prostředek ověření totožnosti (autentizaci) uživatele, kterým nemusí nutně... 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í hesloHeslo je obecný prostředek ověření totožnosti (autentizaci) uživatele, kterým nemusí nutně... 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Údaje, kterými se přihlašujete ke službě. Typicky jméno, e-mail, heslo, kód nebo bezpečnost... Více 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íOvěření totožnosti. Služba zjišťuje, zda jste opravdu ten, za koho se vydáváte. Více?
- 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íOvěření totožnosti. Služba zjišťuje, zda jste opravdu ten, za koho se vydáváte. Více. Jen je bez heslaHeslo je obecný prostředek ověření totožnosti (autentizaci) uživatele, kterým nemusí nutně... Více.
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Údaje o komunikaci nebo souboru, ne nutně samotný obsah. Například čas, odesílatel, příjemc... Více?
- 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íOvěření totožnosti. Služba zjišťuje, zda jste opravdu ten, za koho se vydáváte. Více, 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Údaje, kterými se přihlašujete ke službě. Typicky jméno, e-mail, heslo, kód nebo bezpečnost... Více, 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í, kde zprávu čte až zařízení odesílatele a příjemce, ne server po cestě. Více) šifrováníPřevod dat do podoby, které bez správného klíče nelze rozumět. Více. 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íPřevod dat do podoby, které bez správného klíče nelze rozumět. Více 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 codingVývoj aplikace hlavně pomocí AI nástrojů a rychlého zadávání požadavků, často bez hlubš... Více. 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íRozhodnutí, co smí přihlášený uživatel vidět nebo dělat. Více 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
