Zabezpiecz swój łańcuch dostaw oprogramowania na każdym etapie – od budowania po wdrożenie

Nie dopuszczaj do środowiska produkcyjnego obrazów kontenerów, które nie zostały przeskanowane, nie są podpisane lub zawierają podatności. W tym przewodniku pokazano, jak mechanizmy kontroli prywatnego rejestru, skanowanie podatności, podpisywanie artefaktów i polityki dopuszczania zasobów do klastra Kubernetes tworzą proces zapewniający egzekwowanie zasad bezpieczeństwa w całym łańcuchu dostaw oprogramowania. 
RozpocznijManaged Private Registry
Ilustracja nazw domen

Weryfikuj każdy element potoku

Bezpieczeństwo łańcucha dostaw oprogramowania oznacza ciągłą weryfikację wszystkich zależności, pakietów i artefaktów w procesie CI/CD. Zaufanie musi obejmować kod źródłowy, publicznie dostępne pakiety, technologie zewnętrzne, komponenty firm trzecich, elementy procesu budowania, rejestry oraz ostateczną wersję oprogramowania. Zagrożenie może pojawić się wskutek modyfikacji zależności lub naruszenia bezpieczeństwa procesów. Zacznij od zidentyfikowania każdego komponentu udostępnianego klientom i zweryfikowania go w oparciu o uznane ramy bezpieczeństwa, takie jak wytyczne NIST lub zasady bezpieczeństwa łańcucha dostaw oprogramowania (SSCS). Następnie zespoły mogą ustalić, na których etapach brakuje dowodów potwierdzających bezpieczeństwo, stosować praktyki bezpiecznego programowania i podpisywać powstałe artefakty za pomocą narzędzia Cosign. Takie podejście oparte na uznanych wytycznych pozwala egzekwować wymagania bezpieczeństwa w całym łańcuchu dostaw, zamiast polegać na pojedynczym punkcie kontroli. Każdy uczestnik procesu może prześledzić, jakie elementy wykorzystano podczas budowania oprogramowania, w jaki sposób z nimi postępowano i jakie dowody stanowią podstawę do wdrożenia.
[object Object]

Zapewnij wiarygodność wydań oprogramowania dzięki weryfikowalnym mechanizmom kontroli

Prywatne projekty Harbor, polityki skanowania Trivy, podpisywanie artefaktów za pomocą Cosign i europejska jurysdykcja
Community@2x.png
Ogranicz dostęp do rejestru
Cyber Security@2x.png
Blokuj obrazy ze znanymi podatnościami
Magnifying Glass Check@2x.png
Weryfikuj pochodzenie i odporność na zagrożenia

Chroń każdy etap, który może stać się celem ataku

Czym jest bezpieczeństwo łańcucha dostaw w nowoczesnym środowisku kontenerowym?

Czym jest bezpieczeństwo łańcucha dostaw w nowoczesnym środowisku kontenerowym? Obejmuje ono ochronę całego procesu – od kodu źródłowego i zależności pochodzących od firm trzecich, przez systemy budowania oprogramowania i przechowywanie obrazów kontenerów, aż po docelowe środowiska wdrożeniowe. Bezpieczeństwo łańcucha dostaw oprogramowania wymaga traktowania tych procesów jako wzajemnie powiązanych, ponieważ atak na jednym z początkowych etapów może osłabić wszystkie mechanizmy zabezpieczające na kolejnych etapach.

Ochrona repozytorium kodu źródłowego

Repozytorium kodu źródłowego jest oczywistym celem ataków. Atakujący może wykraść dane uwierzytelniające, zmodyfikować kod, wyłączyć regułę wymagającą przeglądu kodu lub wprowadzić zależność, która sprawia wrażenie wiarygodnej. Kontrolowane źródła pobierania oprogramowania, obowiązkowy przegląd kodu przez inną osobę i chronione gałęzie repozytorium stanowią pierwszą linię obrony. Zespoły powinny również przypinać wersje zależności oraz weryfikować sumy kontrolne, licencje i pochodzenie komponentów, zamiast dopuszczać do wykorzystywania zmieniających się elementów wejściowych przy każdym budowaniu oprogramowania. Kontrole te ograniczają ryzyko wprowadzenia do projektu złośliwego lub niezatwierdzonego oprogramowania pochodzącego od podmiotów zewnętrznych.

Ścieżki ataku na infrastrukturę budowania oprogramowania

Infrastruktura służąca do budowania oprogramowania może stać się celem ataków przeprowadzanych na różne sposoby. Przejęte przez atakujących agenty wykonawcze CI/CD (runnery), ujawnione poufne dane lub modyfikowalne obrazy bazowe mogą umożliwić zmianę artefaktu po zatwierdzeniu jego kodu źródłowego przez programistów. Izoluj procesy budowania oprogramowania, korzystaj z danych uwierzytelniających o krótkim okresie ważności i dokładnie rejestruj wszystkie elementy wykorzystywane w tych procesach. Takie podejście zwiększa bezpieczeństwo obrazów kontenerów, ułatwiając śledzenie nieoczekiwanych zmian w kodzie.

Mechanizmy kontroli między rejestrem a klastrem

Przekazywanie obrazów z rejestru do klastra wymaga niezależnych mechanizmów kontroli. Atakujący może podmienić zatwierdzony obraz, ponownie użyć starego tagu lub wykorzystać nadmiernie szerokie uprawnienia do wdrażania. Dostęp oparty na zasadzie najmniejszych uprawnień ogranicza zakres elementów, które poszczególne tożsamości mogą publikować lub pobierać. Niezmienne odwołania wiążą manifesty z konkretnymi obrazami, a narzędzie Kyverno może odrzucać wdrożenia, które nie mają wiarygodnego potwierdzenia zgodności lub naruszają wymagania bezpieczeństwa.

Skuteczne zarządzanie łańcuchem dostaw oprogramowania zaczyna się od inwentaryzacji. Dokumentuj biblioteki własne i pochodzące od podmiotów zewnętrznych, obrazy bazowe, licencje oraz narzędzia do budowania oprogramowania wykorzystywane przez każdą aplikację. Powiąż każdy wykaz składników oprogramowania (SBOM) z projektem, zatwierdzeniem zmian (commitem) i uruchomieniem procesu CI/CD, w którym powstał dany artefakt. Takie powiązanie pomaga zespołom ds. cyberbezpieczeństwa ustalić, których usług dotyczy naruszenie bezpieczeństwa wrażliwego komponentu. Wybierz narzędzie umożliwiające eksport dowodów weryfikacji w formacie nadającym się do automatycznego odczytu oraz automatyczne porównywanie kolejnych wydań oprogramowania. Ewidencja komponentów powinna być aktualizowana na bieżąco wraz z rozwojem oprogramowania, a nie opierać się na okresowych aktualizacjach ręcznych. Wyznacz osobę odpowiedzialną za kwestie związane z zależnościami, obsługę wyjątków i działania naprawcze, aby zakres odpowiedzialności był jasno określony.
Przeprowadzaj testy bezpieczeństwa na odpowiednio wczesnym etapie, aby programiści otrzymywali wyniki umożliwiające podjęcie konkretnych działań. Automatyzacja procesu CI/CD umożliwia sprawdzanie zależności kodu źródłowego, warstw obrazów kontenerów i konfiguracji przed przekazaniem artefaktów do kolejnego etapu. Ustal progi skanowania podatności CVE na podstawie stopnia narażenia poszczególnych obciążeń na zagrożenia i ich znaczenia biznesowego, a wyniki wskazujące na niespełnienie wymagań przekazuj odpowiedzialnemu zespołowi. Negatywny wynik kontroli powinien blokować przejście do kolejnego etapu, a nie jedynie powodować wygenerowanie alertu, którego nikt nie przeczyta. Dokumentuj wykryty problem, pakiet, którego dotyczy, poziom jego istotności oraz zatwierdzony sposób postępowania. Dokumentacja ta pomaga zapewnić jakość wydań oprogramowania i spójność decyzji dotyczących bezpieczeństwa łańcucha dostaw oprogramowania we wszystkich aplikacjach.
Podpisywanie obrazów pozwala potwierdzić, w ramach którego kontrolowanego procesu zatwierdzono dany artefakt. Po pomyślnym zakończeniu wymaganych testów podpisuj każdy obraz, identyfikując go za pomocą niezmiennego skrótu (digest), a następnie zachowuj informacje o jego pochodzeniu, wskazujące wersję kodu źródłowego, system odpowiedzialny za budowanie artefaktu oraz proces CI/CD (workflow), w którym powstał. Nie ograniczaj się do podpisywania obrazów identyfikowanych za pomocą modyfikowalnych tagów, ponieważ dany tag może później wskazywać na inną zawartość. Oddziel uprawnienia do podpisywania artefaktów od ogólnych uprawnień dostępu przyznawanych programistom i wykorzystywanych w procesie CI/CD. Do weryfikacji należy używać zaufanych tożsamości lub kluczy publicznych wskazanych przez Twoją organizację. Dzięki temu proces budowania oprogramowania przejęty przez atakujących nie będzie mógł wygenerować akceptowanych dowodów potwierdzających wiarygodność artefaktu, jeśli nie spełni również wymagań polityki podpisywania.
Kontroler dopuszczania (admission controller) w Kubernetes podejmuje ostateczną decyzję o dopuszczeniu obciążeń roboczych do klastra. Skonfiguruj go tak, aby odrzucał niepodpisane obrazy, obrazy pochodzące z niezatwierdzonych rejestrów, niespełniające kryteriów dotyczących podatności lub pozbawione informacji potwierdzających ich pochodzenie. Kyverno i OPA Gatekeeper umożliwiają definiowanie tych warunków w postaci polityk objętych kontrolą wersji. Przed rozpoczęciem egzekwowania tych polityk w środowisku produkcyjnym przetestuj każdą regułę z wykorzystaniem reprezentatywnych obciążeń roboczych. Najpierw uruchom polityki w trybie audytu, aby zidentyfikować uzasadnione wyjątki, a następnie przełącz dopracowane mechanizmy kontroli w tryb blokowania. Utrzymuj zatwierdzoną procedurę obsługi wyjątków, określając dla każdego wyjątku osobę odpowiedzialną, uzasadnienie i datę wygaśnięcia. Dzięki temu klaster może konsekwentnie weryfikować dowody potwierdzające bezpieczeństwo wydania, nawet jeśli wcześniejszy mechanizm kontroli został ominięty lub nieprawidłowo skonfigurowany.
Skuteczne zarządzanie łańcuchem dostaw oprogramowania zaczyna się od inwentaryzacji. Dokumentuj biblioteki własne i pochodzące od podmiotów zewnętrznych, obrazy bazowe, licencje oraz narzędzia do budowania oprogramowania wykorzystywane przez każdą aplikację. Powiąż każdy wykaz składników oprogramowania (SBOM) z projektem, zatwierdzeniem zmian (commitem) i uruchomieniem procesu CI/CD, w którym powstał dany artefakt. Takie powiązanie pomaga zespołom ds. cyberbezpieczeństwa ustalić, których usług dotyczy naruszenie bezpieczeństwa wrażliwego komponentu. Wybierz narzędzie umożliwiające eksport dowodów weryfikacji w formacie nadającym się do automatycznego odczytu oraz automatyczne porównywanie kolejnych wydań oprogramowania. Ewidencja komponentów powinna być aktualizowana na bieżąco wraz z rozwojem oprogramowania, a nie opierać się na okresowych aktualizacjach ręcznych. Wyznacz osobę odpowiedzialną za kwestie związane z zależnościami, obsługę wyjątków i działania naprawcze, aby zakres odpowiedzialności był jasno określony.

Wyznacz osoby odpowiedzialne za cztery priorytetowe obszary zarządzania

Zarządzanie zaufanym kodem i dostawcami

Wyznaczony lider powinien określić kryteria uznawania źródeł i dostawców za zaufanych, korzystając ze wsparcia zespołów ds. zakupów, inżynierii i bezpieczeństwa. Wykorzystuj wytyczne SLSA do zwiększania integralności procesu budowania oprogramowania i zapewniania możliwości weryfikacji pochodzenia artefaktów, nie zakładając przy tym osiągnięcia określonego poziomu SLSA. Dostosuj zakres przeglądów do wielkości organizacji i poziomu ryzyka związanego z łańcuchem dostaw oprogramowania.

Egzekwowanie polityk i infrastruktura zgodna z wymaganiami

Osoby odpowiedzialne za bezpieczeństwo i platformę powinny przekładać obowiązki związane z zapewnieniem zgodności z wymaganiami na mierzalne mechanizmy egzekwowania polityk obejmujące kod, środowisko chmurowe i infrastrukturę. Określ, kto może zatwierdzać wyjątki, jakie dowody musi przedstawić i w jaki sposób mechanizmy kontroli spełniają wymagania wewnętrzne.

Dokumentacja, audyty i dowody

Wyznacz osobę odpowiedzialną za prowadzenie dokumentacji dotyczącej podejmowanych decyzji, zależności i zmian w mechanizmach kontroli. Regularne audyty powinny weryfikować, czy dokumentacja odzwierciedla rzeczywiste praktyki operacyjne. Zapewnij osobom przeprowadzającym przeglądy odpowiednie wsparcie, aby mogły ustalić, kto odpowiada za dany problem, którego wydania oprogramowania on dotyczy i w jaki sposób został rozwiązany.

Gotowość do reagowania na incydenty i odpowiedzialność za działania naprawcze

Osoba kierująca zespołem ds. bezpieczeństwa powinna skoordynować role związane z reagowaniem na incydenty odpowiednio wcześnie, zanim atakujący wystawi je na próbę. Utrzymuj plan postępowania w przypadku potencjalnych incydentów, obejmujący ich wstępną ocenę i klasyfikację, powstrzymywanie zagrożeń, komunikację z interesariuszami oraz przywracanie normalnego działania. Dla każdego działania należy wyznaczyć osobę odpowiedzialną, zapewnić odpowiednie zasoby i ustalić terminy dostosowane do poziomu ryzyka, na jakie narażona jest organizacja.

Zarządzaj platformą Harbor w oparciu o cztery filary bezpieczeństwa

Precyzyjnie kontroluj dostęp

Harbor obsługuje kontrolę dostępu opartą na rolach (RBAC) na poziomie projektów i zespołów, co umożliwia rozdzielenie obciążeń roboczych i zakresów odpowiedzialności w przedsiębiorstwie. Twórz konta robotów o ograniczonych uprawnieniach do przesyłania (push) i pobierania (pull) obrazów w procesie CI/CD, zamiast udostępniać dane uwierzytelniające użytkowników o szerokich uprawnieniach. Każdej tożsamości przypisz jeden konkretny cel, regularnie zmieniaj powiązany z nią sekret uwierzytelniający i usuwaj nieużywane uprawnienia dostępu. Takie postępowanie ogranicza skutki ujawnienia danych uwierzytelniających, a jednocześnie zapewnia bezpieczeństwo podczas codziennego publikowania obrazów.

Wykrywaj niebezpieczne komponenty na bieżąco

Połącz ciągłe skanowanie za pomocą Trivy z analizą składu oprogramowania (SCA) i zarządzaniem zależnościami. Narzędzia te wykrywają znane podatności, nieaktualne pakiety oraz oznaki obecności złośliwego kodu w poszczególnych komponentach. Dla każdego wydania przygotowuj przejrzysty raport zawierający poziom istotności wykrytych problemów, miejsce ich występowania oraz status działań naprawczych. Dzięki temu zespoły mogą odróżniać problemy blokujące wdrożenie od zaakceptowanych wyjątków oraz identyfikować sytuacje, w których nowe informacje o zagrożeniach dotyczą przechowywanych artefaktów.

Zintegruj procesy tworzenia oprogramowania

Połącz platformę z GitLab CI, Tekton i innymi zatwierdzonymi procesami tworzenia oprogramowania. Egzekwuj polityki bezpieczeństwa bezpośrednio w procesie CI/CD, aby negatywny wynik kontroli dostarczał użytecznych informacji zwrotnych przed przekazaniem artefaktu do kolejnego etapu. Odwołania w systemie zarządzania kodem źródłowym (SCM) powinny umożliwiać powiązanie każdego artefaktu z odpowiednim commitem, uruchomieniem procesu budowania oprogramowania i osobą odpowiedzialną. Dzięki temu zespoły DevSecOps dysponują spójną dokumentacją, zamiast dowodów rozproszonych w różnych systemach.

Przygotuj procedury reagowania na incydenty

Utrzymuj aktualny plan reagowania na incydenty związane z przejęciem danych uwierzytelniających, obrazami stwarzającymi zagrożenie dla bezpieczeństwa oraz nieskutecznymi mechanizmami kontroli. Określ, kto odpowiada za wstrzymanie dystrybucji, wycofanie wersji, której dotyczy incydent, sprawdzenie historii dostępu i zatwierdzenie przywrócenia działania. Każdy alert musi mieć przypisaną osobę odpowiedzialną i określoną ścieżkę reagowania – samo generowanie alertów nie zmniejsza ryzyka. Przeprowadzaj ćwiczenia, aby upewnić się, że zespoły ds. bezpieczeństwa i zarządzania platformą potrafią znaleźć odpowiedni raport, odizolować zagrożoną zawartość i przekazać podjęte decyzje. Ten filar operacyjny pozwala przekładać wykrywanie zagrożeń na szybkie działania w całej platformie dostarczania oprogramowania.

Zachowuj wiarygodne dowody potwierdzające bezpieczeństwo każdego wydania

Przejrzystość procesu wydawania oprogramowania zależy od dokumentacji potwierdzającej, kto utworzył dany artefakt, skąd on pochodzi i w jaki sposób został przetestowany. Generuj i przechowuj wyniki skanowania za pomocą Trivy, dane z wykazów składników oprogramowania (SBOM) oraz podpisy dla każdego obrazu kontenera i zestawu chartów Helm. Dzięki temu organizacja może identyfikować poszczególne rodzaje zawartości i badać potencjalne problemy związane z bezpieczeństwem. Zintegruj kontrole z GitLab CI, aby automatycznie przekazywać programistom informacje zwrotne przed wprowadzeniem oprogramowania do środowiska objętego kontrolą. Systematyczne przeprowadzanie testów pomaga również zwiększać świadomość bezpieczeństwa, ponieważ pozwala zrozumieć, dlaczego dane wydanie oprogramowania nie przeszło kontroli. Chroń klucze służące do podpisywania za pomocą Cosign, korzystając z usługi OVHcloud Key Management Service i pamięci masowej zabezpieczonej modułami HSM zgodnymi ze standardem FIPS 140-2. Scentralizowane zarządzanie kluczami pomaga zapewnić, że każdy wygenerowany podpis jest powiązany z odpowiednio zabezpieczonym materiałem kryptograficznym, a nie z ujawnionym sekretem wykorzystywanym w procesie CI/CD.
[object Object]
Egzekwuj politykę wydawania obrazów kontenerów za pomocą OVHcloud
Zbuduj kontrolowaną ścieżkę od artefaktów generowanych w procesie CI/CD po wdrożenie w Kubernetes, korzystając z usług Managed Private Registry i Managed Kubernetes Service. Sprawdź, w jaki sposób weryfikacja obrazów w rejestrze, dokumentacja potwierdzająca bezpieczeństwo wydań oraz egzekwowanie polityk na poziomie klastra mogą zapobiec wdrożeniu w środowisku produkcyjnym obrazów, które nie zostały przeskanowane, nie są podpisane lub zawierają podatności. Poznaj usługę Managed Private Registry, a następnie oceń możliwości integracji z Kubernetes pod kątem swoich obciążeń roboczych, modelu polityk bezpieczeństwa i podziału odpowiedzialności operacyjnej.
Poznaj usługę rejestru