Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Incydent bezpieczeństwa ujawniony przez Novo Nordisk pokazuje, że współczesne ataki coraz częściej zaczynają się nie od klasycznego przełamania perymetru, lecz od kompromitacji środowiska deweloperskiego. W praktyce oznacza to wykorzystanie tokenów dostępowych, sekretów zapisanych w repozytoriach kodu, kont usługowych oraz powiązań między systemami CI/CD, chmurą i produkcją.
Tego typu naruszenia są szczególnie niebezpieczne, ponieważ pojedynczy sekret może otworzyć drogę do szerokiego ruchu bocznego, eskalacji dostępu oraz długotrwałej obecności napastnika w infrastrukturze organizacji.
W skrócie
Novo Nordisk poinformował 11 czerwca 2026 r. o incydencie bezpieczeństwa obejmującym nieautoryzowany dostęp do ograniczonej liczby wewnętrznych systemów IT. Firma potwierdziła, że część niepublicznych danych, w tym danych osobowych, została skopiowana poza organizację bez upoważnienia.
Z opublikowanych informacji wynika, że incydent objął między innymi pseudonimizowane dane uczestników badań klinicznych oraz dane kontaktowe pracowników ochrony zdrowia. Opisy zdarzenia sugerują, że kluczowym elementem wektora wejścia mógł być pojedynczy token GitHub o wysokich uprawnieniach.
- Nieautoryzowany dostęp dotknął wybrane systemy wewnętrzne.
- Doszło do skopiowania części niepublicznych danych poza organizację.
- Wśród potencjalnie naruszonych informacji znalazły się dane badań klinicznych i dane kontaktowe HCP.
- Incydent podkreśla znaczenie ochrony sekretów i tożsamości nieosobowych.
Kontekst / historia
Novo Nordisk to globalna firma farmaceutyczna, dlatego każde naruszenie dotyczące jej środowisk IT ma znaczenie wykraczające poza klasyczny incydent korporacyjny. Organizacje z sektora life sciences przechowują jednocześnie własność intelektualną, dane badawcze, informacje o procesach produkcyjnych oraz dane osobowe pacjentów i partnerów medycznych.
To sprawia, że są atrakcyjnym celem zarówno dla grup ransomware, jak i dla podmiotów zainteresowanych kradzieżą danych strategicznych. W oficjalnym komunikacie spółka podała, że po wykryciu incydentu uruchomiła dochodzenie z udziałem zewnętrznych ekspertów cyberbezpieczeństwa, skontaktowała się z właściwymi organami i czasowo wyłączyła część systemów wewnętrznych w celu ochrony środowiska.
Jednocześnie firma zaznaczyła, że podstawowa działalność biznesowa nie została zakłócona. Dodatkowy kontekst zapewniają komunikaty skierowane do osób, których dane mogły zostać objęte naruszeniem, w tym do pacjentów i personelu medycznego, gdzie wskazano również na ryzyko phishingu, prób podszywania się oraz oszustw prowadzonych przez e-mail, telefon i komunikatory.
Analiza techniczna
Najważniejszy techniczny wniosek z tego zdarzenia dotyczy roli pojedynczego sekretu dostępowego. Jeśli token GitHub rzeczywiście został ujawniony po stronie klienta lub w publicznie dostępnym komponencie aplikacji, oznacza to klasyczny, ale nadal bardzo kosztowny błąd w zarządzaniu sekretami.
Taki token może umożliwić dostęp do prywatnych repozytoriów, a następnie do kolejnych poświadczeń, plików konfiguracyjnych, workflow CI/CD, definicji infrastruktury jako kodu oraz integracji z chmurą. W praktyce atak na pipeline deweloperski zwykle przebiega etapowo.
- Pozyskanie sekretu, tokenu lub klucza API.
- Enumeracja repozytoriów i przeszukiwanie ich pod kątem kolejnych poświadczeń.
- Wykorzystanie danych z kodu, plików konfiguracyjnych i historii commitów.
- Pivot do platform budowania, rejestrów artefaktów, kontenerów, chmury i środowisk produkcyjnych.
Szczególnie istotne jest to, że zabezpieczenia typowe dla procesu developerskiego, takie jak code review, branch protection czy akceptacja zmian, zakładają prawidłową tożsamość wykonawcy operacji. Jeśli napastnik przejmuje token lub konto zaufane przez pipeline, wiele mechanizmów kontrolnych przestaje pełnić funkcję ochronną.
Problem nie dotyczy więc wyłącznie przechowywania sekretów, lecz także modelu tożsamości, zakresu uprawnień i cyklu życia poświadczeń maszynowych. Ważny pozostaje również aspekt pseudonimizacji danych, która ogranicza bezpośrednie ryzyko identyfikacji osób, ale nie eliminuje wartości takich informacji dla napastników.
Konsekwencje / ryzyko
Z perspektywy bezpieczeństwa przedsiębiorstwa incydent tego typu niesie kilka warstw ryzyka. Pierwsza to ryzyko operacyjne związane z koniecznością izolacji systemów, ograniczenia dostępu i prowadzenia dochodzenia forensycznego. Druga to ryzyko regulacyjne i prywatnościowe, zwłaszcza gdy naruszenie obejmuje dane osobowe lub dane związane z badaniami klinicznymi.
Trzecia warstwa to ryzyko strategiczne związane z potencjalnym wyciekiem kodu źródłowego, dokumentacji, modeli AI, danych badawczych czy informacji o procesach produkcyjnych. W sektorze farmaceutycznym wyciek danych z pipeline’u deweloperskiego może mieć większe znaczenie niż sama utrata pojedynczego systemu.
Repozytoria kodu i narzędzia CI/CD są dziś centralnym punktem integracji między rozwojem, infrastrukturą i produkcją. Zawierają nie tylko kod, lecz także definicje środowisk, klucze integracyjne, skrypty wdrożeniowe i wiedzę o architekturze, co dla atakującego stanowi mapę całego środowiska.
Dla osób, których dane mogły zostać objęte incydentem, najważniejsze pozostaje ryzyko ukierunkowanego phishingu i podszywania się pod zaufane podmioty. Nawet jeśli dane nie pozwalają na prostą identyfikację pacjentów, mogą posłużyć do tworzenia wiarygodnych pretekstów kontaktu.
Rekomendacje
Organizacje powinny traktować środowiska deweloperskie jak systemy produkcyjne o wysokiej krytyczności. Oznacza to objęcie repozytoriów, platform CI/CD, rejestrów artefaktów, stacji roboczych deweloperów i integracji chmurowych pełnym nadzorem bezpieczeństwa.
- Centralizacja zarządzania sekretami i eliminacja poświadczeń przechowywanych w kodzie lub po stronie klienta.
- Stosowanie krótkotrwałych poświadczeń oraz automatycznej rotacji tokenów i kluczy API.
- Pełna inwentaryzacja tożsamości nieosobowych wraz z przypisaniem właścicieli i zakresem uprawnień.
- Wdrożenie zasady najmniejszych uprawnień dla tokenów, kont usługowych i integracji.
- Ciągłe skanowanie repozytoriów oraz historii commitów pod kątem ujawnionych sekretów.
- Monitoring behawioralny tożsamości maszynowych i wykrywanie anomalii użycia.
- Separacja środowisk deweloperskich od produkcji oraz regularne ćwiczenia reagowania na incydenty.
Kluczowe jest również wdrożenie mechanizmów ograniczających skutki kompromitacji jednego komponentu, takich jak silne MFA dla kont uprzywilejowanych, podpisywanie buildów oraz kontrola dostępu do artefaktów.
Podsumowanie
Incydent Novo Nordisk pokazuje, że bezpieczeństwo procesu wytwarzania oprogramowania stało się jednym z najważniejszych obszarów obrony organizacji. Pojedynczy token o zbyt szerokich uprawnieniach może uruchomić łańcuch zdarzeń prowadzący do przejęcia repozytoriów, ruchu bocznego, eksfiltracji danych i długotrwałej obecności napastnika w środowisku.
Najważniejsza lekcja jest prosta: sekrety nie są wyłącznie problemem narzędziowym, lecz problemem zarządzania tożsamością, uprawnieniami i widocznością całego ekosystemu developerskiego. Organizacje, które nie potraktują pipeline’ów jako infrastruktury krytycznej, pozostaną podatne na ataki o bardzo szerokim promieniu rażenia.
Ź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/content/nncorp/global/en/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
- Information letter for HCPs regarding Novo Nordisk IT incident — https://www.novonordisk.com/content/dam/nncorp/global/en/media/pdfs/updates/HCP%20Letter.pdf
- Incident update — https://www.novonordisk.com/news-and-media/latest-news/incident-update.html