W miarę jak cykl życia łańcucha dostaw oprogramowania postępuje od kodu źródłowego do wykonywalnych artefaktów, etap kompilacji stanowi punkt krytyczny. Jednak ta faza transformacji jest również podatna na szereg zagrożeń, które mogą zagrozić integralności i bezpieczeństwu oprogramowania. build security. Te zagrożenia mogą przedostać się do procesu kompilacji za pomocą różnych metod, w tym poprzez obejście ustalonych zabezpieczeń. CI/CD pipeline, modyfikowanie kodu po kontroli kodu źródłowego, naruszanie bezpieczeństwa samego procesu kompilacji lub manipulowanie repozytoriami artefaktów. W tym wpisie na blogu dogłębnie analizujemy te zagrożenia i analizujemy najczęstsze ataki na łańcuch dostaw oprogramowania. Ten wpis kontynuuje naszą serię blogów, w której zgłębiamy… software supply chain security przez SDLC.
Etap kompilacji w cyklu życia oprogramowania
Etap kompilacji w cyklu życia łańcucha dostaw oprogramowania obejmuje proces przekształcania kodu źródłowego w wykonywalne artefakty oprogramowania. Etap ten obejmuje kompilację, linkowanie i pakowanie kodu źródłowego, a także generowanie pakietów instalacyjnych i plików konfiguracyjnych.
Build security Zagrożenia to luki w zabezpieczeniach, które mogą umożliwić atakującemu wprowadzenie nieautoryzowanych zmian w oprogramowaniu podczas procesu kompilacji bez modyfikowania kodu źródłowego. Zagrożenia te mogą zostać wprowadzone na różne sposoby, takie jak włamanie się do środowiska kompilacji lub wykorzystanie luk w zabezpieczeniach narzędzi do kompilacji.

Najczęstsze zagrożenia dla łańcucha dostaw oprogramowania – ataki na kompilacje
Obejście CI/CD
Chodzi tu o praktykę obchodzenia ustalonych przepisów CI/CD (ciągła integracja i ciągłe dostarczanie) pipeline do bezpośredniego tworzenia i publikowania oprogramowania bez przechodzenia przez rygorystyczne procesy testowania, weryfikacji i audytu, które są zazwyczaj egzekwowane przez oficjalne pipelineMożna to zrobić, ręcznie budując oprogramowanie poza CI/CD środowiska lub za pomocą narzędzi lub skryptów, które umożliwiają nieautoryzowane modyfikacje procesu kompilacji. Przykładem tego typu ataku wektorowego był Atak JenkinsaW 2022 roku hakerzy zinfiltrowali kompilację pipeline popularnego projektu oprogramowania open source o nazwie Jenkins. Hakerzy wstrzyknęli złośliwy kod do pliku Jenkinsfile, czyli skryptu definiującego proces kompilacji. Złośliwy kod pozwolił hakerom ominąć CI/CD pipelinekontrole bezpieczeństwa i wstrzykują swój kod do procesu kompilacji. Kod ten jest następnie wykonywany w systemach organizacji, które zainstalowały oprogramowanie.
Modyfikuj kod po kontroli źródła
Praktyka ta polega na dokonywaniu nieautoryzowanych zmian w kodzie źródłowym po jego utworzeniu. commitPrzekierowano do zaufanego systemu kontroli wersji (SCS), a następnie skompilowano oprogramowanie przy użyciu zmodyfikowanego kodu. Można to zrobić, modyfikując kod bezpośrednio na stacji roboczej programisty lub używając zewnętrznych narzędzi lub skryptów do wstrzyknięcia złośliwego kodu do procesu kompilacji. Przykładem takiego ataku wektorowego był atak na GitLab w 2022 roku. Hakerzy zinfiltrowali system kompilacji. pipeline of GitLabHakerzy wstrzyknęli złośliwy kod do GitLabu CI/CD pipeline, które jest narzędziem automatyzującym build security Proces. Złośliwy kod umożliwił hakerom modyfikację kodu po jego wprowadzeniu do systemu kontroli wersji. Umożliwiło im to wstrzyknięcie kodu do oprogramowania, który następnie był wykonywany w systemach organizacji, które zainstalowały oprogramowanie.
Proces kompilacji kompromisowej
Polega to na manipulowaniu lub modyfikowaniu samego procesu kompilacji, albo poprzez bezpośredni dostęp do środowiska kompilacji, albo poprzez wykorzystanie luk w zabezpieczeniach narzędzi kompilacji lub zależności firm trzecich. Można tego dokonać w celu wprowadzenia złośliwego kodu do wyników kompilacji, manipulacji pochodzeniem kompilacji lub całkowitego zakłócenia procesu kompilacji. Najbardziej znanym przykładem tego wektora ataku był… Atak SolarWindsAtakujący uzyskał nieautoryzowany dostęp do platformy kompilacji SolarWinds, systemu używanego do kompilowania i pakowania oprogramowania SolarWinds Orion. Skrypt ten wstrzyknął złośliwy kod do skompilowanego oprogramowania SolarWinds Orion. Gdy użytkownicy zainstalowali zainfekowane oprogramowanie, złośliwy kod został wykonany w ich systemach, dając atakującemu nieautoryzowany dostęp do nich. Atakujący był również w stanie ukraść poufne dane z ich systemów, takie jak dane uwierzytelniające, własność intelektualną i informacje o klientach.
Repozytorium artefaktów kompromisowych
Odnosi się to do nieautoryzowanego dostępu lub manipulacji repozytorium artefaktów, w którym przechowywane są pakiety oprogramowania i pliki binarne w celu dystrybucji do użytkowników wewnętrznych lub zewnętrznych. Atakujący mogą wykorzystać tę lukę w zabezpieczeniach, aby wprowadzić złośliwy kod, manipulować autentycznością oprogramowania lub zakłócić proces wdrażania. Przykładem takiego ataku wektorowego jest… RubyGems w 2022 rokuHakerzy zinfiltrowali repozytorium artefaktów RubyGems. Zastąpili legalny artefakt złośliwym, który następnie został pobrany przez tysiące organizacji tworzących oprogramowanie w Ruby on Rails. Złośliwy artefakt umożliwił hakerom wykonanie dowolnego kodu w systemach organizacji, które zainstalowały oprogramowanie. Mogło to potencjalnie umożliwić im kradzież danych, instalację złośliwego oprogramowania lub zakłócenie działalności.
Uwagi końcowe
W miarę jak organizacje wdrażają praktyki rozwoju oprogramowania, które kładą nacisk na automatyzację i ciągłe dostarczanie, znaczenie bezpieczeństwa procesu tworzenia oprogramowania nigdy nie było większe. Wdrażając solidne środki bezpieczeństwa na każdym etapie tworzenia oprogramowania, organizacje mogą znacznie zmniejszyć ryzyko padnięcia ofiarą złośliwych ataków, które mogą naruszyć integralność i bezpieczeństwo ich oprogramowania.
Strategie opisane w tym wpisie na blogu i podane przykłady przypominają, że etap kompilacji stanowi wrażliwy punkt w łańcuchu dostaw oprogramowania. Organizacje powinny zwracać uwagę na te zagrożenia i wdrażać niezbędne środki bezpieczeństwa, aby chronić swoje oprogramowanie przed atakami. W ten sposób mogą zapewnić integralność, bezpieczeństwo i niezawodność swojego oprogramowania dla użytkowników i klientów.
Dołącz do naszej podróży w kierunku bezpiecznego ekosystemu oprogramowania
Nie przegap okazji, aby wyprzedzić konkurencję i unikać zagrożeń dla łańcucha dostaw oprogramowania. Subskrybuj naszego bloga już dziś i bądź pierwszą osobą, która otrzyma nasze najnowsze spostrzeżenia, zapewniając odporność i bezpieczeństwo swojej organizacji w obliczu ewoluujących zagrożeń. Razem możemy zbudować bardziej solidny i bezpieczny ekosystem oprogramowania dla wszystkich.
Obejrzyj naszą demonstrację wideo







