Przez dekady zaszyte w kodzie klucze leżały w prywatnych archiwach, często niezauważone przez nikogo poza wąskim gronem programistów. Tę dynamikę bezpowrotnie zmieniła ekspansja agentów AI. W jaki sposób?
Od dłuższego czasu temat bezpieczeństwa sztucznej inteligencji nie schodzi z czołówek portali biznesowych, a głośne afery związane z wyciekami danych boleśnie obrazują rzeczywistą skalę zagrożenia. Programistyczne drogi na skróty, które przez lata „uchodziły na sucho” w pozornie zamkniętych archiwach, dziś stają się tykającą bombą. W momencie, gdy asystenci i autonomiczni agenci AI zyskują wgląd w firmowy kod, dawne zaniedbania potrafią błyskawicznie sparaliżować operacyjnie całe przedsiębiorstwo i wygenerować gigantyczne straty finansowe. Co można zrobić, żeby uchronić się przed poważnymi konsekwencjami?
Iluzja bezpieczeństwa
Powszechne jest przekonanie, że incydenty bezpieczeństwa dotyczą wyłącznie organizacji, które zawsze oszczędzały na bezpieczeństwie, nie interesując się tym tematem i lekceważąc zagrożenie. Doświadczenie rynkowe pokazuje zupełnie inny obraz - podatności wynikające ze źle zabezpieczonych repozytoriów programistycznych dotykają podmioty o ugruntowanej pozycji rynkowej i dużych zespołach.
Nie tak dawno usłyszeliśmy o incydentach w podmiotach takich jak MyDoctor (MyDr) czy platforma Fakturownia. W obu tych przypadkach atakujący zdołali naruszyć obwód ochronny organizacji poprzez dostęp do repozytoriów w serwisie GitHub. Konsekwencje wycieków danych poszkodowani mogą odczuć za jakiś czas, a straty są trudne do oszacowania.
Jednak konsekwencje mogą mieć również natychmiastowy wymiar czysto finansowy. Wyciek kluczy API (na przykład do modeli sztucznej inteligencji pokroju OpenAI czy Gemini) pozwala nieuprawnionym podmiotom generować gigantyczne zużycie infrastruktury na koszt ofiary. Na rynku znane są udokumentowane przypadki, w których niepowstrzymany w porę hacker potrafił w ciągu zaledwie jednego do dwóch dni wygenerować rachunek sięgający 100 000 dolarów za pośrednictwem przechwyconych danych uwierzytelniających.
Dlaczego problem pojawił się teraz?
Podłączenie narzędzi AI (np. GitHub Copilot) do firmowych repozytoriów de facto sprawia, że kod przestaje być w pełni odizolowany i tak naprawdę w pełni prywatny. Jeśli programiści korzystają z niefirmowych kont lub niezweryfikowanych narzędzi, wrażliwe dane mogą zostać wchłonięte przez algorytmy uczenia maszynowego.
Coraz częściej zespoły dopuszczają do pracy autonomiczne agenty AI działające w tzw. trybie YOLO (bez bieżącej autoryzacji każdego kroku przez człowieka). Dając modelowi swobodny dostęp do repozytoriów i baz danych, firma oddaje ster narzędziu, które nie posiada świadomości ryzyka prawnego ani biznesowego.
Rośnie również liczba incydentów, w których złośliwe instrukcje zaszyte w promptach bądź zewnętrznych rozszerzeniach nakazują agentowi przeszukanie dostępnego mu repozytorium, wyekstrahowanie kluczy dostępowych i przesłanie ich na zewnętrzne serwery.
Jak to wygląda w praktyce?
Opiszemy to na przykładzie firmy z branży napojów. Platforma rozwijana od 15–20 lat, której architektura rozrosła się do kilkudziesięciu (od 30 do 50) niezależnych repozytoriów kodu w architekturze mikroserwisowej.
W projekcie przez lata brakowało jednolitych procedur kontrolnych. Dziesiątki programistów na przestrzeni kilkunastu lat tworzyły własne konta dostępu do chmury Amazon Web Services (AWS) i na stałe wpisywały dane logowania w pliki konfiguracyjne. W systemie zidentyfikowano ponad 30 indywidualnych profili dostępowych z uprawnieniami administracyjnymi.
Najpoważniejszym błędem architektonicznym okazało się jednak umieszczenie środowiska testowego (staging) oraz środowiska produkcyjnego w ramach tego samego konta chmurowego. Wyciek jakiegokolwiek klucza z luźniej traktowanego środowiska testowego automatycznie dawał dostęp do bazy danych klientów i pełnej infrastruktury produkcyjnej.
Kiedy zautomatyzowane narzędzie skanujące wykryło, ile tak naprawdę kluczy pozostawiono w kodzie, reakcją był… natychmiastowy kryzys decyzyjny. W tej firmie wprowadzono całkowity zakaz wdrażania zmian, a cały zespół deweloperski został oddelegowany do gaszenia pożaru.
Kluczowa okazała się specyfika narzędzi kontroli wersji (Git): usunięcie klucza z aktualnego pliku nie kasuje go z historii projektu. Każdy commit sprzed 5 czy 10 lat nadal zawierał poufne hasła. Neutralizacja zagrożenia wymagała głębokiego czyszczenia historii, rotacji dziesiątek poświadczeń i ponownego wdrożenia wszystkich aplikacji, co sparaliżowało pracę programistyczną na pełne dwa tygodnie.
Problem nie dotyczy tylko działu IT
Wyciek danych to bezpośrednie uderzenie w bilans przedsiębiorstwa, którego najboleśniejszym kosztem rzadko bywają same wydatki na infrastrukturę IT. W cyfrowej gospodarce nadrzędną walutą pozostaje zaufanie, a informacja o kompromitacji systemów błyskawicznie obiega rynek. Odbudowa nadszarpniętej reputacji trwa latami, podczas gdy klienci – w obawie o własne bezpieczeństwo – bez wahania odchodzą do konkurencji. Co gorsza, niekontrolowane ujawnienie kluczy autoryzacyjnych nie zamyka się wyłącznie wewnątrz organizacji. Często staje się ono wytrychem do wrażliwych danych kontrahentów i użytkowników końcowych.
Jeśli przestępcy wykorzystają przechwycone poświadczenia do przejęcia kont, kradzieży tożsamości czy nadużyć finansowych, firma staje się bezpośrednio współodpowiedzialna za realne, życiowe straty swoich odbiorców.
Drugim ważnym aspektem jest niedopełnienie obowiązków wynikających z prawa. Wdrożenie nowej unijnej dyrektywy NIS 2 oraz rygorystyczne egzekwowanie RODO stawiają sprawę jasno - brak procedur zarządzania kluczami i podatnościami to bezpośrednie naruszenie obowiązku zachowania „należytej staranności”. Ewentualny wyciek oznacza kary finansowe liczone w milionach euro lub procentach globalnego obrotu.
Warto wspomnieć też o braku zgodności z normami (np. ISO 27001). Obecność jawnych poświadczeń w archiwach kodu unieważnia deklaracje bezpieczeństwa informacji i grozi utratą certyfikacji, co często wyklucza organizację z przetargów korporacyjnych.
Na szali leży również sama własność intelektualna. Autorski kod źródłowy, architektura systemów oraz unikalne algorytmy to kapitał budowany latami, decydujący o rynkowej przewadze. Dopuszczenie do ich nieautoryzowanego przejęcia lub wycieku niweczy wielomilionowe inwestycje w rozwój technologiczny i potrafi z dnia na dzień pozbawić przedsiębiorstwo jego fundamentalnej wartości rynkowej.
Lepiej zapobiegać, niż leczyć
Jeśli masz wątpliwości, czy w Waszych repozytoriach nie kryją się dawne luki, albo potrzebujesz świeżego spojrzenia na kod z zewnątrz – sprawdzonym rozwiązaniem jest niezależny audyt bezpieczeństwa.
Alternatywą jest czekanie na rozwój wydarzeń z nadzieją, że „jakoś to będzie”. W razie incydentu rachunek za zespół śledczy, kancelarię prawną i straty reputacyjne będzie jednak wielokrotnie wyższy niż koszt jakiejkolwiek wcześniejszej weryfikacji. Profilaktyka po prostu kalkuluje się znacznie lepiej niż usuwanie skutków kryzysu.
