Badanie ciągłej walidacji bezpieczeństwa

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.