Když se balíček stane vstupní branou

Útoky na softwarové balíčky se za poslední měsíce posunuly. Už nejde jen o škodlivou knihovnu někde ve stromu závislostí. Stále častěji jde o zneužití důvěry v celý distribuční řetězec: registry balíčků, Docker obrazy, GitHub Actions, Jenkins pluginy, rozšíření vývojového prostředí a bezpečnostní nástroje.

Společný cíl je přitom jednoduchý. Dostat kód do prostředí, kde jsou dostupné tokeny, SSH klíče, cloudové přístupové údaje, přístupy do registrů nebo Kubernetes konfigurace. Tedy přesně tam, kde se dnes staví a provozuje infrastruktura.

Pro firmy, které používají open source, kontejnery, CI/CD a cloud, je to důležitá změna uvažování. Balíček už není jen závislost aplikace. V okamžiku instalace, sestavení nebo nasazení se z něj stává součást bezpečnostního perimetru.

Poslední vlna: květen 2026

Nejviditelnější květnový případ je kampaň označovaná jako Mini Shai-Hulud. Podle zpráv Wiz, The Hacker News, Hackread a dalších bezpečnostních týmů zasáhla 11. a 12. května 2026 balíčky v npm a PyPI napříč několika ekosystémy. Mezi uváděnými cíli byly TanStack, UiPath, Mistral AI, OpenSearch a Guardrails AI.

Rozsah nebyl malý. Ve veřejných analýzách se objevují čísla přes 170 zasažených balíčků a stovky škodlivých verzí. U části balíčků šlo o známé projekty používané při vývoji webových aplikací, automatizaci, AI integracích nebo práci s vyhledáváním.

Zajímavější než samotný počet je ale mechanismus.

U TanStacku útočníci podle rozborů incidentu nezískali klasický npm token. Zneužili řetězec v GitHub Actions: pull_request_target, otrávenou cache a OIDC token z běžícího runneru. Škodlivé verze tak mohly být publikovány přes legitimní proces vydání. Výzkumníci navíc upozornili, že část balíčků nesla platnou informaci o původu v rámci SLSA. To je nepříjemný detail: mechanismus určený k ověření původu balíčku může potvrdit, že balíček prošel oficiální pipeline, ale ne že tato pipeline nebyla zneužita.

U PyPI variant se objevily například balíčky mistralai==2.4.6 a guardrails-ai==0.10.1. Ty podle analýz stahovaly další škodlivou komponentu z domény git-tanstack[.]com a spouštěly nástroj pro krádež přístupových údajů. Cílem byly opět cloudové přístupy, GitHub tokeny, tokeny do registrů, servisní účty Kubernetes, Vault a další tajné údaje dostupné v prostředí.

Kampaň měla i další nepříjemnou vlastnost: několik nezávislých cest pro odliv dat. Analýzy popisují kombinaci podvržené domény, decentralizované sítě Session a úložišť vytvářených přes GitHub API. Prakticky to znamená, že nestačí spoléhat na zablokování jedné cílové adresy.

Checkmarx: když je zasažený bezpečnostní nástroj

Druhý květnový příklad ukazuje jiný problém. Checkmarx ve svých průběžných aktualizacích zmiňuje škodlivou verzi Checkmarx Jenkins AST pluginu, publikovanou na Jenkins Marketplace 9. května 2026. Podle zveřejněné aktualizace k incidentu bylo zasažené okno od 9. května 01:25 UTC do 10. května 08:47 UTC.

Checkmarx už předtím řešil širší incident v dodavatelském řetězci, který se dotkl mimo jiné KICS Docker obrazů, GitHub Action a rozšíření pro VS Code/Open VSX. U podobných nástrojů je dopad potenciálně větší než u běžné aplikační knihovny. Bezpečnostní skener nebo CI plugin často vidí repozitáře, logy ze sestavení, proměnné prostředí, konfigurace infrastruktury a někdy i přístupové údaje pro nasazení.

Jinými slovy: nástroj, který má pomáhat hledat chyby v infrastruktuře, se při kompromitaci může stát cestou k jejím tajemstvím.

Březen a duben nebyly výjimka

Květen navázal na sérii předchozích incidentů.

U LiteLLM byly v březnu 2026 publikovány kompromitované verze 1.82.7 a 1.82.8 na PyPI. Projekt ve svém bezpečnostním oznámení uváděl, že škodlivý kód cílil na proměnné prostředí, SSH klíče, cloudové přístupové údaje, Kubernetes tokeny a databázová hesla. Zvlášť důležitý byl detail kolem .pth souboru v Python site-packages, který se může spouštět automaticky při startu interpreteru i bez explicitního importu knihovny.

U Xinference byly podle OX Security zasaženy PyPI verze 2.6.0, 2.6.1 a 2.6.2. Škodlivý kód se spouštěl při importu a sbíral mimo jiné AWS, GCP a Kubernetes konfigurace, SSH klíče, API tajemství, databázové přístupy, historii shellu, SSL certifikáty a v některých případech i data z kryptoměnových peněženek.

V npm ekosystému se objevil CanisterSprawl, útok na balíček pgserve. Škodlivé verze používaly postinstall skript, hledaly publikační tokeny a při vhodných podmínkách se pokoušely šířit dál přes balíčky, ke kterým měl napadený uživatel právo publikovat. Zmíněné bylo i použití decentralizované infrastruktury jako řídicího kanálu C2.

Tyto příklady se liší jazykem, registrem i technickým detailem. Přesto mají stejný vzorec: balíček se spustí v důvěryhodném prostředí a z něj vytáhne tajné údaje.

Proč je problém hlavně v oprávněních

U útoků na dodavatelský řetězec se často ptáme: „Používali jsme zasaženou verzi?“ To je správná otázka, ale nestačí.

Důležitější je druhá otázka: „K čemu měl proces v daném okamžiku přístup?“

Pokud se škodlivý balíček spustí v izolovaném testu bez tajných údajů a bez odchozího přístupu do internetu, dopad může být omezený. Pokud se spustí v úloze CI, která má dlouhodobý cloudový klíč, GitHub token, npm publikační token a přístup k produkčnímu Kubernetes clusteru, mluvíme o úplně jiném incidentu.

Stejně to platí pro vývojářské stanice. Notebook vývojáře často obsahuje SSH klíče, .env soubory, přihlášení do cloudového CLI, kubeconfig, tokeny do registrů a historii příkazů. Kompromitovaný balíček proto nemusí útočit na produkci přímo. Stačí mu vybrat data z prostředí, které produkci spravuje.

Co z toho plyne pro provoz infrastruktury

Open source není problém. Problém je neřízená důvěra.

Open-source infrastruktura dává firmám kontrolu, transparentnost a menší závislost na dodavatelích. Jenže bez provozních pravidel se z ní snadno stane směs nástrojů, které mají příliš mnoho oprávnění a příliš málo dohledu.

Z pohledu infrastruktury je potřeba řešit hlavně šest oblastí.

1. Pinovat verze, digesty a odkazy na workflow

Nepinované závislosti a neukotvené tagy typu latest zvětšují riziko, že sestavení stáhne škodlivou verzi během krátkého okna kompromitace. U kritických komponent má smysl pinovat konkrétní verze, Docker digesty a reference GitHub Actions.

Netýká se to jen aplikačních knihoven. Stejnou pozornost si zaslouží CI/CD pluginy, skenery, základní obrazy, rozšíření vývojového prostředí a interní nástroje.

2. Omezit oprávnění úloh v CI/CD

Úloha pro sestavení nemá mít automaticky přístup k produkčním tajným údajům. Testovací pipeline nepotřebuje právo nasazovat. Skener, který čte repozitář, nemusí mít možnost měnit cloudovou infrastrukturu.

Princip nejmenších oprávnění je známý, ale v CI/CD se často obchází kvůli pohodlí. Právě útoky na dodavatelský řetězec ukazují, proč se to nevyplácí.

3. Nahradit dlouhodobé klíče krátkodobými identitami

Statické klíče uložené v CI/CD proměnných nebo na vývojářských strojích jsou pro nástroje kradoucí přístupové údaje ideální cíl. Kde to jde, je lepší používat krátkodobé tokeny, OIDC federaci, workload identity a dynamicky vydávané tajné údaje.

Krátká životnost přístupu incident nezastaví. Výrazně ale zmenší časové okno, ve kterém je ukradený klíč použitelný.

4. Sledovat odchozí provoz ze sestavovacího prostředí

Mnoho incidentů končí odesláním dat na externí cílový server. Pokud CI runner může komunikovat kamkoliv, detekce je složitější. Dává smysl logovat DNS a HTTP požadavky z CI/CD, sledovat neobvyklé cíle a u citlivých pipeline omezovat odchozí provoz jen na potřebné služby.

Observabilita není jen o výkonu aplikace. V moderní infrastruktuře je součástí bezpečnosti.

5. Vědět, kde se balíček opravdu spustil

Při incidentu nestačí otevřít strom závislostí. Potřebujete odpovědět na provozní otázky:

• Byla zasažená verze v lockfile?
• Stáhla se během sestavení Docker obrazu?
• Běžela v GitHub Actions, GitLabu, Jenkinsu nebo lokálně?
• Jaké tajné údaje byly v dané úloze dostupné?
• Máme logy, které to zpětně prokážou?

To vyžaduje kombinaci lockfile disciplíny, SBOM, auditních logů, centralizované správy logů a čitelné CI/CD architektury.

6. Mít připravenou rotaci tajných údajů

U kompromitovaného balíčku se často rychle dostanete k nepříjemné otázce: co všechno musíme zneplatnit a vydat znovu?

Pokud firma neví, kde jsou klíče uložené, kdo je vlastní a jak se nahrazují, reakce na incident se mění v improvizaci. U kritických tajných údajů by měl existovat postup: najít, vypnout, vygenerovat nové, nasadit, ověřit, že staré už nefungují.

Praktický test pro vlastní prostředí

Jednoduchá kontrolní otázka zní:

Co se stane, když se dnes v naší pipeline spustí škodlivý postinstall skript?

Dobrá odpověď by měla obsahovat konkrétní limity:

• běží v izolovaném runneru,
• nemá produkční přístupové údaje,
• má omezený odchozí provoz,
• používá krátkodobé tokeny,
• instalované verze jsou dohledatelné,
• logy umožní zpětně zjistit, kde se kód spustil,
• rotace tajných údajů má vlastní postup.

Pokud odpověď zní „nevím“, není to selhání. Je to dobrý začátek hardeningu.

Bezpečnost jako day-2 provoz

Incidenty v dodavatelském řetězci nejsou jednorázová chyba, kterou vyřeší jeden audit. Jsou to provozní události. Týkají se toho, jak se denně aktualizují závislosti, jak běží sestavení, kdo má právo publikovat balíčky, kde leží tajné údaje a jak rychle se dají zneplatnit.

Proto patří do stejné kategorie jako monitoring, správa logů, hardening a správa infrastruktury. Ne jako papírové cvičení, ale jako průběžný provozní proces.

Cílem není přestat používat open source ani zastavit automatizaci. Cílem je mít infrastrukturu, která je čitelná, omezuje rozsah dopadu a dává týmu dostatek dat pro rychlou reakci.

Jinými slovy: open source a CI/CD zůstávají správná cesta. Jen už se nedají provozovat jako sada důvěryhodných černých skříněk.

Závěr

Květnové útoky na npm, PyPI a nástroje CI/CD ukazují, že důvěryhodný proces vydání se může stát distribučním mechanismem útočníka.

Otázka tedy nezní jen: „Máme zranitelný balíček?“

Lepší otázka je: „Pokud se nám v sestavení, skeneru nebo na vývojářském stroji spustí škodlivý kód, k čemu všemu se dostane?“

Právě odpověď na tuto otázku rozhoduje o skutečném dopadu incidentu.