Pošlete první prohlášení (holding statement) během několika hodin, potvrzenou odpověď, jakmile ji dokážete doložit, a následnou aktualizaci pokaždé, když se něco změní. Řekněte, co víte, co ještě ověřujete a kdy pošlete aktualizaci. Každé „netýká se nás“ opírejte o to, co vaše buildy během okna útoku skutečně nainstalovaly, ne o dnešní lockfile.
Tento článek je o tom, co říct, kdy a čím to podložit. Samotné šetření, tedy jak zjistit, zda je zranitelná komponenta ve vašich produktech a odkdy, popisuje článek týká se nás tato CVE?.
Proč se zákazníci ptají vás, a ne registru balíčků
Týden po široce medializovaném útoku, jak nám řekl majitel malé softwarové firmy, mu klienti posílali textové zprávy: je váš software bezpečný? Je můj systém v bezpečí? Jeho zákazníci pracují s citlivými daty, jeho tým nemá bezpečnostního specialistu a otázka potřebovala odpověď ještě ten den.
Zákazníci se neptají, zda byl balíček kompromitován. To už řekl registr i výzkumníci. Ptají se, zda to obsahuje to, co jste jim dodali, protože váš produkt je jejich expozice. Na stejnou otázku se jich ptají jejich vlastní zákazníci, auditoři nebo regulátoři. V regulovaných dodavatelských řetězcích, jako jsou polovodiče, průmyslová zařízení a zdravotnictví, jde o smluvní otázku, ne o zvědavost.
A zeptají se znovu, pokud vaši odpověď nelze ověřit. „Netýká se nás“ bez čehokoli v pozadí je slib; „zkontrolovali jsme každý build vydání od 24. do 31. března a žádný z nich zasažené verze nenainstaloval“ je tvrzení, na které se mohou spolehnout.
Čtyři nedávné útoky a otázka, kterou každý z nich vyvolal
Správná odpověď závisí na tom, jak útok fungoval, takže samotná šablona nestačí. U každého z nich rozhoduje jeden fakt o tom, co pro dodavatele znamená „zasaženo“.
Backdoor v xz Utils (CVE-2024-3094), zveřejněný 29. března 2024. Andres Freund objevil backdoor ve verzích xz 5.6.0 a 5.6.1. Archivy vydání obsahovaly kód, který nebyl v repozitáři Git, a ten backdoor vložil během buildu. NVD i Red Hat ho hodnotí podle CVSS 3.1 skóre 10,0. Zasáhl hlavně průběžně aktualizované a testovací distribuce: Debian testing, unstable a experimental, Fedora Rawhide a 41, openSUSE Tumbleweed a Kali, zatímco stabilní vydání zasažena nebyla. Otázka, kterou vyvolal: obsahuje nějaký image nebo zařízení, které jsme dodali, xz 5.6.0 nebo 5.6.1, a jaký základní image každý build použil?
Červ Shai-Hulud na npm, ve vlnách od září 2025. Infikované balíčky při instalaci spustí skript, který ukradne přihlašovací údaje k npm, GitHubu a cloudu a použije je k publikování infikovaných verzí dalších balíčků. Otázka, kterou vyvolal: nainstaloval nějaký job CI infikovanou verzi a byly vystaveny naše tokeny pro publikování, čímž bychom se sami stali šiřitelem? Náš záznam o Shai-Hulud uvádí každou vlnu a jak ji zkontrolovat.
LiteLLM na PyPI, 24. března 2026. Verze 1.82.7 a 1.82.8 byly nahrány přímo na PyPI s kódem pro krádež přihlašovacích údajů, který nikdy nebyl v repozitáři projektu na GitHubu. Ve verzi 1.82.8 spouštěl soubor .pth škodlivý kód při každém spuštění jakéhokoli interpretu Pythonu, nejen při importu LiteLLM; sbíral proměnné prostředí, klíče SSH, přihlašovací údaje ke cloudu a tajné klíče Kubernetes. HiddenLayer spojuje útok se skupinou TeamPCP, která ten měsíc zasáhla také nástroje Trivy a Checkmarx. Vlastní bezpečnostní upozornění LiteLLM uvádí dvě vysvětlení počátečního přístupu: kompromitaci vystopuje k závislosti Trivy ve svém workflow pro bezpečnostní skenování v CI a zároveň uvádí, že mohl být kompromitován účet správce na PyPI. Dokonce i okno expozice se v tomto upozornění liší, na jednom místě asi 40 minut, na jiném 10:39 až 16:00 UTC. Otázka, kterou vyvolal: obsahoval build nebo dodaný kontejner tyto verze a jaké tajné klíče byly v tom prostředí k dispozici?
axios na npm, 31. března 2026. Útočník převzal účet správce na npm a publikoval axios 1.14.1 a 0.30.4, které přidaly závislost [email protected], jejíž instalační skript nasadil trojského koně pro vzdálený přístup pro macOS, Windows a Linux. Datadog uvádí okno od 00:21 do 03:25 UTC; podle Snyku byly verze odstraněny v 03:29 UTC. Otázka, kterou vyvolal: vyřešil nějaký build v tomto okně tyto verze? Lockfile commitnutý před oknem odpovídá „ne“ pro buildy, které ho použily, a neříká nic o buildech, které spustily npm install bez něj.
| Útok | Ekosystém | Zasažené verze | Okno | Co pro dodavatele znamená „zasaženo“ |
|---|---|---|---|---|
| xz Utils | Distribuce Linuxu | 5.6.0, 5.6.1 | Týdny, až do zveřejnění 29. března 2024 | Dodali jste ho v image nebo zařízení postaveném na zasažené distribuci |
| Shai-Hulud | npm | Stovky balíčků v každé vlně | Hodiny až dny v každé vlně | Sestavovali jste s ním a vaše tokeny ho mohly šířit; mohli jste ho i dodat |
| LiteLLM | PyPI | 1.82.7, 1.82.8 | 24. března 2026, od 10:39 UTC (zdroje se liší v konci) | Sestavovali jste s ním nebo jste ho dodali a tajné klíče v prostředí mohly být ukradeny |
| axios | npm | 1.14.1, 0.30.4 | 31. března 2026, zhruba od 00:21 do 03:25 UTC | Sestavovali jste s ním během okna; trojský kůň běžel na stroji buildu |
Stejné otázky se objevují i u kritické zranitelnosti, která není útokem na dodavatelský řetězec. Když byla v říjnu 2026 zneužívána zranitelnost PHP2Shell, zákazníci každého produktu, který dodává PHP, se ptali, které z jejich verzí obsahují zasažené PHP. Níže uvedené kroky platí beze změny.
Odpověď má tři fáze
| Fáze | Kdy | Co posíláte |
|---|---|---|
| První prohlášení | Během několika hodin od zprávy | Co víte, co ověřujete, kdy pošlete aktualizaci |
| Potvrzená odpověď | Jakmile ji dokážete doložit, obvykle první den | „Netýká se nás“ pro jmenované verze, nebo „zasaženo“ s pokyny |
| Následná aktualizace | Když vyjde oprava, když zjistíte něco nového, když případ uzavřete | Stejné oznámení, upravené |
První hodina: první prohlášení
První prohlášení je první veřejné vyjádření, které uděláte dřív, než máte k dispozici fakta. Řekněte něco pravdivého, a rychle. Ticho se vyplní domněnkami a zákazník, který od vás nic neslyší, předpokládá, že jste si ničeho nevšimli.
- Kdo a kde. Jeden jmenovaný odesílatel, v kanálu, který zákazník použil, plus vaše bezpečnostní stránka. Jeden sdílený text je lepší než improvizované odpovědi: zůstává konzistentní a právní oddělení ho zkontroluje jen jednou.
- Co obsahuje. Že o útoku víte, že kontrolujete své produkty a systémy pro build, co zatím víte, kdy přijde další aktualizace a na koho se obrátit.
- Co obsahovat nesmí. „Netýká se nás“ dřív, než jste to ověřili, spekulace o útočníkovi ani obviňování.
Šablona 1: první prohlášení
Předmět: [název útoku]: naše první prohlášení
Víme o hlášené kompromitaci [balíček nebo projekt] ([zasažené verze], publikováno [datum]). Náš bezpečnostní tým kontroluje každé vydání [produkt] a naše systémy pro build, zda neobsahují zasažené verze. Zatím jsme [ve zkontrolovaných produktech nenašli žádné zasažené verze / kontrolu ještě nedokončili]. Aktualizaci vám pošleme do [datum a čas, časové pásmo]. Pokud mezitím máte dotazy, obraťte se na [jméno, bezpečnostní kontaktní adresa]. Dokud kontrola neskončí, nebudeme o dopadu spekulovat.Pro textovou zprávu nebo chat stačí dvě věty:
O kompromitaci [název útoku] víme a právě kontrolujeme každé vydání [produkt] i naše buildy. Potvrzenou odpověď od nás dostanete do [čas].Nechte si všechny tři šablony schválit právníkem dřív, než je budete potřebovat.
První den: potvrďte, s důkazy
Možné jsou dva výsledky a každý potřebuje vlastní důkazy. Pro odpověď „netýká se nás“ shromážděte:
- zasažený balíček a verze, z bezpečnostního upozornění nebo z popisu od výzkumníků
- své produkty a verze, které zákazníci skutečně provozují
- pro každou z těchto verzí build, který ji vytvořil, a záznam toho, co tento build nainstaloval, ne aktuální lockfile
- každý build, který běžel během okna útoku, včetně jobů CI, které nikdy nevytvořily vydání
- u červů, kteří kradou tokeny, zda byly v jobech, které mohly spustit škodlivý kód, k dispozici nějaké tajné klíče CI
Jak každou z těchto věcí zjistit, vysvětluje článek týká se nás tato CVE?.
Každé vaše tvrzení musí být podložené něčím, co můžete ukázat:
| Tvrzení | Co musíte umět ukázat | Co nestačí |
|---|---|---|
| „Produkt X ve verzi Y neobsahuje balíček Z“ | SBOM zaznamenanou z buildu vydání verze Y | Sken aktuálního repozitáře |
| „Žádný z našich buildů nenainstaloval kompromitované verze“ | Záznamy o instalaci pro každý build v okně | Lockfile, který některé joby obcházejí |
| „Naše pipeline pro vydání nebyla kompromitována“ | Záznamy o síti a použití tajných klíčů za dané okno | To, že nepřišly žádné výstrahy |
| „Zákazníci na verzi Y jsou po upgradu v bezpečí“ | Záznam opraveného buildu a přihlašovací údaje, které jste vyměnili | Položka v changelogu |
Šablona 2: netýká se nás
Předmět: [název útoku]: [produkt] není zasažen
Dokončili jsme kontrolu kompromitace [balíček] ([zasažené verze]). Následující verze [produkt] nejsou zasaženy: [seznam zkontrolovaných produktů a verzí]. Zkontrolovali jsme každý build vydání a build CI, který běžel od [počáteční datum] do [koncové datum]. Toto prohlášení vychází ze záznamu komponent nainstalovaných každým buildem vydání, ne ze skenu našeho aktuálního zdrojového kódu. Žádný z těchto buildů zasažené verze nenainstaloval. Pokud potřebujete důkazy, můžeme vám poslat SBOM pro verze, které provozujete, nebo prohlášení VEX. Pokud zjistíme cokoli, co toto hodnocení mění, dáme vám vědět. Kontakt: [jméno, bezpečnostní kontaktní adresa].„Netýká se nás“ říkejte pro jmenované verze. Nikdy nepište „100% bezpečné“. Pokud zákazník poté požádá o úplnou SBOM, podívejte se, jak odpovídat na žádosti zákazníků o SBOM.
Šablona 3: zasaženo, s opatřeními
Předmět: [název útoku]: vyžadována akce pro [produkt] ve verzích [x až y]
Naše kontrola kompromitace [balíček] zjistila, že [produkt] ve verzích [x až y] je zasažen. První zasažený build vznikl [datum]; verze [z], vydaná [datum], už [verze balíčku] neobsahuje.
Co to znamená: [riziko srozumitelnou řečí, například „komponenta nainstalovaná v těchto verzích může odesílat přihlašovací údaje ze systému, na kterém běží, na externí server“].
Co dělat nyní: proveďte upgrade na [produkt] [z]. Pokud nemůžete upgradovat hned, [opatření, například zablokujte odchozí spojení na uvedené hostitele]. Pokud jste používali [produkt] ve verzích [x až y] v [prostředí], vyměňte [přihlašovací údaje nebo klíče], které k nim měly přístup.
Co jsme udělali: odstranili jsme zasažené verze z našich buildů, znovu sestavili [produkt] z čistých závislostí, vyměnili přihlašovací údaje, které používají naše systémy pro build, a [další kroky]. [Tam, kde je to vyžadováno, jsme informovali příslušné orgány.]
Další aktualizaci pošleme do [datum], nebo dříve, pokud se něco změní. Kontakt: [jméno, bezpečnostní kontaktní adresa].Oznámení „zasaženo“ může být i zákonnou povinností; viz sekci o podávání zpráv níže.
Kam patří VEX a CSAF. Prohlášení „netýká se nás“ nebo „opraveno“ lze zveřejnit jako VEX, aby skenery zákazníků přestaly balíček označovat. Větší zákazníci mohou očekávat i strojově čitelné bezpečnostní upozornění; CSAF je formát, který většina z nich požaduje.
Následná aktualizace: uzavřete to pořádně
Pošlete aktualizaci, když vyjde oprava, když vaše šetření zjistí něco nového, a závěrečnou zprávu, když případ uzavřete. Vedte jedno bezpečnostní upozornění na incident a upravujte ho, místo abyste pokaždé posílali nové (aktualizujte, nenahrazujte). Zaznamenejte, co jste komu a kdy řekli: příští audit nebo bezpečnostní dotazník zákazníka se na to zeptá.
Co říct, když ještě nevíte
„Zatím nevíme“ buduje víc důvěry než „netýká se nás“, které musíte odvolat. Formulace, které jsou upřímné a nikoho nepoplaší:
- „V [dosud zkontrolovaných produktech] jsme [balíček] nenašli. Stále kontrolujeme [zbývající produkty nebo systémy pro build] a aktualizaci vám pošleme do [čas].“
- „Verze, které provozujete, byly sestaveny před oknem útoku. Ověřujeme, že je žádný pozdější build nenahradil.“
- „Kontrolujeme, zda některý z našich systémů pro build spustil zasažené verze. Váš nainstalovaný produkt je samostatná otázka a odpovíme na obě.“
Formulace, kterým se vyhněte:
- „Žádný dopad“
- „Plně zabezpečeno“
- „Nezasaženo žádným útokem na dodavatelský řetězec“
- „Náš skener nic nenašel“
Když se z útoku stane povinnost podat zprávu
Pokud prodáváte produkty s digitálními prvky v EU, platí od 11. září 2026 povinnosti podávání zpráv podle Cyber Resilience Act, tedy ode dne, kdy ENISA spustila Single Reporting Platform (jednotnou platformu pro podávání zpráv). Aktivně zneužívaná zranitelnost ve vašem produktu nebo závažný incident s dopadem na jeho bezpečnost spouští včasné varování do 24 hodin od okamžiku, kdy se o nich dozvíte, oznámení do 72 hodin a závěrečnou zprávu, podané přes platformu vašemu týmu CSIRT určenému jako koordinátor a agentuře ENISA. Kroky popisuje průvodce CRA.
Zda kompromitovaná závislost, kterou jste dodali, nebo kompromitace vaší vlastní pipeline pro build splňuje tyto definice, musíte posoudit vy a váš právník, ne tento článek. Pojmy definuje nařízení:
- „Aktivně zneužívaná zranitelnost“ je „zranitelnost, u níž existují spolehlivé důkazy o tom, že ji škodlivý aktér v systému zneužil bez svolení vlastníka systému“ (článek 3, bod 42).
- Incident je závažný, pokud „negativně ovlivňuje nebo může negativně ovlivnit schopnost produktu s digitálními prvky chránit dostupnost, autenticitu, integritu nebo důvěrnost citlivých či důležitých dat nebo funkcí“, nebo pokud „vedl či může vést k zavedení nebo spuštění škodlivého kódu“ v produktu nebo v systémech uživatele (čl. 14 odst. 5).
Čl. 14 odst. 8 přidává povinnost vůči uživatelům: informovat zasažené uživatele, a případně všechny uživatele, o zranitelnosti nebo incidentu a o opatřeních, která mohou zavést, „a to pokud možno ve strukturovaném, strojově čitelném a snadno automaticky zpracovatelném formátu“. Šablona 3 může být součástí plnění této povinnosti.
Platí i jiné režimy. Podle NIS2 oznamují základní a důležité subjekty významné incidenty svému týmu CSIRT nebo příslušnému orgánu a mnoho smluv se zákazníky obsahuje vlastní ustanovení o oznamování s vlastními lhůtami.
Buďte připraveni dřív, než přijde další
- Záznam toho, co každý build vydání nainstaloval, uchovávaný po dobu podpory produktu (SBOM z doby buildu).
- Seznam, kteří zákazníci provozují které verze.
- Tři výše uvedené šablony, schválené právním oddělením.
- Jmenovaný odesílatel a kanál pro každý typ zákazníka.
- Bezpečnostní stránka a soubor
security.txt, kam se publikují aktualizace (koordinované zveřejňování zranitelností). - Kontrola odchozího provozu v CI, aby kompromitovaný balíček nemohl posílat tajné klíče na hostitele, kterého build nepotřebuje (egress policy pro GitHub Actions).
Pro incidenty, které přicházejí po stovkách, ne po jednom, si přečtěte o škálování týmu PSIRT.
Kde pomůže CRACI
Tabulka důkazů výše stále žádá jedno: záznam toho, co každý build vydání nainstaloval. Právě ten CRACI uchovává. CRACI spouští vaše buildy GitHub Actions na vlastních runnerech a zaznamenává každý balíček, který každý job skutečně stáhl, včetně balíčků stažených instalačními skripty a balíčků obnovených z cache. SBOM každého minulého buildu se uchovává, takže na otázku „nainstaloval nějaký build během okna axios 1.14.1?“ odpoví historie buildů, včetně období, kdy jste byli zasaženi, a to tak daleko do minulosti, jak sahá vaše doba uchovávání.
Známá škodlivá vydání, která mají zveřejněnou CVE, jako je backdoor v xz, jsou označena jako jakákoli jiná zranitelnost a policy gate může buildy, které je obsahují, zablokovat. CRACI nedetekuje nový škodlivý balíček podle jeho chování nebo reputace.
Egress policy od CRACI blokuje spojení na hostitele, které build nepotřebuje, což omezuje, co může škodlivý instalační skript odeslat ven, i při útoku, který nikdo předtím neviděl. Když zákazník požádá o důkazy, můžete SBOM pro verze, které provozuje, exportovat jako CycloneDX nebo SPDX a poslat mu ji. CRACI podporuje VEX.
Odpovězte na otázku „byli jsme zasaženi?“ z historie svých buildů, nebo si přečtěte více o tom, jak útoky na dodavatelský řetězec fungují.
Kdy CRACI není řešením
- Potřebujete pomoc se samotnou komunikací. PR a právní poradenství jsou jiná práce.
- Zasažený software nebyl sestaven na CRACI. CRACI zaznamenává buildy GitHub Actions, které běží na jeho runnerech; další systémy CI jsou v plánu vývoje.
- Otázka se týká produktu dodavatele, který jste nesestavili. SBOM dodavatelů lze do CRACI přidat, ale odpověď je jen tak dobrá jako SBOM dodavatele.
- Potřebujete zachytit zbrusu nový škodlivý balíček dřív, než existuje jakékoli bezpečnostní upozornění. CRACI označuje známá škodlivá vydání, jakmile je zveřejněno upozornění s CVE; malware podle chování nebo reputace nedetekuje (reakce na zero-day zranitelnosti).
Časté dotazy
Co říct zákazníkům, když se o útoku na dodavatelský řetězec píše ve zprávách?
Během několika hodin pošlete první prohlášení: že o útoku víte, že kontrolujete své produkty a buildy, co zatím víte a kdy pošlete aktualizaci. Navažte potvrzenou odpovědí pro jmenované verze produktů, jakmile ji dokážete podložit záznamy buildů, a následnou aktualizací, když se cokoli změní.
Co má obsahovat první prohlášení?
Co se stalo, v jedné větě, že kontrolujete své produkty a systémy pro build, co jste zatím zjistili, čas další aktualizace a kontakt. Nesmí tvrdit „netýká se nás“ dřív, než jste to ověřili, spekulovat o útočníkovi ani nikoho obviňovat.
Jak říct „netýká se nás“ a neslibovat příliš?
Jmenujte produkty a verze, které jste zkontrolovali, časové rozmezí zkontrolovaných buildů a důkazy, které jste použili, například záznam komponent, které nainstaloval každý build vydání. „Netýká se nás“ řekněte pro tyto verze, nabídněte SBOM nebo prohlášení VEX a slibte aktualizaci, pokud se něco změní. Vyhněte se formulacím „100% bezpečné“ nebo „plně zabezpečeno“.
Co má obsahovat oznámení zákazníkům „byli jsme zasaženi“?
Které produkty a verze jsou zasaženy, odkdy a do které opravené verze, riziko srozumitelnou řečí, co má zákazník udělat nyní (upgrade, výměna přihlašovacích údajů, blokování hostitelů), co jste už udělali, kdy přijde další aktualizace a na koho se obrátit.
Jaké důkazy by měly podložit tvrzení „netýká se nás“?
Pro každou verzi, kterou zákazníci provozují, záznam toho, co nainstaloval build, který ji vytvořil, ne dnešní lockfile. Přidejte záznamy každého buildu, který běžel během okna útoku, a u útoků, které kradou přihlašovací údaje, informaci, zda byly v jobech, které mohly spustit škodlivý kód, k dispozici tajné klíče.
Musím útok na dodavatelský řetězec nahlásit podle Cyber Resilience Act?
Možná. Od 11. září 2026 musí výrobci produktů s digitálními prvky prodávaných v EU hlásit aktivně zneužívané zranitelnosti a závažné incidenty s dopadem na bezpečnost produktu: včasné varování do 24 hodin, oznámení do 72 hodin a závěrečnou zprávu. Zda konkrétní útok tyto podmínky splňuje, musíte posoudit vy a váš právník.
Jak rychle bychom měli zákazníkům odpovědět?
Během několika hodin, a to prvním prohlášením, i kdyby říkalo jen to, že věc kontrolujete a kdy pošlete aktualizaci. Potvrzená odpověď následuje, jakmile ji dokážete doložit. Rychlé upřímné „kontrolujeme to“ udělá pro důvěru víc než pozdní „netýká se nás“.
