Wycieki kodu źródłowego i luki w łańcuchu dostaw

W marcu 2022 roku hakerska grupa Lapsus$ opublikowała prawie 190 GB kodu źródłowego Samsunga – razem z algorytmami biometrycznymi, kodem TrustZone i źródłami bootloaderów. Tydzień później te same osoby trafiły do systemów Nvidii. W obu przypadkach firmy dowiedziały się o problemie z mediów, nie z własnych systemów monitorowania. Ten jeden szczegół mówi więcej o stanie nadzoru nad łańcuchem dostaw oprogramowania niż niejeden raport branżowy.


Wyciek kodu to nie wstyd – to mapa dla atakujących


Gdy kod źródłowy trafia w niepowołane ręce, atakujący dostają coś cenniejszego niż dane logowania: rozumieją architekturę. Widzą, jak działa autoryzacja, gdzie zakopane są klucze API, jak aplikacja waliduje dane wejściowe i – co najważniejsze – gdzie developer zostawił sobie komentarz „TODO: fix later”. Te miejsca często czekają na swój moment latami.


GitGuardian w raporcie State of Secrets Sprawl 2023 odnotował ponad 10 milionów sekretów wykrytych w publicznych repozytoriach GitHub – kluczy API, tokenów dostępu, haseł wbudowanych w commity. Spora część pochodzi od firm, które albo nie wiedzą, że je opublikowały, albo zakładają, że „nikt nie patrzy”. Ktoś zawsze patrzy.


Wyciek kodu Twitcha w październiku 2021 roku (ponad 128 GB danych) ujawnił nie tylko źródła platformy, ale też wewnętrzne narzędzia i dane wypłat dla streamerów. Nie dlatego, że Twitch był wyjątkowo niedbały – ale dlatego, że tego rodzaju incydenty zdarzają się wszędzie tam, gdzie nie ma systemu wykrywania anomalii w dostępach do repozytoriów.


Łańcuch dostaw jest tak mocny jak jego najsłabsze ogniwo


Nowoczesna aplikacja webowa to rzadko kiedy kod napisany od zera. To kilkaset zależności open source, biblioteki firm trzecich, integracje z zewnętrznymi API i pakiety instalowane przez npm, pip czy Maven. Każde z tych ogniw może być kompromitowane – i historycznie bywało.


Atak na SolarWinds w 2020 roku dotknął blisko 18 tysięcy organizacji – w tym agencje rządowe USA – bo atakujący nie włamali się bezpośrednio do celów. Zainfekowany update platformy Orion trafił do klientów jak każdy normalny patch. W marcu 2024 roku odkryto backdoor w bibliotece XZ Utils (CVE-2024-3094): przez niemal dwa lata cierpliwie rozwijał ją podstawiony deweloper, działający pod przykrywką zaangażowanego wolontariusza open source. To nie były ataki na systemy – to były ataki na zaufanie.


Wyciek kodu źródłowego wpisuje się w ten sam schemat zagrożeń. Jeśli atakujący zna wnętrze biblioteki używanej jako zależność przez dziesiątki firm, może szukać luk z precyzją chirurga – bez skanowania portów, bez hałasu, bez zostawiania śladów w logach sieciowych.


Nikt nie wie do końca, co tak naprawdę uruchamia


Tu leży sedno problemu wskazanego przez Dark Reading: fundamentalny brak nadzoru. Nie chodzi tylko o to, że kod wycieka – chodzi o to, że organizacje nie mają mechanizmów, które pozwoliłyby im w ogóle zauważyć, że coś jest nie tak. Brak SBOM (Software Bill of Materials), brak podpisywania artefaktów, brak monitorowania anomalii w pipeline CI/CD – to nie są rzadkości w branży, to wciąż powszechny standard.


SBOM to w uproszczeniu lista składników oprogramowania – coś w rodzaju etykiety wartości odżywczych, ale dla kodu: wiadomo, co jest w środku, w jakiej wersji i skąd pochodzi. Prezydenckie rozporządzenie wykonawcze 14028 z 2021 roku nałożyło na dostawców rządowych w USA obowiązek dostarczania SBOM. W Europie analogiczne wymagania przynosi Cyber Resilience Act, który wszedł w życie w grudniu 2024 roku i daje producentom oprogramowania od 3 do 36 miesięcy na dostosowanie się – w zależności od kategorii produktu. Brzmi jak postęp. Problem w tym, że regulacje to papier, dopóki nie ma kultury organizacyjnej, która je faktycznie wypełnia.


Co realnie zmniejsza ryzyko – bez rewolucji budżetowej


Kilka praktyk, które działają i nie wymagają przepisywania całej infrastruktury:


  • Skanowanie sekretów w pipeline – narzędzia takie jak Gitleaks, Trufflehog czy GitHub Advanced Security wyłapują klucze API i tokeny przed commitem lub zaraz po nim. Integracja z CI/CD zajmuje kilka godzin.
  • SBOM od pierwszego dnia – generowanie listy zależności przez Syft, CycloneDX lub w formacie SPDX powinno być elementem każdego buildu, nie jednorazowym audytem co rok.
  • Podpisywanie artefaktów – Sigstore i cosign to darmowe narzędzia pozwalające zweryfikować, że publikowany pakiet pochodzi dokładnie z tego pipeline’u, z którego powinien.
  • Monitoring publicznych repozytoriów – zautomatyzowane systemy mogą wyłapywać przypadkowe publiczne commity zawierające fragmenty kodu firmowego lub osadzone sekrety w czasie bliskim rzeczywistemu.
  • Zasada least privilege w CI/CD – każdy krok buildu powinien mieć minimalne uprawnienia. Jeśli krok kompilacji nie potrzebuje dostępu do środowiska produkcyjnego, nie powinien go mieć – i nie powinno to być kwestią dobrej woli, tylko polityki technicznej.


Uczciwe zastrzeżenie: żadne z tych narzędzi nie eliminuje ryzyka całkowicie. Przy wystarczająco cierpliwym i zaawansowanym atakującym – takim jak ten stojący za backdoorem XZ Utils, który przez dwa lata budował zaufanie w projekcie open source – większość automatycznych zabezpieczeń zostaje po prostu ominięta. Narzędzia ograniczają ekspozycję, ale nie zastępują czujności ludzkiej.


Moja opinia


Problem nie jest techniczny – jest kulturowy. Większość deweloperów wie, że nie powinno się commitować kluczy API do repozytorium. Mimo to GitGuardian rok w rok raportuje miliony takich przypadków. Narzędzia istnieją, standardy istnieją, regulacje nadchodzą – brakuje przekonania, że „nam to się nie przytrafi”. Wycieki kodu Samsunga czy Nvidii powinny być obowiązkowym case study na każdym onboardingu w działach IT i security. Nie dlatego, że te firmy były wyjątkowo niedbałe – ale dlatego, że jeśli im się zdarzyło, to naprawdę nikomu nie należy się immunitet. Cyber Resilience Act to krok w dobrą stronę, ale podejrzewam, że w wielu organizacjach SBOM stanie się kolejnym checkboxem do odfajkowania zamiast realnego narzędzia do zarządzania ryzykiem. I to będzie prawdziwy problem – nie samo prawo, ale stosunek do niego.


Jakie mechanizmy nadzoru nad kodem i zależnościami stosuje Twoja firma – i czy byłbyś w stanie odpowiedzieć na pytanie „co dokładnie uruchamiamy na produkcji?” bez kilkugodzinnego dochodzenia?



Źródło:
Dark Reading: Source Code Leaks Highlight Lack of Supply Chain Oversight

Podziel się artykułemFacebookXBlueskyWykopTelegram
Arycjusz

Piszę o technologii, cyberbezpieczeństwie i sztucznej inteligencji w CyberImpuls. Skomplikowane tematy tłumaczę prostym językiem, bez zbędnego żargonu. Najbardziej kręcą mnie nowe modele AI, prywatność w sieci i sprzęt, który realnie zmienia codzienność. Prywatność traktuję serio w sieci i u siebie. Dlatego piszę pod jednym, stałym podpisem.

https://cyberimpuls.pl