Minulý týden zveřejnila bezpečnostní firma CloudSEK rozbor útoku, který proběhl už v březnu. Nový je až rozsah: potenciálně zasáhl přes 2 500 organizací a zhruba 434 000 CI/CD pipelines. V seznamu jsou firmy jako Cisco, Siemens, Volkswagen, Airbus, Deloitte, Deutsche Bahn, Thales, Munich Re, Bosch nebo Vodafone.

Zajímavější než ta čísla je ale způsob, jakým se to stalo. Ani jedna z těch firem nebyla napadena přímo. A napadena nebyla ani knihovna, přes kterou se to k nim dostalo.

Co se stalo

Terčem byla knihovna LiteLLM, opne-source nástroj pro práci s různými modely umělé inteligence přes jednotné rozhraní. Používá se často, protože firmám umožňuje přepínat mezi poskytovateli bez přepisování aplikace.

LiteLLM ale nikdo nenapadl. Řetěz byl delší.

Krok první. Skupina označovaná jako TeamPCP se dostala k automatizačnímu tokenu bezpečnostního skeneru Trivy. Token unikl a byl sice rotován, ale ne zcela zneplatněn. Vznikl tak zhruba dvacetidenní prostor, ve kterém útočník přepsal už zveřejněné tagy skeneru vlastním kódem. Kdo si stáhl tu verzi, dostal škodlivý kód, který navenek vypadal legitimně.

Krok druhý. CI/CD pipeline LiteLLM si Trivy instalovala automaticky přes systémového správce balíčků, bez připnuté verze. Kompromitovaný skener tedy do buildu natekl sám od sebe.

Krok třetí. Ten build vyrobil a do repozitáře PyPI publikoval škodlivé verze aplikace 1.82.7 a 1.82.8.

Jeden nezneplatněný token, tři nástroje hluboko v dodavatelském řetězci. To je celý příběh.

Proč čtyřicet minut stačilo

Škodlivé balíčky byly na PyPI dostupné zhruba čtyřicet minut. To zní jako málo. Není.

Automatizované build systémy nespí a nečekají. Během těch čtyřiceti minut si balíček stáhly naplánované joby, ephemeral runnery, vývojářské notebooky a cache. Odtud se šířil dál i po odstranění z repozitáře.

Škodlivý kód navíc obcházel běžnou ochranu. Nepoužíval instalační skripty, které se dají vypnout přepínačem --ignore-scripts, ale soubor typu .pth. Ten se spouští při startu interpretu Pythonu, ne až při importu knihovny. Stačilo tedy, aby byl balíček nainstalovaný. Nikdo ho nemusel použít.

Co odteklo ven

Škodlivá část si zvýšila oprávnění na root a posbírala všechno, k čemu měl daný proces přístup:

U většiny z toho nebyl potřeba žádný exploit. Stačilo využít přístup, který dané prostředí už mělo.

Sesbíraná data odcházela na doménu s překlepem v názvu. A když odesílání selhalo, škodlivý kód založil veřejný repozitář uvnitř GitHub účtu samotné oběti a nahrál ukradená data tam. Některé organizace tak zveřejňovaly vlastní přístupové údaje, aniž by o tom věděly.

Odstranění balíčku incident neřeší

Tohle je nejdůležitější věta celého případu.

Balíček zmizel z repozitáře za čtyřicet minut. Ukradené přístupové údaje ale zůstaly použitelné dál. FBI vydala 2. července 2026 varování (FLASH-20260702-01), že spřízněné skupiny pravděpodobně budou získané údaje zneužívat ještě dlouho po původním průniku.

Firma Sophos navíc téhož dne popsala, že TeamPCP spolupracuje s ransomwarovou skupinou. Ukradené přístupy se tedy nemusí zneužít hned a nemusí je zneužít ten, kdo je ukradl.

Prakticky to znamená, že rotace jednoho klíče nestačí. Rotovat je potřeba všechno, k čemu měl zasažený proces přístup — cloud, repozitáře, registry, clustery, databáze, SaaS i modely.

Není to ojedinělý případ

Bylo by pohodlné brát tohle jako exotickou nehodu. Není.

Stejná kampaň zneužila kromě Trivy i nástroj Checkmarx KICS. Dva ze tří vstupních bodů byly tedy bezpečnostní nástroje. V seznamu potenciálně zasažených organizací je i Zscaler, tedy bezpečnostní dodavatel.

Vzorec se opakuje delší dobu. SolarWinds, Kaseya, 3CX, útoky na balíčky v npm a PyPI. Mění se jen to, že cílem už nejsou jen nástroje pro správu, ale i nástroje, které mají bezpečnost zajišťovat, a nově infrastruktura kolem umělé inteligence.

Důvod je logický. AI gateways, běhová prostředí agentů a MCP servery drží přístupové údaje k modelům, databázím, cloudovým službám i interním nástrojům naráz. Kdo se dostane sem, nemusí lovit systémy po jednom.

Proč se dodavatelský řetězec musí řešit

Zásadní posun je v tom, komu vlastně důvěřujete.

Nedůvěřujete jen svým dodavatelům. Důvěřujete dodavatelům svých dodavatelů. LiteLLM si vybralo Trivy, vy jste si vybrali LiteLLM. O tom prvním rozhodnutí jste nevěděli a nemohli ho ovlivnit.

K tomu se přidávají tři věci, které to zhoršují:

Automatizace zesiluje krátkou chybu. Ruční instalace by kompromitovaný balíček zachytila v jednotkách případů. CI/CD pipeline ho rozešle napříč firmou během minut.

Build prostředí má široká oprávnění. Aby mohlo nasazovat, musí mít přístup k produkci. Kdo ovládne build, nepotřebuje se dobývat do produkce zvlášť.

Chybí přehled. Většina firem neumí odpovědět na otázku, jestli měla někdy nainstalovanou konkrétní verzi konkrétní knihovny. Bez té odpovědi nelze incident ani vyhodnotit.

Co s tím říká CRA

Tady se to potkává s regulací, a docela přesně.

Od 11. září 2026 musí výrobci produktů s digitálními prvky hlásit aktivně zneužívané zranitelnosti do 24 hodin. Kdyby se takový případ stal vám a vy jste ho zabudovali do svého produktu, hlásíte ho vy. Podrobnosti jsme rozebrali v článku o hlášení podle CRA.

Od 11. prosince 2027 přibude povinnost vést SBOM (Software Bill of Materials), tedy strojově čitelný seznam všech komponent produktu. Není to papírování pro auditory. Je to přesně ta věc, která u tohoto incidentu odpovídá na otázku „měli jsme někdy 1.82.7?“ za pár minut místo za týden.

CRA k tomu vyžaduje náležitou péči při použití komponent třetích stran. Jinými slovy: zákon říká, že výběr závislostí je vaše odpovědnost, i když ten kód nepíšete vy.

Co dělat prakticky

Konkrétní opatření, seřazená podle poměru přínosu a námahy.

Uzamkněte verze. Závislosti i akce v CI/CD pipeline odkazujte na konkrétní commit hash, ne pouze na tag. Tag může vlastník repozitáře později přesunout na jinou verzi kódu, zatímco konkrétní commit hash jednoznačně odkazuje na daný obsah. Tím výrazně omezíte riziko, že se do vašeho buildu automaticky dostane podvržená nebo kompromitovaná verze.

Zkraťte životnost přístupových údajů. Statické klíče nahraďte workload identity s krátkou platností. Ukradený údaj, který platí patnáct minut, má výrazně menší cenu.

Zužte oprávnění buildu. Build job nepotřebuje přístup ke všem cloudovým účtům. Oddělte prostředí a omezte, co který krok vidí.

Veďte seznam komponent. SBOM začněte generovat automaticky v rámci buildu. Nástroje jako Syft nebo cdxgen to zvládnou, formáty SPDX a CycloneDX jsou standardem.

Sledujte chování build prostředí. Neobvyklý odchozí provoz z runneru je signál, který jde zachytit. U tohoto případu by ho odhalil.

Rotujte podle dosahu, ne podle důkazu. Pokud nemáte jistotu, co všechno bylo dostupné, rotujte široce. Cena rotace je téměř vždy nižší než cena odloženého zásahu.

Ptejte se dodavatelů. Jak řídí své vlastní závislosti? Připínají verze? Mají SBOM? Jak by vás informovali, kdyby se něco takového stalo jim? U klíčových dodavatelů to patří do smlouvy.

Co si z toho odnést

Bezpečnost vlastního kódu je dnes menší část problému. Většina toho, co ve firmě běží, jste nenapsali a nikdy neuvidíte. Bezpečný vývoj proto není jen o tom, jak píšete kód, ale hlavně o tom, co do něj pouštíte a s jakými právy to běží.

To je přesně obsah toho, čemu se říká DevSecOps, a taky důvod, proč to CRA po výrobcích bude vyžadovat. Víc jsme o tom psali v článku Security by Design.

A pokud si z toho případu odnesete jen jednu věc, ať je to tahle: bezpečnostní nástroj není automaticky důvěryhodný jen proto, že je bezpečnostní.

Jak vám s tím pomůžeme

Dodavatelský řetězec je nepříjemný v tom, že se nedá vyřešit jedním opatřením ani jedním oddělením. Zasahuje do architektury, do vývoje, do nákupu, do smluv i do compliance. Firmy proto obvykle nevědí, kdo za to má odpovídat, a téma se odkládá, dokud se něco nestane.

Tohle je přesně ten typ průřezového problému, na který jsme postavení.

Zjistíme, jak na tom jste. Revize architektury a posouzení CI/CD pipeline. Kde běží buildy, jaká mají oprávnění, co se do nich instaluje bez pinnuté verze, kde jsou statické klíče a kdo je má. Výstupem není seznam nálezů, ale plán, který má pořadí. → Security Assessment

Nastavíme řízení dodavatelů. Kategorizace podle rizika, bezpečnostní požadavky do smluv, hodnocení klíčových dodavatelů a pravidelný přezkum. Včetně otázek, které jim máte položit, a toho, co si nechat doložit. → Security Technologies

Dostaneme rizika z Excelu. Evidence rizik a dodavatelů s vlastníky, opatřeními a termíny, s reportingem pro vedení. Sedm dní na vyzkoušení zdarma. → Observa

Připravíme vás na CRA. Posouzení, jestli jste výrobcem podle nařízení, zavedení generování SBOM, proces hlášení do 24 hodin a veřejný kanál pro příjem zranitelností. Termín 11. září je za rohem. → Compliance a ZKB/NIS2/DORA

Převezmeme řízení, když na to nemáte lidi. Externí manažer kybernetické bezpečnosti, který tuhle agendu vede dlouhodobě a nese za ni odpovědnost. Bez nutnosti shánět seniorního člověka na trhu, kde není. → vCISO a Security Leadership

A když už se to stalo. Vyhodnocení rozsahu, prioritizace rotace přístupových údajů, forenzní podpora a komunikace s regulátorem. → Pomoc při incidentu

Velké firmy vám na tohle pošlou dvousetstránkovou zprávu. My s vámi projdeme každý řádek a zůstaneme, dokud to není vyřešené.

Nezávazná konzultace →

Řekneme vám na rovinu, co má smysl řešit jako první a co může počkat. Bezplatně, bez závazků, odpověď do 24 hodin.