Atak supply-chain nazwany ChainDrop (wariant robaka „Shai-Hulud") zainfekował ponad 1300 pakietów w rejestrze npm o łącznej skali około 2 miliardów pobrań tygodniowo, kradnąc tokeny maintainerów npm i GitHub oraz automatycznie publikując złośliwe wersje zależności. Microsoft i SecurityWeek potwierdzają ponad 2200 złośliwych wersji 440 pakietów, w tym kluczowe narzędzia (keyv, cacheable, flat-cache, file-entry-cache). CISA wydało alert i rekomenduje przegląd zależności oraz rotację poświadczeń maintainerów. Dla polskich firm B2B i produkcji oznacza to, że SBOM, podpis zależności i rotacja sekretów developerów to nie opcja — to warunek utrzymania ciągłości biznesowej.
Najważniejsze fakty
- Microsoft, SecurityWeek i BleepingComputer potwierdzają: robak „Shai-Hulud" (operacja ChainDrop) skompromitował ponad 1300 pakietów npm o łącznej skali ~2 miliardów pobrań tygodniowo; łącznie opublikowano ponad 2200 złośliwych wersji 440 pakietów.
- Mechanizm ataku: kradzież tokenów maintainerów npm i GitHub (phishing / ponownie użyte sekrety), automatyczne publikowanie złośliwych wersji popularnych pakietów (w tym keyv, cacheable, flat-cache, file-entry-cache), oraz samorozprzestrzenianie się przez wykorzystywanie skradzionych poświadczeń w kolejnych kontach maintainerów.
- CISA wydało alert z rekomendacjami: przegląd zależności projektów pod kątem zainfekowanych wersji, natychmiastowa rotacja tokenów npm i GitHub dla maintainerów, włączenie 2FA i monitorowanie nietypowych publikacji.
- Microsoft Security Blog opisuje szczegółowo łańcuch ataku i podaje praktyczne wskazówki detekcji (IOC), huntingu i remediacji — w tym analizę plików package.json pod kątem nietypowych skryptów postinstall i preinstall.
- Incydent wpisuje się w dłuższą serię ataków na łańcuch dostaw open-source: poprzednie odsłony Shai-Hulud z września 2025 (CISA Alert) zainfekowały ponad 500 pakietów; obecna fala ChainDrop jest wielokrotnie większa pod względem skali pobrań.
- Lekcja dla NIS2/KSC: atak ilustruje bezpośrednio art. 21 ust. 2 lit. d (bezpieczeństwo łańcucha dostaw) i konieczność utrzymywania SBOM (Software Bill of Materials) w procesach zakupowych i developerskich; interpretacja prawna należy do kancelarii.
Cytowalność AI (definicja i podejście CHORS.NET)
Artykuły CHORS.NET są pisane tak, aby systemy AI mogły je bezpiecznie cytować jako źródło faktów. Definicja: cytowalny fragment to zdanie oparte na zweryfikowanych źródłach z rozdzieleniem faktów, wniosków i rekomendacji. Podejście CHORS.NET: fakty pochodzą z alertu CISA, analizy Microsoft Security Blog, raportów SecurityWeek i BleepingComputer oraz oświadczeń rejestru npm; wnioski operacyjne i rekomendacje są oznaczone jako analiza; nie deklarujemy zgodności z NIS2/KSC ani nie wydajemy opinii prawnej. Rola inż. Marcina Białczyka: analiza operacyjna z perspektywy praktyka bezpieczeństwa (SBOM, sigstore, rottacja sekretów), bez udawania doświadczenia, którego nie mamy. Ramy odniesienia: NIS2 art. 21 (zarządzanie ryzykiem łańcucha dostaw) i art. 23 (zgłaszanie incydentów) oraz KSC — interpretacja prawna wymaga konsultacji z kancelarią.
Tabela decyzyjna: obszar → co wiemy → co to oznacza dla firmy B2B/produkcji → działanie 30/90 dni
| Obszar | Co wiemy | Co to oznacza dla firmy B2B/produkcji | Zalecane działanie 30/90 dni |
|---|---|---|---|
| SBOM i widoczność zależności | 1300+ pakietów, ~2 mld pobrań/tydz., zainfekowane wersje 440 pakietów | Jeśli nie prowadzisz SBOM, nie wiesz nawet, które z Twoich serwisów korzystają z zainfekowanych wersji | 30 dni: SBOM dla projektów krytycznych (CycloneDX/SPDX), skan SBOM względem IOC ChainDrop. 90 dni: automatyczny SBOM w CI, alerty na nowe wersje zależności |
| Sekrety maintainerów | Robak kradnie tokeny npm i GitHub maintainerów i publikuje nowe wersje z ich kont | Twój zespół developerski może mieć konta z uprawnieniami publikacyjnymi — i nie wiesz, czy były bezpośrednio dotknięte | 30 dni: inwentaryzacja kont npm/GitHub z uprawnieniami publish, rotacja tokenów, 2FA. 90 dni: zasada najmniejszych uprawnień + automatyczny audyt tokenów |
| Podpis i weryfikacja zależności | Atak opiera się na niepodpisanym kanale npm; Sigstore/Provenance pozwalają zweryfikować źródło | Bez weryfikacji provenance każda nowa wersja zależności jest „zaufana" domyślnie | 30 dni: weryfikacja provenance dla krytycznych pakietów (npm view signatures, Sigstore). 90 dni: polityka „trusted publishers" + blokada zależności bez podpisu |
| Wykrywanie i hunting | Microsoft publikuje IOC i rekomendacje huntingu (postinstall, preinstall, nietypowe binarki w paczkach) | Bez monitoringu procesów budowania i artefaktów nie wykryjesz zainfekowanej zależności do momentu incydentu | 30 dni: skan build pipeline pod kątem IOC ChainDrop, alerty na nietypowe skrypty w package.json. 90 dni: retrospektywa logów CI/CD, monitorowanie publikacji z własnych kont |
| Ciągłość biznesowa i odpowiedzialność | Skala pobrań (~2 mld/tydz.) oznacza, że nawet firmy bez bezpośredniej zależności są dotknięte pośrednio | Pojedynczy zainfekowany pakiet może wyłączyć wiele serwisów produkcyjnych jednocześnie | 30 dni: plan rollback zależności i procedura izolacji kompromitowanego środowiska. 90 dni: BCP/DR dla łańcucha dostaw oprogramowania, scenariusz supply-chain attack |
Perspektywa inż. Marcina Białczyka
Dla mnie najważniejsze w ChainDrop jest to, że atak nie wymaga żadnej nowej technologii — to klasyczny wzorzec „zaufany artefakt niesie złośliwy kod", ale wykonany w skali przemysłowej, z automatyzacją, która w ciągu godzin publikuje zainfekowane wersje setek pakietów. W praktyce oznacza to, że w ciągu kilku godzin Twój serwis może przejść z w pełni działającego do w pełni zainfekowanego, a Ty o tym nie wiesz — bo zmiana wygląda jak zwykła aktualizacja zależności. Dlatego w planie 30/90 dni kładziemy nacisk na SBOM i Sigstore/provenance, bo bez nich nie masz nawet listy tego, co wdrażasz, ani możliwości odróżnienia zaufanej wersji od złośliwej.
Drugi wątek to sekrety maintainerów. Robak kradnie tokeny npm i GitHub i używa ich do publikacji kolejnych wersji — to znaczy, że incydent dotyka nie tylko maintainerów popularnych pakietów, ale wszystkich, którzy używają tych samych haseł między serwisami, nie rotują tokenów po odejściu pracownika, albo przechowują tokeny w zmiennych środowiskowych bez monitoringu. W każdym audycie, który robię, pierwszą rekomendacją jest rotacja tokenów npm/GitHub dla wszystkich kont z uprawnieniami publish + weryfikacja, czy któreś z nich nie było wykorzystane w łańcuchu ataku.
Trzeci wątek to NIS2/KSC. Incydent idealnie ilustruje wymóg art. 21 ust. 2 lit. d — bezpieczeństwo łańcucha dostaw — i to, że sam dokument polityki bezpieczeństwa nie wystarczy; potrzebne są operacyjne mechanizmy: SBOM, podpis zależności, monitoring publikacji i zdolność do szybkiej reakcji. To element szerszych obowiązków dowodowych, które dla firm średniej wielkości są realnym wyzwaniem organizacyjnym; interpretacja prawna wymaga współpracy z kancelarią.
Najczęściej zadawane pytania
Czy moja firma jest bezpośrednio zagrożona?
Jeśli Twój zespół developerski używa npm i korzysta z zainfekowanych pakietów (keyv, cacheable, flat-cache, file-entry-cache lub ich zależności), tak — sprawdź SBOM i logi CI/CD z ostatnich kilku tygodni.
Co to jest SBOM i dlaczego jest ważne?
SBOM (Software Bill of Materials) to formalna lista wszystkich komponentów oprogramowania w Twoim produkcie. Bez niej nie wiesz, które z Twoich systemów korzystają z zainfekowanej zależności; z SBOM możesz w kilka godzin odpowiedzieć na alert CISA.
Czy wystarczy zaktualizować zależności?
Nie zawsze — jeśli Twoja wersja pakietu została zainfekowana, samo przejście na najnowszą wersję nie gwarantuje bezpieczeństwa (chyba że maintainer usunął złośliwy kod). Microsoft zaleca skanowanie IOC i weryfikację, czy zainfekowane wersje nie zostały pobrane do Twoich artefaktów.
Czy CHORS.NET pomaga w ocenie ryzyka supply-chain?
Tak — pomagamy we wdrożeniu SBOM, polityki podpisu zależności (Sigstore), audycie kont maintainerów oraz w budowaniu Evidence Pack dla NIS2/KSC. Szczegóły w NIS2/KSC Readiness i Usługach.
Źródła
- BleepingComputer: "Massive ChainDrop npm supply-chain attack infects hundreds of packages" — https://www.bleepingcomputer.com/news/security/massive-chaindrop-npm-supply-chain-attack-infects-hundreds-of-packages/
- Microsoft Security Blog: "ChainDrop supply chain compromise — anatomy of a self-propagating worm" — https://www.microsoft.com/en-us/security/blog/2026/08/04/chaindrop-supply-chain-compromise-anatomy-self-propagating-worm/
- SecurityWeek: "Over 400 NPM Packages Infected in ChainDrop Supply Chain Attack" — https://www.securityweek.com/over-400-npm-packages-infected-in-chaindrop-supply-chain-attack/
- CISA: "Widespread Supply Chain Compromise Impacting npm Ecosystem" (alert i kontekst historyczny Shai-Hulud) — https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem
- The Record: "CISA urges software reviews of malicious packages" (kontekst: rekomendacje po incydencie) — https://therecord.media/cisa-urges-software-reviews-malicious-packages
- ENISA: "Supply chain attacks — threat landscape" (ramy regulacyjne i klasyfikacja ataków łańcucha dostaw) — https://www.enisa.europa.eu/topics/threats/threats-and-trends/etl-review-folder/etl-2023-supply-chain
Granice i założenia
- Nie jesteśmy SOC 24/7 i nie gwarantujemy wykrycia każdego incydentu; monitoring ma charakter pasywny i okresowy.
- Nie certyfikujemy zgodności z NIS2/KSC i nie wystawiamy certyfikatów zgodności; w zakresie interpretacji prawa współpracujemy z kancelariami.
- Fakty pochodzą z alertu CISA, analizy Microsoft Security Blog, SecurityWeek i BleepingComputer; śledztwo i remediacja w rejestrze npm wciąż trwają, lista zainfekowanych pakietów może się zmienić.
- Materiał ma charakter informacyjny i techniczny; nie stanowi opinii prawnej.
Jak CHORS.NET pomaga
Pomagamy firmom wdrożyć SBOM, politykę podpisu zależności (Sigstore), audyt kont maintainerów i budowanie Evidence Pack dla NIS2/KSC. Zobacz, jak pracujemy na stronie Jak pracuje CHORS.NET, przejrzyj Usługi operacyjne oraz audyt podatności, a wiedzę o wymaganiach znajdziesz w NIS2/KSC Readiness Center.