Únos balíčků debug a chalk byl selhání identity maintainera, ne příběh o Severní Koreji

29. července 2026 zveřejnil Amazon Threat Intelligence výzkum, který přiřadil zářijový únos balíčků debug a chalk z roku 2025 stejné severokorejské skupině, jakou později označili za viníka kompromitace axiosu z března 2026. Přečtěte si tu časovou osu ještě jednou. Otrávení debug a chalk se stalo v září 2025, leželo ve veřejných záznamech zhruba deset měsíců a po většinu té doby se to popisovalo jako obyčejný crypto-drainer, kus injektovaného kódu, který v prohlížeči prohazoval adresy peněženek, aby seškrábal transakce každému, kdo měl tu smůlu a stáhl si špatnou verzi. Všichni to zapatchovali, všichni šli dál, postmortemy se založily pod hygienu supply chainu a zapomnělo se na to. Pak přišla atribuce a najednou celý příběh dostal nátěr nation-state útoku a spousta lidí, kteří to poprvé ignorovali, začala dávat pozor, protože teď na tom visí vlaječka. Ta reakce je přesně naruby. Zajímavé na tomhle incidentu nikdy nebylo, kdo ho spáchal. debug a chalk dohromady mají přes dvě miliardy stažení týdně. chalk samotný je tranzitivní závislost naprosto absurdní části JavaScriptového toolingu, který denně používáte: ESLint, Jest, půlka CLI nástrojů ve vašem node_modules, prostě všeho. Když se něco takhle hluboko zabudovaného kompromituje, je úplně jedno, jestli je útočník znuděný teenager nebo státem financovaná jednotka s výplatní páskou a KPI. Blast radius je identický. To, co to umožnilo, je přesně to samé, co by to umožnilo náhodnému oportunistovi, a je to nudné, strukturální a naprosto ve vaší moci to promyslet.

Vstupním bodem byl jediný vyphishovaný účet maintainera. Ne zero-day v npm, ne kompromitovaný CI runner, ne otrávená build cache. Někdo poslal maintainerovi těchto balíčků přesvědčivý e-mail, získal přihlašovací údaje nebo session a pushnul novou verzi pod namespace, který npm, váš registry, váš resolver i vaši kolegové považují za legitimně jeho. To je celý útok. Funguje to proto, že npm model maintainerů bere publish práva jako vlastnost účtu, ne vlastnost konkrétního release, a většina hodnotných balíčků má přesně jeden účet, na kterém záleží. Neexistuje žádná redundance vlastnictví, žádná druhá strana, která by musela spolupodepsat, žádné oddělení mezi člověkem, který píše kód, a přihlašovacím údajem, který to dodá dvěma miliardám stažení týdně. debug je v podstatě sólo projekt někoho, kdo dělá ekosystému obrovskou laskavost zadarmo, a chci být jasný v tom, že tohle není kritika toho člověka. Phishing funguje na chytré a opatrné lidi neustále a to břemeno nikdy nemělo ležet na jednom dobrovolníkovi, aby byl nerozbitnou pevností identity. Problém je, že systém umístil celou hranici důvěry na jedinou schránku. Když spustíte npm install, rozšiřujete tranzitivní důvěru na každý účet, který může cokoliv publikovat ve vašem stromu, a nemáte tušení, kolik z těch účtů má 2FA, jestli je to phishovatelné SMS 2FA nebo hardwarový klíč, jestli maintainer recykluje hesla, nebo jestli v úterý neklikne na špatný odkaz. Spoléháte na e-mailovou hygienu stovek cizích lidí.

Co bolí týmy, které si myslely, že mají odvedeno, je fakt, že připnutý lockfile a čisté SBOM vám tady nedaly žádnou ochranu, a pochopit proč je vlastně pointa celého tohohle článku. Lockfile připíná verze a integrity hashe, aby všichni resolvovali přesně stejné byty, což je skvělé proti zmutovanému tarballu nebo typosquattu pod jiným jménem. Ale nezmůže vůbec nic, když legitimní namespace publikuje novou verzi, protože z pohledu lockfilu je chalk@5.x.y od skutečného maintainera chalku prostě chalk, tečka. Integrity hash sedí na škodlivý tarball dokonale, protože ten škodlivý tarball je přesně to, co se publikovalo pod pravým jménem. Vaše SBOM má tu samou slepou skvrnu. SBOM vám řekne, co běží a odkud to podle registru přišlo, a registry vám vesele potvrdí, že tenhle otrávený build přišel ze správného, ověřeného, legitimního balíčku. Každý provenance signál, na který jste spoléhali, ukazoval na zelenou. Tohle je ta past. Roky jsme lidi učili, že reprodukovatelné buildy, připnuté závislosti a generované bills of materials zpevní supply chain, a ony opravdu zpevní jednu reálnou třídu útoků, jenže všechny předpokládají, že samotný namespace je důvěryhodný. Ve chvíli, kdy je unesená právě ta důvěryhodná identita, každá kontrola pod ní zdědí kompromitaci a sebevědomě hlásí úspěch. Provenance je jen tak dobrá jako účet, který ji vytvořil, a žádný z těchhle nástrojů nebyl navržený tak, aby odpověděl na otázku, na které opravdu záleželo: jestli je člověk za tímhle publishem pořád ten člověk, kterého jste si mysleli.

Existuje sada kontrol, které by phishing nezastavily, ale zmenšily by blast radius z katastrofického na otravný, a všechny jsou věci, se kterými můžete začít tenhle týden. Verified publishing s trusted provenance, kde se balíčky publikují ze známého CI workflow přes OIDC místo z notebooku s dlouho žijícím tokenem, zvedá laťku, protože ukradený npm credential samotný přestává stačit. Útočník musí navíc kompromitovat build pipeline, která má právo vytvořit provenance attestation. Podpora provenance v npm a attestations podložené sigstore jsou směr, kterým se celý ekosystém pomalu plazí, a pro každý balíček, který váš tým vlastní, byste to měli zapnout hned. Multi-party release signing je větší strukturální oprava a ta, které se ekosystém pořád vyhýbá, protože přidává tření, ale release model, kde dva nezávislí maintaineři musí schválit release, než jde verze s dvěma miliardami stažení do světa, by tohle zastavil na místě. Vyphishovat jednoho dobrovolníka je snadné, vyphishovat dva naráz na stejném release je materiálně jiná operace. Pro balíčky, které konzumujete, ne publikujete, je realistická kontrola dependency monitoring, který označí nové verze, než dopadnou do vašeho buildu, krátká karanténa na nové release kritických závislostí a alerting na změny maintainera nebo vlastnictví. Nástroje jako Socket a novější registry proxy existují přesně proto, aby zachytily změny chování: balíček, který najednou sáhne po síti nebo čte env proměnné, které dřív nikdy netknul, a tenhle behaviorální diff je často jediný dostupný signál, když identita i hash sedí čistě.

V tomhle ekosystému stavíme každý den, Next.js a React Native na frontendu, Go a Django služby za tím, a každý z těch projektů má dependency strom dost hluboký na to, abychom osobně nemohli ručit za každého maintainera v něm. Takže jsme přestali předstírat, že cílem je perfektně důvěryhodný strom, a začali ten strom brát jako hostile-by-default a místo toho škody zadržovat. Konkrétně to znamená, že naše kritické deploymenty se při buildu neinstalují přímo z veřejného registru, ale resolvují přes proxy, která nové verze pozdrží na review window a screenuje behaviorální drift, takže úterní odpolední otrávení balíčku, na kterém závisíme, nezasáhne produkci to samé odpoledne. Znamená to, že v CI běží provenance checky a build spadne, když balíček, který dřív měl attestation, ho najednou nemá. Znamená to, že u interních nástrojů a document pipeline, které dodáváme klientům, držíme dependency surface záměrně malý, protože každý balíček, na kterém nezávisíte, je účet, který vám nemůže ublížit. Nic z toho není exotické a nic z toho nevyžaduje vlastní threat intelligence tým. Incident s debug a chalk stojí za zapamatování ne jako doba, kdy byla Severní Korea chytrá, chytrá být nemusela, ale jako nejjasnější možná ukázka toho, že identita maintainera je útočná plocha, že schránka jednoho dobrovolníka je nosná infrastruktura pro obrovský díl softwaru, který dodáváte, a že kontroly, kterým jste už věřili, se potichu dívaly jinam. Navrhujte tak, jako by se namespace mohl obrátit proti vám, protože podle těchhle důkazů může.