Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Ataki typu supply chain należą do najpoważniejszych zagrożeń dla nowoczesnych procesów wytwarzania oprogramowania. Zamiast atakować bezpośrednio organizację docelową, cyberprzestępcy kompromitują elementy łańcucha dostaw, takie jak biblioteki, pakiety i narzędzia wykorzystywane podczas budowania oraz wdrażania aplikacji. Najnowszy incydent związany z pakietami NPM powiązanymi z ekosystemem SAP pokazuje, jak niewielka zmiana w zależności może przełożyć się na szerokie ryzyko dla zespołów korzystających z SAP Cloud Application Programming Model oraz SAP Business Technology Platform.
W skrócie
Cztery pakiety NPM związane z SAP zostały uznane za złośliwe po wstrzyknięciu do nich kodu uruchamianego na etapie instalacji. Kampania, określana jako Mini Shai-Hulud, wykorzystywała mechanizm preinstall do pobrania i uruchomienia dodatkowego komponentu, którego zadaniem była kradzież sekretów i danych uwierzytelniających z lokalnych środowisk deweloperskich oraz pipeline’ów build i release.
- Złośliwe wersje były dostępne przez krótki czas, ale mogły zostać automatycznie pobrane przez systemy CI/CD.
- Atak koncentrował się na przejęciu tokenów, kluczy API i sekretów chmurowych.
- Incydent mógł prowadzić do dalszej propagacji w łańcuchu dostaw oprogramowania.
Kontekst / historia
Incydent dotyczył czterech wersji pakietów NPM używanych w kontekście narzędzi i usług bazodanowych SAP CAP. Wśród nich znajdowały się komponenty wykorzystywane do budowania archiwów aplikacji typu Multi-Target Application oraz obsługi warstwy bazodanowej aplikacji. Z uwagi na dużą liczbę pobrań i rolę tych pakietów w automatyzacji procesów build, kompromitacja miała znaczenie nie tylko dla pojedynczych programistów, ale także dla organizacji utrzymujących rozbudowane procesy dostarczania oprogramowania.
Zgodnie z ustaleniami złośliwe wersje opublikowano 29 kwietnia 2026 roku i pozostawały dostępne przez ograniczony czas, po czym zostały zastąpione czystymi wydaniami. Krótkie okno ekspozycji nie eliminuje jednak zagrożenia, ponieważ wiele środowisk automatycznie pobiera nowe wersje zależności bez manualnej weryfikacji, zwłaszcza przy stosowaniu luźnych zakresów wersjonowania oraz zależności przechodnich.
Analiza techniczna
Centralnym elementem ataku był złośliwy skrypt preinstall osadzony w opublikowanych pakietach. Tego typu skrypt uruchamia się jeszcze przed właściwą instalacją zależności, co daje napastnikowi możliwość wykonania kodu na maszynie dewelopera lub agencie CI zanim użytkownik zidentyfikuje problem. W analizowanym przypadku skrypt działał jako bootstrapper: pobierał archiwum ZIP zawierające środowisko Bun z repozytorium GitHub, rozpakowywał je i uruchamiał dołączony komponent binarny.
Kolejny etap obejmował kradzież informacji z hosta oraz środowiska wykonawczego. Malware był ukierunkowany na lokalne poświadczenia, tokeny GitHub i NPM, a także sekrety chmurowe związane z AWS, Azure, GCP, GitHub Actions i Kubernetes. Oznacza to, że pojedyncza kompromitacja builda mogła skutkować nie tylko wyciekiem danych, ale również wtórnym przejęciem repozytoriów, rejestrów pakietów oraz procesów publikacji.
Istotnym aspektem kampanii był także mechanizm propagacji. Z analiz wynika, że zagrożenie sprawdzało workflow publikacyjne GitHub Actions, a następnie modyfikowało paczki tarball, dodawało payload, podbijało wersje pakietów, ponownie je pakowało i publikowało z wykorzystaniem przejętych tokenów. To wskazuje na próbę półautomatycznego rozprzestrzeniania się w ekosystemie zależności.
Jedna z hipotez dotyczących wektora początkowego zakłada kompromitację tokenu NPM, który mógł zostać ujawniony w procesach pull request build realizowanych przez CircleCI. Jeśli taki scenariusz się potwierdzi, będzie to kolejny dowód na to, że sekrety dostępne podczas automatycznych buildów są krytycznym punktem ryzyka i wymagają ścisłego ograniczania uprawnień, rotacji oraz segmentacji.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją incydentu jest możliwość przejęcia sekretów wykorzystywanych w procesach programistycznych i wdrożeniowych. W praktyce oznacza to ryzyko nieautoryzowanego dostępu do repozytoriów kodu, rejestrów pakietów, kont chmurowych, pipeline’ów release, a nawet środowisk produkcyjnych, jeśli tokeny miały szerokie uprawnienia.
Dla użytkowników SAP CAP i SAP BTP zagrożenie ma szczególne znaczenie, ponieważ kompromitowane pakiety mogą znajdować się w centralnym miejscu procesu budowania aplikacji, rozszerzeń, backendów i integracji. Jeśli złośliwa wersja została pobrana w czasie ekspozycji, organizacja powinna założyć możliwość naruszenia poufności sekretów i przeprowadzić pełne dochodzenie powłamaniowe.
Ryzyko wtórne obejmuje również dalsze skażenie łańcucha dostaw. Jeżeli skradzione tokeny zostały wykorzystane do publikacji kolejnych pakietów lub modyfikacji workflow automatyzacji, skala incydentu może wykraczać poza pierwotnie dotknięte komponenty. Tego typu atak łączy cechy infostealera, nadużycia CI/CD i samopropagującej kompromitacji środowisk developerskich.
Rekomendacje
Organizacje korzystające z SAP CAP, SAP BTP oraz narzędzi MTA powinny w pierwszej kolejności ustalić, czy w oknie ekspozycji zostały pobrane lub zainstalowane złośliwe wersje pakietów. Należy przeanalizować logi menedżerów pakietów, historię buildów CI/CD, cache zależności oraz artefakty publikowane w tym okresie.
W przypadku potwierdzenia kontaktu ze złośliwą wersją wszystkie sekrety dostępne w danym środowisku należy uznać za potencjalnie ujawnione. Obejmuje to rotację tokenów NPM, GitHub, kluczy API, sekretów chmurowych, poświadczeń Kubernetes oraz wszelkich danych uwierzytelniających obecnych na hoście i w pipeline’ach. Samo usunięcie pakietu nie rozwiązuje problemu.
- blokowanie lub ścisłe monitorowanie skryptów install, preinstall i postinstall,
- wymuszanie przypinania wersji zamiast szerokich zakresów semver,
- skanowanie zależności pod kątem nietypowych zmian w metadanych i lifecycle scripts,
- ograniczanie dostępu sekretów w buildach pull request i środowiskach testowych,
- stosowanie krótkotrwałych tokenów oraz separacji uprawnień do publikacji pakietów,
- monitorowanie ruchu wychodzącego z agentów CI/CD,
- weryfikację integralności artefaktów publikowanych do rejestrów wewnętrznych i zewnętrznych.
Dodatkowo warto uruchomić retrospektywny threat hunting w poszukiwaniu oznak eksfiltracji sekretów, nieautoryzowanych publikacji pakietów, zmian w workflow GitHub Actions oraz anomalii w użyciu tokenów serwisowych. W środowiskach wysokiego ryzyka wskazane może być także ponowne zbudowanie krytycznych artefaktów z zaufanego źródła.
Podsumowanie
Atak na pakiety NPM powiązane z SAP potwierdza, że ekosystem open source i procesy CI/CD pozostają jednym z kluczowych wektorów operacji supply chain. W tym przypadku kompromitacja ograniczonej liczby wersji pakietów wystarczyła, aby stworzyć realne ryzyko kradzieży sekretów, przejęcia pipeline’ów oraz dalszej propagacji zagrożenia. Dla zespołów korzystających z SAP CAP i powiązanych narzędzi najważniejsze są szybka identyfikacja ekspozycji, rotacja poświadczeń oraz wzmocnienie kontroli bezpieczeństwa wokół zależności i procesów publikacji.