Cisco straciło kod źródłowy po naruszeniu środowiska deweloperskiego powiązanym z atakiem na Trivy

Wprowadzenie do problemu / definicja

Cisco padło ofiarą incydentu bezpieczeństwa, w którym atakujący wykorzystali poświadczenia przejęte wcześniej w łańcuchu dostaw związanym z narzędziem Trivy. W rezultacie doszło do naruszenia wewnętrznego środowiska deweloperskiego, uzyskania dostępu do systemów build oraz CI/CD, a także kradzieży kodu źródłowego należącego do firmy i części jej klientów.

To kolejny przykład zagrożenia, jakie niesie kompromitacja elementów wykorzystywanych w procesie tworzenia i dostarczania oprogramowania. Atak na pojedynczy komponent może przełożyć się na szeroki dostęp do repozytoriów, sekretów, środowisk chmurowych i zasobów laboratoriów deweloperskich.

W skrócie

• Źródłem incydentu miał być złośliwy komponent powiązany z wcześniejszym atakiem na ekosystem Trivy i GitHub Actions.
• Atakujący przejęli poświadczenia oraz uzyskali dostęp do środowiska deweloperskiego Cisco.
• W trakcie naruszenia skradziono klucze AWS i wykorzystano je do nieautoryzowanych działań w ograniczonej liczbie kont chmurowych.
• Sklonowano ponad 300 repozytoriów GitHub, w tym projekty związane ze sztuczną inteligencją i produktami przed premierą.
• Incydent objął także zasoby należące do części klientów korporacyjnych.

Kontekst / historia

Tłem zdarzenia był wcześniejszy atak na łańcuch dostaw związany z Trivy, popularnym skanerem podatności. Z ustaleń wynika, iż kompromitacja mogła dotyczyć pipeline’u GitHub, co umożliwiło dystrybucję złośliwego ładunku kradnącego poświadczenia poprzez oficjalne wydania i mechanizmy GitHub Actions.

Tego rodzaju operacje supply chain są szczególnie niebezpieczne, ponieważ wykorzystują zaufanie do powszechnie stosowanych narzędzi deweloperskich. Zamiast atakować pojedynczy endpoint, cyberprzestępcy koncentrują się na narzędziach budowania, integracji i publikacji kodu, które często posiadają rozległe uprawnienia oraz dostęp do krytycznych sekretów.

Incydent w Cisco wpisuje się więc w szerszy trend ataków na środowiska deweloperskie, rejestry pakietów i systemy CI/CD. Dla dużych organizacji oznacza to konieczność traktowania całego procesu wytwarzania systemu jako infrastruktury wysokiego ryzyka.

Analiza techniczna

Technicznie był to klasyczny przykład przejścia od kompromitacji łańcucha dostaw do wtórnego naruszenia środowiska ofiary. Punkt wejścia miał stanowić złośliwy komponent GitHub Actions służący do wykradania poświadczeń i danych z systemów build oraz development.

Takie podejście jest skuteczne, ponieważ workflowy CI/CD często mają szeroki dostęp do repozytoriów, sekretów, artefaktów i integracji chmurowych. Po przejęciu tych zasobów napastnicy mogą nie tylko kraść kod źródłowy, ale także rozszerzać dostęp na kolejne segmenty infrastruktury.

W omawianym przypadku atakujący przejęli również wiele kluczy AWS. Otwiera to możliwość wykonywania działań poza samym GitHubem, w tym przeglądania zasobów, pobierania danych, uruchamiania usług lub dalszego przemieszczania się między środowiskami. Naruszenie miało dotknąć dziesiątki urządzeń, co sugeruje, iż incydent nie ograniczył się wyłącznie do pipeline’u, ale objął też stacje robocze deweloperów i systemy laboratoryjne.

Szczególnie istotnym elementem było sklonowanie ponad 300 repozytoriów. Taki etap zwykle służy nie tylko eksfiltracji kodu, ale też analizie architektury aplikacji, zależności, integracji API oraz mechanizmów bezpieczeństwa. o ile w repozytoriach znajdowały się informacje klientów lub projekty przedpremierowe, wartość operacyjna takiego wycieku znacząco rośnie.

Po stronie obrony adekwatną reakcją jest izolacja dotkniętych systemów, odtwarzanie środowiska i pełna rotacja poświadczeń. Skala kompromitacji pokazuje jednak, iż przy incydentach CI/CD nie wystarcza wyłączenie jednego komponentu. Konieczna jest całościowa rewizja zaufania do runnerów, sekretów, tokenów, repozytoriów i procesów publikacji.

Konsekwencje / ryzyko

Najbardziej oczywistą konsekwencją jest utrata poufności kodu źródłowego. Dla dostawcy technologii oznacza to ryzyko ujawnienia logiki biznesowej, architektury bezpieczeństwa, planów produktowych oraz rozwiązań powiązanych z AI. W praktyce może to wpłynąć zarówno na przewagę konkurencyjną, jak i bezpieczeństwo przyszłych wdrożeń.

Z perspektywy klientów niebezpieczna jest możliwość analizy przejętego kodu pod kątem błędów, podatności logicznych i słabych punktów integracyjnych. choćby jeżeli sam incydent nie oznacza automatycznej kompromitacji środowisk klientów, to zdobyte repozytoria mogą posłużyć do przygotowania precyzyjnych ataków wtórnych, kampanii phishingowych lub prób podszywania się pod dostawcę.

Dodatkowe zagrożenie wynika z przejęcia kluczy chmurowych. Każde naruszenie obejmujące poświadczenia AWS należy traktować jako incydent wieloetapowy, który może prowadzić do utrzymania dostępu, eskalacji uprawnień, eksfiltracji danych oraz przygotowania mechanizmów ponownego wejścia do środowiska.

Rekomendacje

Organizacje korzystające z GitHub Actions, skanerów bezpieczeństwa i zewnętrznych komponentów CI/CD powinny potraktować ten przypadek jako sygnał do pilnego przeglądu własnych pipeline’ów. Szczególnie ważna jest pełna inwentaryzacja używanych akcji, pinowanie ich do niezmiennych identyfikatorów oraz ograniczenie korzystania z komponentów pobieranych dynamicznie.

• Rotować wszystkie sekrety, tokeny i klucze, które mogły być dostępne dla workflowów lub runnerów.
• Ograniczyć uprawnienia zgodnie z zasadą najmniejszych przywilejów.
• Zastępować długowieczne sekrety dostępem czasowym i federacyjnym tam, gdzie to możliwe.
• Monitorować masowe klonowanie repozytoriów, nietypowy eksport artefaktów i zmiany w workflowach.
• W chmurze śledzić użycie kluczy, tworzenie nowych tożsamości oraz próby eskalacji uprawnień.
• Przygotować osobne procedury reagowania na incydenty obejmujące runnerów, workflowy i proces wydawniczy.

Równie ważne jest wdrożenie zasad hardeningu dla GitHub Actions oraz dobrych praktyk IAM w chmurze. W nowoczesnym DevSecOps ochrona łańcucha dostaw systemu powinna być traktowana jako jeden z fundamentów bezpieczeństwa organizacji.

Podsumowanie

Incydent Cisco pokazuje, iż ataki na łańcuch dostaw systemu nie kończą się na kompromitacji pojedynczego narzędzia. Wystarczy naruszenie jednego komponentu używanego w pipeline’ach, aby otworzyć drogę do przejęcia poświadczeń, dostępu do środowisk chmurowych i masowej eksfiltracji kodu źródłowego.

Dla organizacji to jasny sygnał, iż środowiska CI/CD należy traktować jak infrastrukturę krytyczną. Twarde zabezpieczenia, ścisłe zarządzanie sekretami, monitoring anomalii oraz gotowe procedury reagowania stają się niezbędne, jeżeli firma chce ograniczyć skutki podobnych operacji w przyszłości.

Źródła

1. BleepingComputer — Cisco source code stolen in Trivy-linked dev environment breach — https://www.bleepingcomputer.com/news/security/cisco-source-code-stolen-in-trivy-linked-dev-environment-breach/
2. BleepingComputer — Trivy vulnerability scanner breach pushed infostealer via GitHub Actions — https://www.bleepingcomputer.com/news/security/trivy-vulnerability-scanner-breach-pushed-infostealer-via-github-actions/
3. GitHub Docs — Security hardening for GitHub Actions — https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions
4. AWS Documentation — IAM best practices — https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
5. NIST Secure Software Development Framework (SSDF) — https://csrc.nist.gov/pubs/sp/800/218/final