Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Incydent bezpieczeństwa ujawniony przez Novo Nordisk pokazuje, że współczesne ataki coraz częściej koncentrują się nie na tradycyjnym perymetrze sieci, lecz na środowiskach deweloperskich, repozytoriach kodu oraz tożsamościach maszynowych. W praktyce oznacza to, że pojedynczy ujawniony token dostępu może stać się punktem wejścia do znacznie szerszego naruszenia obejmującego łańcuch dostaw oprogramowania, dane badawcze i systemy wewnętrzne organizacji.
To istotna zmiana perspektywy dla zespołów bezpieczeństwa. Repozytoria kodu nie są już wyłącznie miejscem przechowywania aplikacji, lecz coraz częściej zawierają definicje infrastruktury, konfiguracje wdrożeń, integracje z chmurą i sekrety wykorzystywane przez automatyzację.
W skrócie
Novo Nordisk poinformował 11 czerwca 2026 r. o incydencie obejmującym nieautoryzowany dostęp do ograniczonej liczby wewnętrznych systemów IT oraz nieuprawnione skopiowanie części danych poza organizację. Z publicznie dostępnych informacji wynika, że jednym z możliwych punktów wejścia był ujawniony token GitHub o szerokich uprawnieniach.
Taki scenariusz jest szczególnie niebezpieczny, ponieważ umożliwia atakującemu działanie z poziomu legalnej, uwierzytelnionej tożsamości. W efekcie napastnik może uzyskać dostęp nie tylko do prywatnych repozytoriów, ale również do kolejnych poświadczeń zapisanych w kodzie, konfiguracjach oraz pipeline’ach CI/CD.
Kontekst / historia
W oficjalnej komunikacji firma potwierdziła, że naruszenie dotyczyło ograniczonej liczby wewnętrznych systemów IT, a część niepublicznych danych, w tym danych osobowych, została skopiowana bez autoryzacji. Jednocześnie podkreślono, że podstawowe operacje biznesowe pozostały aktywne.
W materiałach skierowanych do uczestników badań klinicznych wskazano, że incydent objął pseudonimizowane dane części pacjentów, takie jak identyfikator pacjenta, informacje o udziale w badaniu, płeć, rok urodzenia, biomarkery, dane zdrowotne lub immunogenności oraz wybrane czynniki stylu życia. Z kolei komunikacja do pracowników ochrony zdrowia ostrzegała przed ryzykiem phishingu, podszywania się pod współpracowników oraz oszustw realizowanych przez e-mail, telefon i komunikatory.
Równolegle w przestrzeni publicznej pojawiły się twierdzenia grupy przypisującej sobie atak, według których skala naruszenia mogła być większa niż oficjalnie ujawniono. Tego typu rozbieżności są charakterystyczne dla współczesnych incydentów ransomware i extortion, w których organizacja komunikuje potwierdzony zakres zdarzenia, a aktor zagrożenia próbuje zwiększyć presję poprzez sugerowanie szerszego wycieku.
Analiza techniczna
Najważniejszym aspektem technicznym tego przypadku jest domniemany wektor wejścia: token dostępu GitHub ujawniony po stronie klienta w kodzie JavaScript. Jeśli taki sekret posiadał szerokie uprawnienia, mógł zostać wykorzystany jak pełnoprawna tożsamość zaufanego użytkownika lub procesu, bez konieczności klasycznego przełamywania zabezpieczeń.
Po uzyskaniu dostępu do repozytorium napastnik może bardzo szybko przeprowadzić rekonesans środowiska i wyszukać kolejne ścieżki eskalacji. W repozytoriach często znajdują się elementy, które znacząco zwiększają potencjał ataku.
- pliki konfiguracyjne aplikacji,
- definicje infrastruktury jako kodu,
- ustawienia pipeline’ów CI/CD,
- sekrety zapisane jawnie lub półjawnie,
- tokeny API,
- dane dostępowe do chmury,
- konta serwisowe i klucze integracyjne.
Taki zestaw informacji umożliwia przejście od jednego tokenu do kolejnych poświadczeń, a następnie do ruchu bocznego pomiędzy systemami. To właśnie dlatego środowisko developerskie jest dziś jednym z najbardziej wartościowych celów dla atakujących.
Szczególnie istotny jest problem tożsamości nie-ludzkich, czyli kont serwisowych, sekretów automatyzacji, tokenów i poświadczeń wykorzystywanych przez pipeline’y. W wielu organizacjach nie mają one jednoznacznego właściciela, nie są regularnie rotowane, posiadają nadmierne uprawnienia i pozostają aktywne znacznie dłużej, niż wymaga tego ich rola. W efekcie pojedynczy wyciek sekretu może zapewnić napastnikowi długotrwałą obecność w środowisku.
Z perspektywy architektury bezpieczeństwa jest to klasyczny przykład błędu polegającego na traktowaniu zarządzania sekretami wyłącznie jako problemu narzędziowego. Sam skaner sekretów lub sam vault nie rozwiązuje problemu, jeśli organizacja nie kontroluje pełnego cyklu życia tożsamości, nie egzekwuje zasady najmniejszych uprawnień i nie monitoruje zachowania tokenów oraz kont maszynowych w czasie rzeczywistym.
Konsekwencje / ryzyko
Ryzyko wynikające z tego typu incydentu należy analizować na kilku poziomach. Pierwszy dotyczy poufności danych. W przypadku firmy farmaceutycznej chodzi nie tylko o dane osobowe, ale również o wyniki badań klinicznych, własność intelektualną, informacje produktowe, dokumentację badawczo-rozwojową oraz potencjalnie dane związane z procesami produkcyjnymi.
Drugi poziom obejmuje integralność łańcucha dostaw oprogramowania. Jeśli napastnik uzyskuje dostęp do repozytoriów i pipeline’ów, może teoretycznie modyfikować kod, artefakty buildów, procesy wdrożeniowe lub zależności projektowe. Nawet jeśli nie dochodzi do sabotażu, sama możliwość naruszenia zaufania do procesu wytwarzania oprogramowania generuje wysokie koszty audytowe, operacyjne i regulacyjne.
Trzeci obszar to ryzyko operacyjne i reputacyjne. Organizacje z sektora life sciences działają pod silną presją regulacyjną, a każda informacja o wycieku danych badawczych lub informacji dotyczących pacjentów może wpływać na relacje z partnerami, badaczami, dostawcami i organami nadzoru. Dodatkowe szkody mogą wynikać z kampanii phishingowych wymierzonych w personel medyczny, uczestników badań oraz pracowników firmy.
Czwarty poziom to ryzyko wtórne. Ujawnione repozytoria lub sekrety często stają się bazą do kolejnych działań, takich jak przejęcia kont chmurowych, kompromitacja środowisk testowych, nadużycia API czy próby długofalowej infiltracji procesów badawczych i analitycznych.
Rekomendacje
Organizacje powinny potraktować ten incydent jako sygnał do przeglądu bezpieczeństwa całego software development lifecycle. Kluczowe działania powinny objąć zarówno technologię, jak i zarządzanie tożsamościami oraz procesami operacyjnymi.
- Przeprowadzenie pełnej inwentaryzacji tożsamości nie-ludzkich, w tym tokenów Git, kluczy API, kont serwisowych, sekretów CI/CD i poświadczeń chmurowych.
- Bezwzględne wdrożenie zasady najmniejszych uprawnień dla tokenów repozytoryjnych, kont automatyzacji i integracji zewnętrznych.
- Usunięcie sekretów z kodu, plików konfiguracyjnych i artefaktów budowania oraz przeniesienie ich do zarządzanych magazynów sekretów.
- Wdrożenie automatycznej rotacji poświadczeń oraz preferowanie krótkotrwałych tokenów zamiast długowiecznych sekretów osobistych.
- Traktowanie monitoringu środowiska developerskiego na równi z monitoringiem produkcji, w tym wykrywanie nietypowego użycia tokenów i masowego klonowania repozytoriów.
- Uruchomienie polityk pre-commit i pre-receive blokujących umieszczanie sekretów w repozytoriach oraz skanowanie historycznych commitów.
- Wzmocnienie bezpieczeństwa stacji roboczych deweloperów, IDE, agentów buildów i runnerów automatyzacji.
Najważniejszy wniosek praktyczny jest prosty: bezpieczeństwo pipeline’u deweloperskiego musi być traktowane jak ochrona systemów produkcyjnych o najwyższej krytyczności. To tam coraz częściej znajduje się rzeczywisty punkt ciężkości współczesnych ataków.
Podsumowanie
Incydent związany z Novo Nordisk pokazuje, że jedno ujawnione poświadczenie może stać się początkiem naruszenia obejmującego kod źródłowy, dane wrażliwe i zasoby o strategicznej wartości biznesowej. Współczesne organizacje nie mogą już zakładać, że bezpieczeństwo kończy się na ochronie perymetru.
Repozytoria, tokeny, konta serwisowe i pipeline’y CI/CD powinny być chronione jak kluczowe elementy infrastruktury krytycznej przedsiębiorstwa. W przeciwnym razie napastnik nie musi przełamywać tradycyjnych zabezpieczeń — wystarczy, że przejmie zaufaną tożsamość już obecną w ekosystemie wytwórczym.
Źródła
- Novo Nordisk Breach Exposes Software Development Pipeline Risk — https://www.darkreading.com/cyber-risk/novo-nordisk-breach-exposes-dev-pipeline-risk
- Novo Nordisk A/S: IT Security incident at Novo Nordisk — https://www.novonordisk.com/news-and-media/news-and-ir-materials/news-details.html?id=916571
- Information letter for patients regarding Novo Nordisk IT incident — https://www.novonordisk.com/content/dam/nncorp/global/en/media/pdfs/updates/Patient%20Letter.pdf
- Incident update — https://www.novonordisk.com/news-and-media/latest-news/incident-update.html
- Information letter for healthcare professionals regarding Novo Nordisk IT incident — https://www.novonordisk.com/content/dam/nncorp/global/en/media/pdfs/updates/HCP%20Letter.pdf