DevSecOps dla programów obronnych: bezpieczeństwo w każdym sprincie

DevSecOps — integracja praktyk bezpieczeństwa na każdym etapie cyklu tworzenia oprogramowania — jest odpowiedzią programów obronnych na uznanie, że tradycyjne podejścia do bezpieczeństwa z testowaniem na końcu nie nadążają za współczesnymi tempami dostarczania oprogramowania. Gdy testowanie bezpieczeństwa następuje dopiero przed wydaniem, naprawianie podatności jest kosztowne i opóźnia dostawę; gdy jest wbudowane w pipeline CI/CD, podatności są wykrywane blisko miejsca ich wprowadzenia, gdy kontekst jest świeży, a naprawa jest stosunkowo tania.

Programy obronne mają dodatkowe wymagania w porównaniu do komercyjnego DevSecOps: zgodność ze STIG (Security Technical Implementation Guides), ścieżki audytu dla organów akredytacyjnych, zarządzanie tajemnicami dla systemów klasyfikowanych oraz rygorystyczne wymagania dotyczące integralności łańcucha dostaw dla artefaktów kodu wdrażanych w systemach krytycznych. Wymagania te zmieniają konfigurację i priorytety pipeline DevSecOps, ale nie zmieniają podstawowej architektury.

Statyczna analiza kodu: Semgrep i narzędzia SAST

SAST (Static Application Security Testing) analizuje kod źródłowy lub kod bajtowy bez jego uruchamiania, wykrywając potencjalne podatności poprzez analizę przepływu danych, konfiguracji i wzorców. Semgrep jest de facto standardem dla lekkiego SAST w pipeline DevSecOps: obsługuje ponad 30 języków programowania, uruchamia się w ciągu sekund na typowych bazach kodu i może być dostosowany do konkretnych wzorców bezpieczeństwa istotnych dla programów obronnych.

Semgrep umożliwia definiowanie reguł za pomocą prostej składni YAML, pozwalając zespołom bezpieczeństwa skodyfikować wzorce bezpieczeństwa specyficzne dla domeny. Dla programów obronnych obejmuje to reguły specyficzne dla domeny: weryfikację szyfrowania danych klasyfikowanych, wykrywanie niebezpiecznych połączeń sieciowych w kontekście systemów klasyfikowanych oraz wykrywanie wzorców dostępu do danych naruszających obowiązkowe reguły kontroli dostępu (MAC). W kontekście MON (Ministerstwo Obrony Narodowej), SAST staje się wymogiem akredytacyjnym, a nie opcjonalnym ulepszeniem.

Testowanie dynamiczne: OWASP ZAP i DAST w pipeline

DAST (Dynamic Application Security Testing) testuje uruchomione aplikacje, wysyłając złośliwe dane wejściowe i obserwując zachowanie, wykrywając podatności wynikające z interakcji między komponentami, a nie z izolowanego kodu źródłowego. OWASP ZAP (Zed Attack Proxy) jest standardowym narzędziem DAST open-source do integracji z pipeline CI/CD. ZAP w trybie daemon udostępnia REST API, który umożliwia pipeline uruchamianie automatycznych skanowań, pobieranie raportów i wychodzenie z niezerowym kodem dla wyników przekraczających progi.

Dla aplikacji obronnych skanowania DAST muszą obejmować wektory ataków specyficzne dla obrony: podatności uwierzytelniania w systemach z obowiązkową kontrolą dostępu, SQL injection w bazach danych z danymi operacyjnymi, podatności zarządzania sesjami w systemach z wieloma poziomami klasyfikacji.

Analiza komponentów: SCA i wykrywanie podatności

SCA (Software Composition Analysis) identyfikuje znane podatności w zależnościach zewnętrznych — bibliotekach open source i komponentach komercyjnych zawartych w bazie kodu. Grype i Trivy są standardowymi narzędziami SCA w pipeline DevSecOps: skanują pakiety zależności (Maven, npm, pip, moduły Go) i obrazy kontenerów pod kątem baz danych podatności (NVD, GitHub Advisory Database, dystrybucyjne bazy porad).

Dla programów obronnych SCA jest szczególnie ważne z dwóch powodów: komponenty zewnętrzne są najczęstszym źródłem podatności w dojrzałych bazach kodu, a wymagania łańcucha dostaw programów obronnych (EO 14028, wymagania SBOM) wymagają pełnej inwentaryzacji i dokumentacji komponentów zewnętrznych.

Wykrywanie tajemnic: Gitleaks i ochrona pre-commit

Tajemnice — klucze API, hasła, certyfikaty, tokeny — które dostają się do repozytoriów kodu źródłowego są jednym z najczęstszych i najbardziej impaktowych naruszeń bezpieczeństwa. Po tym jak tajemnica trafi do repozytorium git, pozostaje tam w historii git nawet po "usunięciu" — może zostać znaleziona przez każdego z dostępem do repozytorium.

Gitleaks i detect-secrets są standardowymi narzędziami skanowania tajemnic w pipeline DevSecOps: analizują repozytoria git (w tym historię git) pod kątem wzorców pasujących do znanych formatów tajemnic. Hooki pre-commit uruchamiające Gitleaks zapewniają pierwszą barierę ochronną, zapobiegając commitom zawierającym wykryte tajemnice. Sprawdzenia CI/CD zapewniają drugą barierę, skanując push do scentralizowanego repozytorium.

Bezpieczeństwo kontenerów: podpisywanie obrazów i rejestr

Obrazy kontenerów wdrażane w systemach obronnych muszą mieć zweryfikowaną integralność. Cosign (z projektu Sigstore) zapewnia podpisywanie i weryfikację obrazów kontenerów: pipeline budowy podpisuje obraz kluczem kryptograficznym po pomyślnym przejściu wszystkich kontroli bezpieczeństwa; webhook przyjęcia Kubernetes weryfikuje podpis przed zezwoleniem na wdrożenie obrazu.

Harbor jest standardowym rejestrem kontenerów dla bezpiecznych i wdrożonych w środowiskach izolowanych programów obronnych: zapewnia kontrolę dostępu, dzienniki audytu, wbudowane skanowanie podatności (przez Trivy) i obsługę podpisywania treści. Dla programów obronnych wdrażanych w środowiskach izolowanych, Harbor jest oficjalnym rejestrem dla wszystkich dozwolonych obrazów.

Zgodność ze STIG: automatyzacja weryfikacji

STIG (Security Technical Implementation Guides) opublikowane przez DISA definiują szczegółowe techniczne wymagania dotyczące konfiguracji bezpieczeństwa dla systemów Ministerstwa Obrony. OpenSCAP zapewnia zautomatyzowaną weryfikację zgodności ze STIG: porównuje konfigurację systemów ze specyfikacjami STIG (w formacie XCCDF/OVAL) i generuje raporty zgodności identyfikujące wyniki Kategorii I (krytyczne), II (średnie) i III (niskie).

Dla pipeline CI/CD weryfikacje zgodności STIG mogą być zautomatyzowane jako część budowy obrazu kontenera: po zbudowaniu obrazu bazowego, ale przed wypchnięciem do rejestru, OpenSCAP uruchamia odpowiedni profil STIG na obrazie. Wyniki Kategorii I powodują niepowodzenie budowy; wyniki Kategorii II i III mogą generować ostrzeżenia lub wymagać udokumentowanych odstępstw z uzasadnieniem.