Sprawdzanie i weryfikowanie baz kodu pod kątem zgodności

  • 5 min

Przed wdrożeniem zautomatyzowanych narzędzi do analizy kompozycji oprogramowania organizacje muszą zrozumieć, co należy sprawdzić i zweryfikować w bazach kodu. Nowoczesne aplikacje zawierają setki lub tysiące zależności, co sprawia, że inspekcja ręczna jest niepraktyczna. Systematyczne podejścia do odnajdywania zależności, oceny luk w zabezpieczeniach i walidacji zgodności są niezbędne.

Dlaczego kontrola i walidacja mają znaczenie

Wyzwanie zależności: Aplikacje nie zależą tylko od pakietów, które importujesz bezpośrednio. Każda bezpośrednia zależność zwykle zależy od dodatkowych pakietów (zależności przechodnich), tworząc głębokie drzewa zależności. Typowa aplikacja może bezpośrednio odwoływać się do 20–30 pakietów, ale przechodnio zależy od pakietów 200–500. Odpowiadasz za luki w zabezpieczeniach i obowiązkach licencyjnych we wszystkich zależnościach, a nie tylko bezpośrednich.

Imperatyw zabezpieczeń: Luki w zabezpieczeniach w zależnościach stanowią znaczne ryzyko. Osoby atakujące aktywnie wykorzystują znane luki w zabezpieczeniach w popularnych pakietach, co czyni niezałatane zależności atrakcyjnymi celami. Naruszenia wysokiego profilu często obejmują wykorzystanie znanych luk w zabezpieczeniach w składnikach typu open source, których nie można zaktualizować w organizacjach.

Wymaganie dotyczące zgodności: Naruszenia licencji mogą powodować działania prawne, wymuszone otwieranie kodu własnościowego, ograniczenia dystrybucji i szkody związane z reputacją. Organizacje muszą śledzić zobowiązania licencyjne dla każdej zależności i zapewnić zgodność z postanowieniami licencyjnymi.

Rzeczywistość operacyjna: Zależności stale się zmieniają. Nowe luki w zabezpieczeniach są ujawniane codziennie, pakiety otrzymują aktualizacje, opiekunowie porzucają projekty, a nowe wersje są wydawane. Jednorazowa inspekcja nie jest wystarczająca — wymagana jest ciągła walidacja.

Co należy sprawdzić i zweryfikować

Kompleksowa inspekcja bazy kodu obejmuje wiele wymiarów:

Spis zależności

Tworzenie kompletnego rachunku materiałów:

  • Zależności bezpośrednie: Pakiety jawnie wymienione w plikach manifestu pakietu (package.json, requirements.txt, pom.xml, *.csproj).
  • Zależności przechodnie: Pakiety wymagane przez bezpośrednie zależności, wiele poziomów głębokości.
  • Zależności programistyczne: Pakiety używane podczas programowania i testowania, ale nie są dostarczane z kodem produkcyjnym.
  • Śledzenie wersji: Określone wersje każdego pakietu są obecnie używane.
  • Źródła zależności: Które rejestry pakietów zapewniają zależności (npm, PyPI, NuGet, Maven Central, rejestry prywatne).

Dlaczego pełne zapasy mają znaczenie:

  • Zarządzanie lukami w zabezpieczeniach: Nie można naprawić luk w zabezpieczeniach, o których nie wiesz.
  • Zgodność licencji: Musi śledzić zobowiązania licencyjne dla wszystkich zależności, a nie tylko bezpośrednich.
  • Planowanie aktualizacji: Zrozumienie relacji zależności ułatwia planowanie aktualizacji, które nie będą przerywać zgodności.
  • Widoczność łańcucha dostaw: Dokładnie dowiedz się, jaki kod zewnętrzny jest uwzględniony w aplikacjach.

Wykrywanie luk w zabezpieczeniach

Identyfikowanie znanych luk w zabezpieczeniach:

  • CVE (Typowe luki w zabezpieczeniach i ekspozycje) mapowanie: Dopasuj wersje zależności do baz danych CVE zawierających znane luki w zabezpieczeniach.
  • Ocena ważności: Ocena ważności luk w zabezpieczeniach przy użyciu ocen CVSS (common vulnerability scoring System) od 0 do 10.
  • Analiza możliwości wykorzystania: Ustal, czy luki w zabezpieczeniach są aktywnie wykorzystywane w środowisku naturalnym.
  • Dostępność poprawek: Określenie, które wersje naprawiają luki w zabezpieczeniach i czy są dostępne poprawki.

Omówienie baz danych luk w zabezpieczeniach:

  • Krajowa baza danych luk w zabezpieczeniach (NVD): Repozytorium rządu USA dotyczące danych luk w zabezpieczeniach na podstawie identyfikatorów CVE.
  • Baza danych doradztwa GitHub: Wyselekcjonowane ostrzeżenia zabezpieczeń dla pakietów w wielu ekosystemach.
  • Listy poczty e-mail zabezpieczeń: Powiadomienia dotyczące zabezpieczeń specyficzne dla języka i platformy.
  • Bazy danych dostawców: Komercyjne narzędzia SCA utrzymują zastrzeżone bazy danych luk w zabezpieczeniach z dodatkową analizą.

Kategorie luk w zabezpieczeniach w zależnościach:

  • Wady iniekcji: Wstrzyknięcie kodu SQL, wstrzyknięcie polecenia, luki w zabezpieczeniach skryptów między witrynami w strukturach internetowych.
  • Problemy z uwierzytelnianiem: Słabe implementacje uwierzytelniania, problemy z zarządzaniem sesjami, wady obsługi poświadczeń.
  • Ujawnienie poufnych danych: Niezabezpieczony magazyn danych, nieodpowiednie szyfrowanie, wyciek informacji.
  • Błędna konfiguracja zabezpieczeń: Domyślne konfiguracje ze znanymi słabościami, niepotrzebne funkcje są włączone.
  • Odmowa usługi: Luki w zabezpieczeniach dotyczące wyczerpania zasobów, problemy ze złożonością algorytmiczną.
  • Wady deserializacji: Niebezpieczna deserializacja prowadząca do zdalnego wykonywania kodu.

Walidacja zgodności licencji

Identyfikowanie zobowiązań licencyjnych:

  • Wykrywanie licencji: Określ, które licencje mają zastosowanie do każdej zależności.
  • Klasyfikacja licencji: Kategoryzuj licencje jako liberalne, słabe copyleft, silne copyleft lub własnościowe.
  • Analiza zgodności: Sprawdź, czy licencje różnych zależności są zgodne w połączeniu.
  • Śledzenie obowiązku: Wymagania dotyczące dokumentów, takie jak przypisywanie autorstwa, ujawnianie kodu źródłowego lub licencjonowanie prac pochodnych.

Typowe problemy ze zgodnością:

  • Zanieczyszczenie copyleft: Zależności licencjonowane na podstawie GPL w zastrzeżonym oprogramowaniu mogą wymagać otwarcia kodu źródłowego całej aplikacji.
  • Błędy przypisywania autorstwa: Brak wymaganych powiadomień o prawach autorskich i tekstu licencji w oprogramowaniu rozproszonym.
  • Niezgodne kombinacje: Używanie zależności z licencjami powodującymi konflikt, których nie można połączyć zgodnie z prawem.
  • Zmiany licencji: Projekty czasami zmieniają licencje między wersjami, wymagając ponownej oceny.

Ocena ryzyka licencji:

  • Wysokie ryzyko: Silne licencje copyleft (GPL, AGPL) w własnościowej dystrybucji oprogramowania.
  • Średnie ryzyko: Słabe licencje copyleft (LGPL, MPL) wymagające starannych praktyk integracji.
  • Niskie ryzyko: Licencje permisywne (MIT, Apache 2.0, BSD) z minimalnymi ograniczeniami.
  • Nieznane ryzyko: Licencje niestandardowe, niejasne licencjonowanie lub brakujące informacje o licencji.

Ocena jakości zależności

Ocenianie możliwości utrzymania zależności:

  • Stan konserwacji: Ustal, czy zależności są aktywnie utrzymywane, czy porzucone.
  • Częstotliwość aktualizacji: Oceń, jak często zależności otrzymują aktualizacje i poprawki błędów.
  • Zdrowie społeczności: Oceń aktywność współautora, czasy odpowiedzi na problemy i zaangażowanie społeczności.
  • Jakość dokumentacji: Sprawdź, czy zależności mają odpowiednią dokumentację do odpowiedniego użycia.
  • Rozwiązania w zakresie zabezpieczeń: Sprawdź, czy projekty mają procesy odpowiedzialnego ujawniania informacji i biuletyny zabezpieczeń.

Wskaźniki jakości:

  • Aktywna konserwacja: Regularne zatwierdzenia, najnowsze wersje, responsywni maintainerzy.
  • Duża społeczność: Wielu współautorów, gwiazdek, forków i użytkowników zapewnia trwałość.
  • Jasna komunikacja: Aktywne narzędzie do śledzenia problemów, responsywne dyskusje, jasne notatki o wersji.
  • Świadomość zabezpieczeń: Opublikowane zasady zabezpieczeń, natychmiastowe stosowanie poprawek luk w zabezpieczeniach, biuletyny zabezpieczeń.

Czerwone flagi:

  • Porzucone projekty: Brak aktualizacji przez lata, nieodpowiadające osoby odpowiedzialne, gromadząc nieuporządkowane problemy.
  • Ryzyko związane z pojedynczym konserwatorem: Zależność krytyczna utrzymywana przez jedną osobę, która może stać się niedostępna.
  • Niska jakość: Niewystarczające testowanie, częste błędy, łamliwe zmiany w wersjach drugorzędnych.
  • Brak zabezpieczeń: Brak zasad zabezpieczeń, powolne reagowanie na luki w zabezpieczeniach, nieujawnione problemy z zabezpieczeniami.

Wyzwania ręcznej inspekcji

Dlaczego inspekcja ręczna nie jest efektywna na dużą skalę:

Przytłaczająca głośność

  • Setki zależności: Nawet małe aplikacje przechodnio zależą od setek pakietów.
  • Wiele aplikacji: Organizacje utrzymują dziesiątki lub setki aplikacji, mnożąc liczbę zależności.
  • Stałe zmiany: Nowe wersje wydawane codziennie powodują, że wszystkie ręczne inwentaryzacje stają się natychmiast przestarzałe.
  • Błąd ludzki: Ręczne śledzenie nieuchronnie pomija zależności, zwłaszcza przechodnie.

Informacje rozproszone

  • Wiele źródeł: Informacje o lukach w zabezpieczeniach pochodzą z baz danych CVE, list wysyłkowych zabezpieczeń, biuletynów usługi GitHub, powiadomień dostawców i ujawnienia badacza zabezpieczeń.
  • Badania licencji: Określenie dokładnych licencji wymaga zbadania plików kodu źródłowego, dokumentów readme i plików licencji w każdym pakiecie.
  • Szczegóły specyficzne dla wersji: Luki w zabezpieczeniach i licencje mogą ulec zmianie między wersjami, wymagając badań specyficznych dla wersji.
  • Informacje powodujące konflikt: Różne źródła czasami zapewniają sprzeczne luki w zabezpieczeniach lub informacje o licencji.

Czasochłonna analiza

  • Ocena luk w zabezpieczeniach: Badanie ważności, możliwości wykorzystania i stanu poprawek każdej luki w zabezpieczeniach zajmuje dużo czasu.
  • Analiza licencji: Zrozumienie postanowień licencyjnych, zgodności i zobowiązań wymaga wiedzy prawnej.
  • Planowanie aktualizacji: Określanie bezpiecznych ścieżek aktualizacji z uwzględnieniem zmian powodujących niezgodność oraz konfliktów zależności jest złożone.
  • Ciągłe monitorowanie: Ciągłe monitorowanie nowych luk w zabezpieczeniach i aktualizacji wymaga dedykowanych zasobów.

Wykrywanie opóźnione

  • Opóźnienie odnajdywania: Procesy ręczne wykrywają luki w zabezpieczeniach tygodni lub miesięcy po ujawnieniu.
  • Reaktywna odpowiedź: Organizacje uczą się o lukach w zabezpieczeniach poprzez incydenty bezpieczeństwa, a nie poprzez proaktywne skanowanie.
  • Cykle inspekcji: Okresowe inspekcje pozostawiają aplikacje podatne na zagrożenia między inspekcjami.
  • Poprawki awaryjne: Bez ciągłego monitorowania krytyczne luki w zabezpieczeniach wymagają zakłócającego stosowania poprawek awaryjnych.

Zautomatyzowane rozwiązanie

Narzędzia do analizy kompozycji oprogramowania pozwalają rozwiązać problemy z ręczną inspekcją:

Automatyczne odnajdywanie

  • Analizowanie zależności: Narzędzia SCA automatycznie analizują pliki manifestu pakietu w celu zidentyfikowania zależności.
  • Rozwiązywanie przechodnie: Narzędzia śledzą łańcuchy zależności, aby utworzyć kompletny rachunek materiałów.
  • Analiza plików blokady: Analizowanie plików blokady (package-lock.json, Pipfile.lock), dokładnie pokazujące, które wersje są zainstalowane.
  • Skanowanie binarne: Niektóre narzędzia skanują skompilowane pliki binarne i kontenery w celu odnajdywania osadzonych zależności.

Ciągłe monitorowanie

  • Alerty dotyczące luk w zabezpieczeniach w czasie rzeczywistym: Otrzymuj natychmiastowe powiadomienia, gdy nowe luki w zabezpieczeniach wpływają na twoje zależności.
  • Aktualizacje automatyczne: Narzędzia, takie jak GitHub Dependabot, automatycznie tworzą żądania ściągnięcia, gdy są dostępne aktualizacje zabezpieczeń.
  • Widoczność pulpitu nawigacyjnego: Scentralizowane pulpity nawigacyjne pokazują stan luk w zabezpieczeniach we wszystkich aplikacjach.
  • Zaplanowane skanowanie: Regularne automatyczne skanowania zapewniają, że dane zależności pozostają aktualne.

Kompleksowe bazy danych

  • Zagregowane dane luk w zabezpieczeniach: Narzędzia SCA agregują informacje z NVD, GitHub Advisory Database, list mailingowych dotyczących bezpieczeństwa i baz danych dostawców.
  • Bazy danych licencji: Zachowaj kompleksowe informacje licencyjne, w tym pełne teksty licencji i podsumowania zobowiązań.
  • Kontrola i weryfikacja: Dostawcy weryfikują i opracowują dane dotyczące luk w zabezpieczeniach, aby zmniejszyć liczbę fałszywych alarmów.
  • Analiza własnościowa: Narzędzia komercyjne zapewniają dodatkowe badania i analizy poza publicznymi bazami danych.

Analiza inteligentna

  • Ocena stopnia ważności: Automatycznie obliczaj oceny CVSS i ustalaj priorytety wrażliwości według ryzyka.
  • Analiza dostępności: Ustal, czy ścieżki kodu podatnego na zagrożenia są rzeczywiście używane w aplikacji.
  • Wskazówki dotyczące korygowania: Podaj konkretne zalecenia dotyczące wersji, które naprawiają luki w zabezpieczeniach przy zachowaniu zgodności.
  • Wymuszanie przestrzegania zasad: Automatyczne zatrzymanie kompilacji lub blokada wdrożeń po wykryciu naruszeń zasad.

Ustanawianie punktów odniesienia walidacji

Przed zaimplementowaniem zautomatyzowanego skanowania ustanów kryteria weryfikacji:

Zasady zabezpieczeń

  • Tolerancja luk w zabezpieczeniach: Określ, które ważności luk w zabezpieczeniach są akceptowalne (np. brak krytycznych lub wysokich, ograniczona średnia).
  • Przedziały czasowe poprawek: Ustal, jak szybko należy naprawić różne luki w zabezpieczeniach o różnej poważności.
  • Procesy wyjątków: Tworzenie procedur akceptowania zagrożeń, gdy natychmiastowe stosowanie poprawek nie jest możliwe.
  • Wymagania dotyczące raportowania: Określ, kto potrzebuje powiadomień o lukach w zabezpieczeniach i jak szybko.

Zasady zgodności

  • Zatwierdzone licencje: Wyświetlanie listy licencji, które są zawsze akceptowalne (np. MIT, Apache 2.0).
  • Licencje z ograniczeniami: Zidentyfikuj licencje wymagające specjalnego zatwierdzenia (np. LGPL) lub zakazu (np. GPL dla oprogramowania własnościowego).
  • Wymagania dotyczące autorstwa: Zdefiniuj sposób określania autorstwa w oprogramowaniu rozproszonym.
  • Dzienniki inspekcji: Określ wymagania dotyczące dokumentacji dotyczące dowodów zgodności.

Standardy jakości

  • Wymagania dotyczące konserwacji: Zdefiniuj minimalne oczekiwania dotyczące konserwacji (np. aktualizacje w ciągu ostatniego roku).
  • Rozmiar społeczności: Ustanów progi akceptowalnych metryk kondycji społeczności.
  • Standardy dokumentacji: Określ minimalne wymagania dotyczące dokumentacji dla zależności.
  • Rozwiązania w zakresie zabezpieczeń: Wymagaj od zależności opublikowania zasad zabezpieczeń i dynamicznej obsługi luk w zabezpieczeniach.

Zrozumienie, co należy sprawdzić i zweryfikować, stanowi podstawę do implementowania zautomatyzowanych narzędzi do analizy kompozycji oprogramowania. W następnej jednostce przedstawiono podstawy analizy składników oprogramowania (SCA) i sposób, w jaki zautomatyzowane narzędzia rozwiązują wyzwania związane z ręcznym zarządzaniem zależnościami.