Článek
Když ve středu odpoledne přišel poplach z monitoringu, byl si náš CTO Michal Roth jistý jednou věcí: záplata byla naplánovaná na půlnoc. Ráno vyšlo oznámení CVE o kritické zranitelnosti v Ubuntu, jeho tým si naplánoval údržbu mimo provozní hodiny a všechno běželo podle standardního postupu posledních deseti let.
Ve firmě DesignDev vyvíjíme a provozujeme webové aplikace pro klienty z bankovnictví, e‑commerce a B2B SaaS. Výpadek je u téhle klientely drahý, bezpečnostní incident ještě dražší.
„Půlnoc zněla rozumně,“ říká dnes Michal. „Nechtěli jsme záplatovat v otevírací době, nechtěli jsme výpadek. Ten plán by před třemi lety byl naprosto v pořádku.“
V pořádku nebyl. Než se technici dostali k terminálu, někdo už byl uvnitř.
Okno se zmenšilo o dva řády
Ten incident má širší podtext, který bezpečnostní výzkum sleduje několik let. Doba, za kterou útočníci dokážou nově zveřejněnou zranitelnost zneužít, se zkrátila ze dnů na hodiny. Verizon ve zprávě DBIR 2024 zaznamenal meziroční nárůst o 180 procent u průniků, které začaly zneužitím zranitelnosti. Zneužití zranitelnosti se tak stalo jedním z hlavních způsobů, jak se útočník dostane dovnitř.
Druhá strana téhož grafu vypadá hůř. Edgescan ve Vulnerability Statistics Report 2025 uvádí, že kritickou zranitelnost v aplikaci organizace záplatují v mediánu 74 dní. Skoro polovina zranitelností v podnikových systémech zůstává neopravená i rok po odhalení. Mezi prvním funkčním exploitem v řádu hodin a typickou reakcí provozovatele v řádu měsíců zeje propast o dva řády.
„Ten rozdíl je provozní realita,“ říká Michal. „Když se v devět ráno objeví CVE, v deset už ji nějaký skenovací bot zkouší na našich IP rozsazích. V poledne máme buď zavřeno, nebo máme problém.“
Americká CISA prostřednictvím katalogu Known Exploited Vulnerabilities dnes přidává nově a aktivně zneužívané položky každý týden. Edgescan napočítal jen za rok 2024 přes 760 zranitelností, které byly poprvé zneužity v reálném provozu. Záplata na ně většinou existovala. Chyběl čas a plán ji nasadit.
AI rozšířila asymetrii na obou stranách
Posun rychlosti probíhá několik let. Generativní AI ho za poslední rok zrychlila z obou stran.
Jde o dvě odlišné roviny zranitelnosti. První jsou známé díry v infrastruktuře, tedy CVE v operačním systému, frameworku nebo knihovně, na které už existuje záplata i hotový exploit. Druhou je únik tajemství, typicky klíče, tokeny a hesla zapsané natvrdo přímo v kódu. AI zrychluje obojí najednou: útočníkům pomáhá rychleji zneužít známé zranitelnosti v infrastruktuře a vývojářům pomáhá rychleji vyrobit špatně zabezpečený kód, který se vzápětí stává cílem.
Michal popisuje typickou situaci z našeho týmu. „Požádám Claude, aby napsal kus integrace. Vrátí mi funkční kód. Dobrý kód. A také by ho rovnou commitnul, i s API klíčem v souboru, protože to byla nejjednodušší cesta k funkčnímu výsledku.“
GitHub Octoverse 2024 uvádí, že AI asistenta dnes používá drtivá většina vývojářů. Analýza GitClear z roku 2024 ukázala výrazný nárůst takzvaného code churn, tedy kódu přepsaného během dvou týdnů od napsání. Vyšší code churn je signál, že rychlost produkce kódu přerostla kapacitu jeho kontroly.
Na druhé straně už tu jsou nástroje, které toho využívají. TruffleHog a GitLeaks skenují veřejné repozitáře na vzory klíčů, tokenů a hesel. GitHub ve své statistice secret scanningu sám hlásí miliony detekovaných tajemství ročně. Doba mezi okamžikem, kdy se klíč objeví ve veřejném repu, a okamžikem zneužití se měří v minutách.
„Tenhle typ chyby vývojáři dělávali ručně už dvacet let,“ říká Michal. „Naučili jsme se ji hlídat při code review. AI ale generuje rychleji, než člověk čte. A rychlé review nestihne všechno.“
Smlouva, která myslela na dny
Strukturní problém leží v ekonomice vztahu mezi agenturou a klientem. Drtivá většina smluv stále počítá s časovými horizonty z let, kdy útoky zrály týdny, a popisuje jednorázové předání hotového webu. Bezpečnost se mezitím stala každodenním provozem. Smlouva napsaná pro jednorázovou akci ten provoz neufinancuje ani nepokryje.
Michal popisuje vzorec, který u nově příchozích klientů vidíme opakovaně. Web spuštěný před třemi až šesti měsíci. Funguje, klient je spokojený, dodavatel projekt uzavřel. Od té doby žádná aktualizace, protože nebyla ve smlouvě, nebyla v rozpočtu, nikdo s ní nepřišel. Mezitím framework dostal dvě bezpečnostní aktualizace a ani jedna se nedostala do produkce.
„Útočníci si tech stack webů skenují automaticky. Vidí verzi WordPressu, Laravelu, Drupalu, Nette. Vědí, které verze mají známé díry. Pro ně jde o plně automatizovaný proces.“ Když projdou, scénář bývá podobný: získají přístup, eskalují práva a server začnou používat na rozesílání spamu, těžbu kryptoměn nebo jako odrazový můstek na další cíle.
Sucuri ve své zprávě o napadených webech dlouhodobě uvádí WordPress jako nejčastěji zastoupený systém mezi kompromitovanými instalacemi. Aktualizace jádra přitom vycházejí pravidelně. Do produkce se ale u velké části napadených webů nikdy nedostanou.
NÚKIB ve zprávě o stavu kybernetické bezpečnosti za rok 2024 opakovaně upozorňuje, že malé a střední firmy se stávají vstupními body do dodavatelských řetězců větších cílů. Tlak navíc poroste s evropskou směrnicí NIS2, kterou Česko přenáší do nového zákona o kybernetické bezpečnosti. Směrnice výrazně rozšiřuje okruh regulovaných subjektů, klade důraz na bezpečnost dodavatelského řetězce a poprvé činí za kybernetickou bezpečnost přímo odpovědné vrcholové vedení firmy. Nároky tak dopadnou i na řadu firem, které se dosud považovaly za příliš malé. Zanedbaný firemní web bývá primárním cílem málokdy. Skvělým odrazovým můstkem pro útok jinam být může.
„‚Máme web a tím to končí’ přestalo platit asi před třemi lety,“ shrnuje Michal. „Web bez aktualizačního plánu je dnes otevřená bezpečnostní díra.“
Vrstvy místo zdi
Strukturní odpověď na zrychlení útoku stojí na více nezávislých obranách, které běží současně. Model, na který Michal odkazuje, je starý desítky let. Britský psycholog James Reason ho shrnul v roce 2000 v British Medical Journal při analýze nehod a v Česku zlidověl během covidu jako „ementál“.
Princip: žádná jednotlivá vrstva obrany nemá nula děr. Záleží na tom, aby se díry nepřekrývaly.
V kontextu vývojového a provozního pipeline to znamená sérii nezávislých kontrol:
- Pre-commit hook, který odmítne klíč v souboru.
- Skenování závislostí proti CVE databázím při každém buildu.
- Automatický deploy záplat na úrovni infrastruktury v řádu hodin od zveřejnění.
- WAF, který blokuje známé útočné vzory.
- Monitoring, který zaznamená neobvyklou aktivitu.
- Redundantní infrastruktura, která umožní přepnout na záložní instanci, než se záplatuje produkce.
„Žádná z těch vrstev není stoprocentní,“ říká Michal. „Společně fungují. Penetrační test jednou za rok tohle nevyřeší. Vrstvy musí běžet průběžně, automaticky, bez ohledu na to, jestli si někdo vzpomněl.“
Logika odpovídá tomu, co NIST ve svém Cybersecurity Frameworku 2.0 popisuje jako přechod od bodové ochrany ke kontinuálnímu řízení rizika. Bezpečnost přestala být stavem, kterého se jednou dosáhne. Stala se provozem, který běží každý den.
Klient jako chybějící vrstva
Tady se dostáváme k tomu, co Michal považuje za nejvíc podceněnou změnu. Klient přestal být jen odběratel a stal se součástí obranné struktury. Ať to ví, nebo ne.
„Klient, který má web bez aktualizačního plánu, bez SLA na záplatování, bez rozpočtu na security a předpokládá, že to agentura nějak řeší sama, vytváří v obraně slabé místo. Popisuji realitu, která se mění každý měsíc. Musí vědět, že firewall existuje a kdo ho má spravovat. Konfigurovat ho umět nemusí.“
Praktický důsledek pro stranu klienta leží podle Michala ve čtyřech bodech, a žádný z nich není technický.
Čtyři věci, které byste si jako klient měli ohlídat:
✔ Vyžádejte si SLA na aktualizace a záplatování. Explicitně, s definovanou dobou reakce na kritickou CVE.
✔ Počítejte s bezpečností v rozpočtu jako se standardní provozní položkou. U byznysově kritických aplikací se roční náklad na údržbu, průběžný vývoj a bezpečnost dohromady pohybuje typicky mezi 30 a 50 procenty ceny vývoje. U běžného firemního webu je výrazně nižší.
✔ Ptejte se dodavatele na verze. Na jaké verzi frameworků web běží a kdy byl naposledy aktualizovaný. Nejasná odpověď je odpověď.
✔ Projděte si základní security briefing s týmem, který se webu dotýká. Stačí porozumění, proč 2FA neobtěžuje a proč se hesla neposílají ve Slacku.
Check Point ve své zprávě uvádí, že organizace dnes čelí v průměru bezmála dvěma tisícům pokusů o útok týdně a že Evropa roste meziročně nejrychleji ze všech regionů, o 22 procent. Při téhle frekvenci je každý firemní web pod automatickým tlakem bez ohledu na velikost majitele.
Smlouvy musí dohnat technologii
Michal nakonec posune perspektivu z technické na obchodní. Skutečný předěl leží podle něj v tom, jak se dá bezpečnost zaplatit a smluvně ukotvit.
„Bezpečnostní hardening, tedy práce, kterou musíme udělat při každém projektu, se za poslední dva roky výrazně zvětšil. Dřív šlo o standardní předání. Dnes je to povinná průběžná součást, která projekt natahuje. Protože není vidět, těžko se pro ni hledá prostor v rozpočtu. Tohle musíme řešit společně s klientem, jako součást zadání.“
Bezpečnost se v jeho podání přesouvá z kolonky „jednorázová položka při předání“ do kolonky „provozní náklad, který běží, dokud web žije“. Kdo to ve smlouvě neudrží, doplatí na to později u forenzní analýzy.
Když chcete konkrétní číslo, Michal ho má. Webových projektů spuštěných s explicitním provozním rozpočtem na security je v našem portfoliu zhruba třetina. Další třetinu tvoří weby, které se k nám dostaly až po incidentu. Zbytek jsou klienti, kteří přicházejí preventivně, většinou potom, co se něco stalo někomu v jejich oboru.
„Ten poměr se posouvá ve prospěch první kategorie. Pomalu, ale posouvá. Když se pohne o dalších deset procent, budeme to považovat za úspěch celého oboru.“
Pokud si nejste jistí, kdy byl váš firemní web naposledy aktualizovaný, nebo nevíte, jestli vaše SLA řeší kritické CVE, je to dobrá první otázka pro vašeho dodavatele. Patnáctiminutový hovor stojí výrazně méně než hodina forenzní analýzy. Rádi vám ho dáme.
