Badanie ciągłej walidacji bezpieczeństwa

  • 8 min

Nowoczesne deweloperzy rutynowo używają składników dostępnych w publicznych źródłach pakietów, takich jak npm, NuGet, PyPI, Maven Central i RubyGems. Ta praktyka stała się standardem w całej branży oprogramowania, ponieważ organizacje stosują składniki oprogramowania open source (OSS) w celu szybszego dostarczania i lepszej wydajności.

Podwójnie krawędziowy miecz składników innych firm

Zalety składników innych firm:

  • Szybsze programowanie: Deweloperzy nie muszą tworzyć typowych funkcji od podstaw.
  • Sprawdzone rozwiązania: Popularne pakiety zostały przetestowane przez tysiące użytkowników.
  • Pomoc techniczna społeczności: Aktywne społeczności zapewniają dokumentację, aktualizacje i pomoc.
  • Oszczędności: Bezpłatne składniki systemu operacyjnego znacznie obniżają koszty programowania.
  • Przyspieszanie innowacji: Zespoły mogą skupić się na unikatowej logice biznesowej, a nie na ponownym wynalezieniu standardowych funkcji.

Rosnące zagrożenia związane z bezpieczeństwem i zgodnością: Jednak w miarę wzrostu zależności od komponentów oprogramowania open source innych firm, rosną również ryzyka:

Luki w zabezpieczeniach:

  • Pakiety innych firm mogą zawierać znane luki w zabezpieczeniach, które mogą wykorzystać osoby atakujące.
  • Luki w zabezpieczeniach są stale wykrywane w istniejących pakietach.
  • Przejściowe zależności (czyli zależności twoich zależności) mogą wprowadzać luki w zabezpieczeniach, o których możesz nie wiedzieć.
  • Ataki łańcucha dostaw są przeznaczone dla popularnych pakietów w celu naruszenia zabezpieczeń wielu aplikacji podrzędnych.

Problemy ze zgodnością licencji:

  • Ukryte wymagania licencyjne mogą tworzyć zobowiązania prawne.
  • Niektóre licencje systemu operacyjnego wymagają użycia własnego kodu typu open source, jeśli używasz ich składników.
  • Naruszenia licencji mogą prowadzić do pozwów, kar finansowych i wymuszonych wydań kodu.
  • Różne licencje mogą być ze sobą niezgodne, tworząc konflikty zgodności.

Krytyczne znaczenie dla działania firmy: W przypadku firmy te problemy mają kluczowe znaczenie. Problemy związane ze zgodnością, zobowiązaniami i danymi osobowymi klientów mogą powodować poważne problemy związane z prywatnością i bezpieczeństwem:

  • Odpowiedzialność prawna: Naruszenia licencji narażają organizacje na działania prawne.
  • Naruszenia zabezpieczeń danych: Wrażliwe składniki mogą prowadzić do naruszeń danych wpływających na dane osobowe klientów.
  • Zgodność: Naruszenia przepisów, takich jak RODO, KPCHA lub HIPAA, mogą spowodować znaczne grzywny.
  • Uszkodzenie reputacji: Zdarzenia zabezpieczeń i naruszenia licencji powodują uszkodzenie zaufania klientów i reputacji marki.
  • Umowy klienta: Klienci biznesowi często wymagają gwarancji w zakresie zabezpieczeń i zgodności, które mogą być pogwałcone przez podatne na zagrożenia komponenty.

Wartość wczesnego wykrywania

Ostrzeżenie zaawansowane: Identyfikowanie problemów z zabezpieczeniami i zgodnością na wczesnym etapie cyklu wydania zapewnia zaawansowane ostrzeżenie i wystarczająco dużo czasu, aby rozwiązać problemy przed dotarciem do środowiska produkcyjnego.

Koszt korygowania: Koszt rozwiązywania problemów jest znacznie niższy, im wcześniej w projekcie zostaną wykryte.

  • Podczas opracowywania: Zmiana zależności kosztuje godziny czasu dewelopera.
  • Podczas testowania: Rozwiązywanie problemów wymaga ponownego testowania całej aplikacji.
  • W środowisku produkcyjnym: Korygowanie wymaga stosowania poprawek awaryjnych, reagowania na zdarzenia zabezpieczeń, powiadomień klientów i potencjalnych raportów regulacyjnych.

Wpływ gospodarczy: Badania pokazują, że problemy z zabezpieczeniami znalezione w produkcji kosztują 10-100 razy więcej do naprawy niż te wykryte podczas opracowywania.

Ciągła weryfikacja zabezpieczeń integracji

Po scaleniu kodu z gałęzią główną kompleksowa weryfikacja zabezpieczeń powinna zostać wykonana w ramach procesu kompilacji ciągłej integracji.

Kompilacja ciągłej integracji a kompilacja PR-CI

Ciągła integracja żądania ściągnięcia (PR-CI): Uruchamia się podczas walidacji żądania ściągnięcia przed scaleniem kodu. Zapewnia szybką informację zwrotną, aby zapobiec wprowadzeniu podatnego na zagrożenia kodu do bazy kodu.

Pełna budowa CI: Uruchamia się po scaleniu kodu z gałęzią główną. Obejmuje bardziej kompleksowe kontrole i przygotowuje artefakty do wdrożenia.

Typowe różnice: Podstawową różnicą między kompilacjami PR-CI a pełnymi kompilacjami CI jest to, że PR-CI nie potrzebuje tworzenia pakietów ani artefaktów etapowych, które generują pełne kompilacje CI. Dzięki temu PR-CI pozostaje szybkie, jednocześnie zachowując weryfikację zabezpieczeń.

Oba powinny obejmować kontrole zabezpieczeń: Oba typy kompilacji powinny uruchamiać podstawowe weryfikacje zabezpieczeń, ale pełne kompilacje ciągłej integracji mogą obejmować dodatkowe testy czasochłonne.

Statyczna analiza kodu w budowach ciągłej integracji

Cel: Kompilacje ciągłej integracji powinny uruchamiać statyczne testy analizy kodu, aby upewnić się, że kod jest zgodny ze wszystkimi regułami zapewniającymi utrzymanie i bezpieczeństwo.

Typowe narzędzia do analizy statycznej:

SonarQube:

  • Kompleksowa platforma jakości kodu i zabezpieczeń.
  • Wykrywa usterki, problematyczne fragmenty kodu i luki w zabezpieczeniach.
  • Śledzi metryki jakości kodu w czasie.
  • Integruje bramy jakości, które powodują niepowodzenie budowy, gdy progi jakości nie są spełnione.
  • Obsługuje wiele języków programowania.

Analizatory zabezpieczeń programu Visual Studio Code i Roslyn:

  • Wbudowana analiza aplikacji .NET.
  • Analizatory zabezpieczeń Roslyn wykrywają luki w zabezpieczeniach w kodzie języka C#.
  • Uruchamia się podczas kompilacji, przesyłając natychmiastową opinię.
  • Brak dodatkowej infrastruktury wymaganej dla projektów .NET.

Checkmarx:

  • Narzędzie do testowania zabezpieczeń aplikacji statycznych (SAST).
  • Głęboka analiza zabezpieczeń kodu źródłowego.
  • Identyfikuje luki w zabezpieczeniach, takie jak wstrzyknięcie kodu SQL, XSS i problemy z uwierzytelnianiem.
  • Zawiera szczegółowe wskazówki dotyczące korygowania.
  • Obsługuje wiele języków programowania i struktur.

BinSkim:

  • Binarne narzędzie do analizy statycznej firmy Microsoft.
  • Zapewnia wyniki zabezpieczeń i poprawności dla przenośnych plików wykonywalnych systemu Windows (plików PE).
  • Analizuje skompilowane pliki binarne, a nie kod źródłowy.
  • Identyfikuje problemy z zabezpieczeniami w ustawieniach kompilacji i strukturze binarnej.
  • Przydatne do analizowania składników skompilowanych przez inne firmy.

Dodatkowe narzędzia:

  • Program ESLint z wtyczkami zabezpieczeń: Analiza zabezpieczeń języka JavaScript/TypeScript.
  • Bandit: Analiza zabezpieczeń języka Python.
  • Brakeman: Ruby on Rails skaner bezpieczeństwa.
  • gosec: Narzędzie do sprawdzania bezpieczeństwa w Go.

Integracja z Azure Pipelines: Wiele narzędzi zabezpieczeń bezproblemowo integruje się z Azure Pipelines i innymi platformami CI/CD. Witryna Visual Studio Marketplace udostępnia rozszerzenia dla różnych narzędzi zabezpieczeń, dzięki czemu integracja jest prosta:

  • Narzędzia są wyświetlane jako zadania potoku, które można dodać do definicji potoku.
  • Wyniki są wyświetlane w dziennikach potoku i mogą zakończyć się niepowodzeniem kompilacji po wykryciu problemów.
  • Wyniki zabezpieczeń integrują się ze śledzeniem elementów roboczych usługi Azure DevOps.

Skanowanie luk w zabezpieczeniach pakietów innych firm

Krytyczne, ale często pomijane: Poza weryfikacją jakości kodu, dwie inne krytyczne weryfikacje są często ignorowane lub wykonywane nieodpowiednio:

  1. Skanowanie pakietów innych firm pod kątem znanych luk w zabezpieczeniach.
  2. Weryfikowanie zgodności licencji systemu operacyjnego.

Wspólna odpowiedź organizacyjna: Na pytanie o luki w zabezpieczeniach i licencjach pakietów innych firm wiele organizacji reaguje z obawą lub niepewnością. Nie mają przejrzystych procesów zarządzania tymi zagrożeniami.

Problemy z procesem ręcznym: Organizacje próbujące zarządzać lukami w zabezpieczeniach pakietów innych firm lub licencjami systemu operacyjnego często wyjaśniają, że ich proces jest żmudny i ręczny:

  • Deweloperzy ręcznie wyszukują bazy danych luk w zabezpieczeniach.
  • Zespoły ds. zabezpieczeń utrzymują arkusze kalkulacyjne zatwierdzonych pakietów.
  • Przeglądy licencji wymagają zaangażowania zespołu prawnego dla każdego pakietu.
  • Aktualizacje są śledzone ręcznie, co prowadzi do nieaktualnych informacji o zależnościach.
  • Proces trwa kilka tygodni, znacznie spowalniając rozwój.

Zautomatyzowane rozwiązania: Nowoczesne narzędzia do analizy kompozycji oprogramowania (SCA) automatyzują ten proces identyfikacji, dzięki czemu niemal natychmiast:

Mend (dawniej WhiteSource):

  • Automatycznie wykrywa wszystkie składniki systemu operacyjnego w aplikacjach.
  • Identyfikuje znane luki w zabezpieczeniach w zależnościach.
  • Sprawdza zgodność licencji z zasadami organizacyjnymi.
  • Dostarcza wskazówki dotyczące naprawy, w tym dostępne poprawione wersje.
  • Stale monitoruje nowe luki w zabezpieczeniach w używanych pakietach.

GitHub Dependabot:

  • Automatycznie skanuje zależności pod kątem znanych luk w zabezpieczeniach.
  • Tworzy prośby o połączenie w celu zaktualizowania wrażliwych zależności.
  • Obsługuje wiele ekosystemów pakietów (npm, Maven, itp.).
  • Bezpłatne dla publicznych i prywatnych repozytoriów GitHub.

Snyk:

  • Narzędzie bezpieczeństwa, które jako pierwsze wspiera deweloperów w znajdowaniu i naprawianiu luk w zabezpieczeniach.
  • Skanuje zależności, obrazy kontenerów i infrastrukturę jako kod.
  • Zapewnia zalecenia dotyczące naprawy i zautomatyzowane pull requesty.
  • Integruje się ze środowiskami IDE, kontrolą wersji i potokami ciągłej integracji/ciągłego wdrażania.

Źródła nadrzędne usługi Azure Artifacts:

  • Można skonfigurować do skanowania pakietów ze źródeł nadrzędnych.
  • Blokuje pakiety ze znanymi lukami w zabezpieczeniach.
  • Zapewnia wgląd we wszystkie pakiety używane w całej organizacji.

Korzyści z analizy kompozycji oprogramowania

Kompleksowa widoczność: Narzędzia SCA zapewniają pełny wgląd w łańcuch dostaw oprogramowania:

  • Utwórz spis wszystkich zależności bezpośrednich i przechodnich.
  • Śledź wersje i stan aktualizacji.
  • Zidentyfikuj składniki, które nie są już obsługiwane.
  • Mapuj zależności na określone aplikacje i zespoły.

Priorytetyzacja ryzyka: Nie wszystkie luki w zabezpieczeniach są równie krytyczne. Narzędzia SCA ułatwiają określanie priorytetów:

  • Oceny ważności (klasyfikacje CVSS) wskazujące ważność luki w zabezpieczeniach.
  • Oceny możliwości wykorzystania pokazujące, czy istnieją ataki.
  • Analiza dostępności określająca, czy kod podatny na zagrożenia jest rzeczywiście używany w aplikacji.
  • Kontekst biznesowy dotyczący tego, które aplikacje są najbardziej krytyczne.

Ciągłe monitorowanie: Luki w zabezpieczeniach są stale wykrywane. Narzędzia SCA zapewniają ciągłe monitorowanie:

  • Alerty po wykryciu nowych luk w zabezpieczeniach w używanych pakietach.
  • Regularne raporty dotyczące trendów stanu zabezpieczeń.
  • Integracja z systemami śledzenia problemów w celu zarządzania pracą korygowania.

Dokumentacja dotycząca zgodności: Narzędzia SCA generują raporty zgodności:

  • Zobowiązania licencyjne dla wszystkich używanych składników.
  • Wymagania dotyczące autorstwa, które muszą zostać spełnione.
  • Dowody na to, że przeprowadzono przeglądy zabezpieczeń.
  • Dzienniki inspekcji dotyczące zgodności z przepisami.

Integracja w potoku

Ciągła walidacja zabezpieczeń integruje się z łańcuchem CI/CD w formie zadań automatycznych.

  1. Scalanie kodu: Pull request jest zatwierdzony i kod jest scalany z gałęzią główną.
  2. Wyzwalacze kompilacji ciągłej integracji: Scalanie automatycznie wyzwala pełną kompilację ciągłej integracji.
  3. Przebiegi analizy statycznej: Narzędzia SAST analizują kod źródłowy pod kątem luk w zabezpieczeniach.
  4. Skanowanie zależności: Narzędzia SCA skanują wszystkie zależności pod kątem luk w zabezpieczeniach i problemów z licencjami.
  5. Bramy jakości: Kompilacja kończy się niepowodzeniem, jeśli problemy z zabezpieczeniami przekraczają dopuszczalne progi.
  6. Dostępne wyniki: Wyniki zabezpieczeń są dostępne dla deweloperów i zespołów ds. zabezpieczeń.
  7. Tworzenie artefaktu: Jeśli testy zabezpieczeń przejdą, artefakty kompilacji są tworzone do wdrożenia.

W kolejnych modułach omówimy integrację kilku przydatnych i często używanych narzędzi zabezpieczeń i zgodności do określonej konfiguracji potoku.