Eksplorowanie kluczowych punktów weryfikacji

Ukończone

Ciągła weryfikacja zabezpieczeń powinna być zintegrowana na każdym etapie od programowania przez środowisko produkcyjne, aby zapewnić bezpieczeństwo aplikacji w całym cyklu życia. Takie podejście przekształca sposób, w jaki zespoły bezpieczeństwa współpracują z zespołami deweloperskimi, co zmienia się od ręcznego zatwierdzania poszczególnych wersji do ciągłego monitorowania i audytu całego procesu CI/CD.

Przekształcanie dyskusji na temat zabezpieczeń

Tradycyjne podejście: Zespoły ds. zabezpieczeń ręcznie przeglądają i zatwierdzają każdą wersję przed jej przejściem do środowiska produkcyjnego. Tworzy wąskie gardła, opóźnia wydania i nie skaluje się przy użyciu nowoczesnych częstotliwości wdrażania.

Bezpieczne podejście DevOps: Zespoły ds. bezpieczeństwa akceptują sam proces CI/CD, a nie poszczególne wydania. Definiują wymagania dotyczące zabezpieczeń, implementują automatyczną walidację i stale monitorują proces. Zabezpieczenia stają się zintegrowane, zamiast stanowić oddzielną bramę.

Zalety tej zmiany:

• Wydania postępują automatycznie po spełnieniu kryterium bezpieczeństwa.
• Zespoły ds. zabezpieczeń koncentrują się na ulepszaniu procesu, a nie przeglądaniu poszczególnych zmian.
• Walidacja zabezpieczeń jest skalowana w celu obsługi wielu wdrożeń dziennie.
• Ścieżki audytu dokumentują weryfikację zabezpieczeń automatycznie.
• Problemy z zabezpieczeniami są wykrywane natychmiast, a nie w czasie przeglądu.

Krytyczne punkty walidacji w przepływie danych

Na poniższym diagramie przedstawiono krytyczne punkty weryfikacji w potoku ciągłej integracji/ciągłego wdrażania na potrzeby tworzenia aplikacji od podstaw:

Stopniowe wdrażanie: Narzędzia do walidacji zabezpieczeń można stopniowo implementować w zależności od platformy i etapu cyklu życia aplikacji. Takie podejście etapowe jest szczególnie ważne, jeśli produkt jest dojrzały i nie uruchamiano wcześniej weryfikacji zabezpieczeń w witrynie lub aplikacji. Wprowadzenie wszystkich kontroli zabezpieczeń jednocześnie może przeciążyć zespoły wynikami.

Strategia priorytetyzacji: Podczas implementowania weryfikacji zabezpieczeń w istniejących aplikacjach:

1. Zacznij od najważniejszych kontroli zabezpieczeń (wykrywanie wpisów tajnych, znane luki w zabezpieczeniach).
2. Najpierw należy uwzględnić wyniki w obszarach wysokiego ryzyka.
3. Stopniowo rozszerzaj zakres do dodatkowych kontroli zabezpieczeń.
4. Dostrajanie narzędzi w celu zmniejszenia liczby wyników fałszywie dodatnich przed dodaniem kolejnych testów.
5. Tworzenie zaufania deweloperów przez pokazanie wartości z automatyzacji zabezpieczeń.

Walidacja IDE i pull request

Sprawdzanie poprawności zabezpieczeń rozpoczyna się przed zatwierdzeniem przez deweloperów kodu do udostępnionego repozytorium. To podejście "przesunięcie w lewo" umożliwia wychwytywanie problemów tak wcześnie, jak to możliwe, gdy są najłatwiejsze i najmniej kosztowne do rozwiązania.

Testy zabezpieczeń na poziomie środowiska IDE

Statyczna analiza kodu w IDE: Narzędzia do analizy kodu statycznego zintegrowane z IDE stanowią pierwszą linię obrony, aby upewnić się, że luki w zabezpieczeniach nie są wprowadzane do procesu ciągłej integracji/ciągłego wdrażania.

Opinie w czasie rzeczywistym: Deweloperzy otrzymują natychmiastowe opinie na temat problemów z zabezpieczeniami podczas pisania kodu:

• Luki w zabezpieczeniach są wyróżnione bezpośrednio w edytorze kodu.
• Sugestie dotyczące bezpiecznych praktyk kodowania pojawiają się podczas pisania przez deweloperów.
• Szybkie poprawki typowych problemów z zabezpieczeniami są dostępne za pomocą jednego kliknięcia.
• Wyjaśnienia pomagają deweloperom zrozumieć, dlaczego niektóre wzorce są problematyczne.

Przykładowe narzędzia zabezpieczeń IDE:

• Rozszerzenia zabezpieczeń programu Visual Studio Code: Rozszerzenia, takie jak Snyk, SonarLint i GitHub Copilot, zapewniają wskazówki dotyczące zabezpieczeń podczas kodowania.
• Wtyczki zabezpieczeń Środowiska IntelliJ IDEA: Wtyczki ukierunkowane na zabezpieczenia analizują kod w czasie rzeczywistym.
• Analizatory zabezpieczeń programu Visual Studio: Wbudowane analizatory wykrywają problemy z zabezpieczeniami podczas programowania.

Zalety kontroli na poziomie środowiska IDE:

• Problemy są przechwytywane w trakcie pisania kodu, a nie dni lub tygodnie później.
• Deweloperzy uczą się bezpiecznych praktyk kodowania dzięki natychmiastowej informacji zwrotnej.
• Problemy z zabezpieczeniami zostały rozwiązane przed zatwierdzaniem kodu, co zmniejsza liczbę błędów potoków.
• Pętla sprzężenia zwrotnego jest mierzona w sekundach, a nie w godzinach lub dniach.

Kontrola zatwierdzeń w repozytorium

Zapobieganie wprowadzeniu bazy kodu podatnego na zagrożenia: Proces zatwierdzania kodu w centralnym repozytorium powinien mieć mechanizmy kontroli, które uniemożliwiają wprowadzanie luk w zabezpieczeniach.

Zasady gałęzi Git: Korzystanie z kontroli źródła Git w usłudze Azure DevOps, GitHub lub na podobnych platformach z zasadami gałęzi zapewnia proces zatwierdzania z zabezpieczeniami, który wymusza weryfikację zabezpieczeń.

Wymuszanie ochrony gałęzi: Włączenie zasad gałęzi w udostępnionych gałęziach (takich jak main lub develop) wymaga pull requesta do rozpoczęcia procesu scalania. Bezpośrednie zatwierdzenia do chronionych gałęzi są blokowane, dzięki czemu wszystkie zmiany kodu przechodzą przez proces weryfikacji.

Wymagania dotyczące żądania ściągnięcia: Żądania ściągnięcia powinny wymuszać kilka wymagań dotyczących zabezpieczeń:

Wymaganie dotyczące przeglądu kodu:

• Co najmniej jeden inny deweloper musi przejrzeć zmiany kodu.
• Ten przegląd ręczny ma kluczowe znaczenie dla identyfikowania problemów z zabezpieczeniami, które mogą zostać pominięte przez zautomatyzowane narzędzia.
• Recenzenci powinni w szczególności szukać zagadnień dotyczących zabezpieczeń, w tym:
  • Prawidłowa weryfikacja danych wejściowych.
  • Odpowiednie kontrole uwierzytelniania i autoryzacji.
  • Bezpieczna obsługa poufnych danych.
  • Poprawne użycie bibliotek zabezpieczeń i struktur.
  • Brak zakodowanych wpisów tajnych lub poświadczeń.

Połączenie elementu roboczego:

• Zatwierdzenia powinny być połączone z elementami roboczymi (historiami, zadaniami, usterkami) na potrzeby audytu.
• To powiązanie dokumentuje powód, dla którego wprowadzono zmianę w kodzie.
• Ścieżki audytu pomagają zespołom ds. zabezpieczeń zrozumieć kontekst zmian podczas dochodzenia zdarzeń.
• Łączenie elementów roboczych umożliwia śledzenie od wymagań aż po wdrożenie.

Wymaganie kompilacji Continuous Integration (CI):

• Proces kompilacji CI musi zakończyć się pomyślnie, zanim będzie można scalić pull request.
• Proces CI obejmuje automatyczne kontrole zabezpieczeń, co zostanie omówione w następnej sekcji.
• Nieudane kontrole zabezpieczeń blokują scalanie, zapobiegając wprowadzaniu podatnego na zagrożenia kodu do głównej gałęzi.
• Wyniki kompilacji są widoczne w żądaniu pull, zapewniając recenzentom kontekst dotyczący bezpieczeństwa.

Sprawdzanie stanu:

• Zewnętrzne narzędzia zabezpieczeń mogą zgłaszać sprawdzanie statusu żądań pobrania.
• Wszystkie wymagane kontrole stanu muszą zostać pomyślnie zakończone przed scaleniem.
• Zespoły ds. zabezpieczeń mogą dodawać nowe wymagane kontrole bez modyfikowania definicji pipeline'u.

Przykładowa konfiguracja polityki gałęzi:

W usługach Azure DevOps lub GitHub zasady gałęzi mogą wymagać:

• Co najmniej 1 zatwierdzenie recenzenta (2 dla gałęzi krytycznych).
• Połączone elementy robocze dotyczące wszystkich zmian.
• Pomyślna weryfikacja kompilacji.
• Wszystkie komentarze rozwiązane przed scaleniem.
• Aktualne gałęzie (muszą zawierać najnowsze zmiany przed scaleniem).
• Wymagane kontrole statusu z narzędzi zabezpieczeń są pozytywne.

Zalety walidacji pull request:

• Testy zabezpieczeń są wykonywane przed wprowadzeniem kodu do udostępnionej bazy kodu.
• Wiele perspektyw przegląda kod pod kątem problemów z zabezpieczeniami.
• Ścieżki audytu dokumentują, kto zatwierdził potencjalnie ryzykowne zmiany.
• Deweloperzy otrzymują opinie dotyczące zabezpieczeń w ramach normalnego przepływu pracy.
• Zespół tworzy kulturę świadomości zabezpieczeń za pomocą przeglądów kodu.

Automatyczne kontrole zabezpieczeń w pull requestach:

Żądania ściągnięcia mogą wyzwalać automatyczną analizę zabezpieczeń:

• Analiza statyczna: Kod jest skanowany pod kątem luk w zabezpieczeniach.
• Testy zależności: Nowe lub zaktualizowane zależności są sprawdzane pod kątem znanych luk w zabezpieczeniach.
• Wykrywanie tajnych danych: System skanowania wykrywa dane poświadczeń zatwierdzonych przez pomyłkę.
• Testy jakości kodu: Analiza identyfikuje problemy z jakością kodu, które mogą prowadzić do problemów z zabezpieczeniami.

Wyniki są wyświetlane bezpośrednio w interfejsie pull request, umożliwiając recenzentom i autorom rozwiązywanie problemów przed scalaniem.