Petr Fojtů: Vibe coding do produkce bez testování nepatří
„Vývojář, který kód vygeneruje, je za něj zodpovědný, jako by byl jeho vlastní,“ říká Petr Fojtů.
AI dnes pomáhá psát kód rychleji než kdy dřív. Jenže rychlost sama o sobě bezpečnou aplikaci nevytvoří. S Petrem Fojtů jsme mluvili o vibe codingu, open-source knihovnách, bezpečnostním testování i o tom, proč by vývojáři neměli slepě věřit vstupům, nástrojům ani vlastnímu pocitu, že „tohle přece nikdo nezneužije“.
Petře, změnil se od našeho posledního rozhovoru váš pohled na to, kde dnes leží největší bezpečnostní rizika?
Nemyslím si. Od té doby nás potkal zejména širší nástup systémů umělé inteligence, které jsou teď všude, jako byl svého času třeba blockchain. Aplikace založené na velkých jazykových modelech mají specifické zranitelnosti, ale principy a rizika jsou víceméně pořád stejná.
Použití těchto modelů v oblasti kybernetické bezpečnosti má své výhody a na své si samozřejmě přijdou i útočníci. A svět se točí dál.
Co si myslíte o současném trendu vibe codingu a využívání umělé inteligence pro generování kódu?
Velké jazykové modely, které stojí za těmito systémy umělé inteligence, jsou nástroj jako každý jiný. Takže hodně záleží na tom, jak je používaný.
Je super, jaké dává možnosti laikům a jak zvyšuje efektivitu profesionálů. Je dobré si ale uvědomit, že takto vygenerovaná aplikace není připravena pro produkční provoz, pokud neprojde nezbytným testováním a ověřováním. Stejně tak je dobré si uvědomit, že vývojář, který kód vygeneruje, je za něj zodpovědný, jako by byl jeho vlastní.
Jaký máte názor na bezpečnost open-source softwaru třetích stran?
Bezpečnost open-source softwaru je ve vývoji samostatná disciplína. Obecně si myslím, že je lepší vzít a použít prověřenou open-source knihovnu, než vymýšlet kolo. Obzvlášť populární open-source balíčky jsou pod drobnohledem a jsou tak bezpečnostně vyzrálé.
Nicméně i jejich bezpečnost je potřeba řídit – musíme vědět, jaký open-source software v projektu máme a v jakých verzích, a monitorovat související zranitelnosti. Kromě toho třeba i licence, pod kterými je software distribuován… ale to už není tak úplně o bezpečnosti.
Podle čeho se v praxi pozná, že je fáze bezpečnostního testování u projektu kompletně hotová?
Bezpečnostní testování jako takové není v podstatě nikdy hotové. Může však naplnit očekávání určitého projektového milníku – pak záleží na míře tolerance rizika projektu nebo organizace.
Například pro spuštění produkčního běhu nesmí systém nebo aplikace obsahovat zranitelnost závažnosti X nebo být vystavena riziku úrovně Y. Tím dojde ke splnění určité kvalifikace, ale bezpečnostní testování tím nekončí. Zpravidla se mění přístup nebo frekvence.
I při produkčním provozu se testuje třeba formou automatických skenů, pravidelných penetračních testů, monitorují se zranitelnosti… hotovo by tak mohlo být, až když se aplikace definitivně odstaví.
Kde podle vašich zkušeností dělají vývojáři tu nejčastější chybu, pokud jde o bezpečnost kódu?
Bývají moc důvěřiví, respektive nemívají tu správnou úroveň paranoie. Neuvědomí si, čemu všemu by neměli věřit – vstupům od uživatele nebo v některých případech z jiného systému, čemukoliv, co běží na uživatelském zařízení (třeba v prohlížeči) atp. Jsou důvěřiví a v kódu pak chybí odpovídající kontroly nebo se spoléhají na něco, na co by se spoléhat neměli.
Jak by dnes měli programátoři přemýšlet nad ochranou citlivých dat? Stačí se spoléhat na moderní nástroje a frameworky?
Dostupné nástroje a frameworky toho řeší skutečně hodně. Jsou to ale technikálie a stejně důležitý je i kontext – jak bude aplikace nasazená, kde, kdo ji bude používat a jak, co od ní čeká, jaká data bude zpracovávat…
Určitě by měli programátoři přemýšlet i nad byznysovým pohledem a souvislostmi. Co je akceptovatelné v jednom kontextu, je naprosto nepřijatelné v jiném. A pokud jim něco není jasné, tak se ptát a nedomýšlet. Mohou uživatelé v aplikaci vidět navzájem svoje data? V jedné ano, v jiné rozhodně ne. A bezpečnost je tu od toho, aby pomohla vymyslet, jak tomu zamezit v případě, že ne.
Jak by vývojáři měli postupovat, když tlak na rychlé nasazení nové funkce naráží na nutnost dodržet základní principy bezpečné architektury?
Hlavně zůstat v klidu a o svých případných obavách transparentně komunikovat. Rozhodnutí, zda to nakonec bude tak, či onak, nepřísluší zpravidla přímo vývojářům. Stejně tak odpovědnost za případné bezpečnostní nedostatky nepůjde za nimi, pokud je tedy nebudou vědomě krýt.
Jak správně specifikovat bezpečnostní požadavky na aplikaci tak, aby jim bez problému rozuměl vývojář, byznys i koncový zákazník?
V podstatě jde o překladatelskou práci. (smích) Záleží, od koho požadavky jdou – od zákazníka, od byznysu, nebo od někoho technického? Pak je nutné je „přeložit“, aby jim i ostatní porozuměli ve „svém jazyce“.
Každý rovněž potřebuje jinou úroveň detailu, ale musí tomu rozumět v podstatě stejně. Pro někoho je důležitý cíl, pro jiného implementační detaily. Nejhorší je, když se někde vyskytne požadavek, kterému vlastně nikdo nerozumí. Každý si totiž myslel, že je důležitý pro někoho jiného, a tak mu rozumět nemusí.
Jakým způsobem lze udržitelně zakomponovat bezpečnostní kontroly do běžných DevOps procesů, aby to týmy nebrzdilo od rychlých dodávek?
Však už nějakou dobu tu máme DevSecOps. Jde o rozšíření klasického DevOps o bezpečnost a související aktivity. Za sebe bych podtrhl dva zásadní principy – posunout bezpečnost „co nejvíce doleva“. To znamená, aby se řešila ve vývojovém cyklu co nejdříve, protože tak je to prostě nejefektivnější. A pak je samozřejmě důležitá automatizace, bez níž nelze držet krok.
V jakých oblastech vývoje softwaru bude podle vás za pár let znalost aplikační bezpečnosti nezbytností a kde se naopak začneme plně spoléhat na nástroje umělé inteligence?
Domnívám se, že znalost bude pořád stejně nezbytná jako dnes. Nástroje umělé inteligence nám pomohou být více efektivní a produktivní, máme s nimi úplně jiné možnosti.
Změní se způsob, jakým automatizujeme a co automatizujeme. Nebudeme automatizovat už jen detekci zranitelností, ale třeba i jejich analýzu a ověřování skutečných pozitiv. Stejně tak se bude automatizovat implementace rutinních bezpečnostních opatření – některé velké jazykové modely je už nyní aktivně uživatelům doporučují nebo rovnou implementují.
Důležitější než to, jaký model se použije pro generování kódu, je, jaký systém se kolem modelu vytvoří.
Jak si při své každodenní práci, kdy neustále hledáte slabiny v systémech, udržujete zdravý nadhled a důvěru v technologie?
Hlavně humor a pozitivní přístup pomáhají s nadhledem, jinak důvěru v technologie stále mám. Míň už v lidi, kteří s nimi pracují. (smích) Zabezpečit se dá v podstatě všechno. Důležité je najít správné řešení, dobře ho zdokumentovat a zajistit, aby mu rozuměli všichni, kdo s ním potřebují pracovat.
Určitě pomáhá i určité odosobnění – pokud někdo nemá rád bezpečnost nebo určité procesy a postupy, za které jste zodpovědný, není to nic osobního.
Kdybyste mohl do každodenní rutiny všech programátorů přidat jeden jediný bezpečnostní návyk, který by to byl a proč?
Obávám se, že nebude jen jediný. (smích) Byl bych moc rád, kdyby každý programátor dodržoval základní bezpečnostní hygienu – než začne používat knihovnu, zjistil si, jestli není dostupná novější verze; nedůvěřoval uživatelským vstupům; rozumně nakládal s „tajemstvími“, jako jsou šifrovací klíče, hesla atp. Prostě aby si sám hlídal takové ty úplné základy.
Stejně tak bych byl moc rád, kdyby v dobré víře netrávil čas implementací „bezpečnostních“ opatření, která jsou vlastně k ničemu nebo dokonce kontraproduktivní… Vlastně jo, ten jeden jediný návyk by byl ozvat se odpovědnému „bezpečákovi“ v případě, kdy neví nebo si není jistý, co s tím, nebo než se pustí do nového „zlepšováku“, aby to s ním probral.
Autor: Lucie Dvořák
