Potok CI/CD dla oprogramowania obronnego: automatyczne testowanie i wdrażanie systemów klasy wojskowej

Komercyjny zespół programistyczny może wdrożyć nową funkcję na produkcję w ciągu kilku minut: żądanie scalenia przechodzi automatyczne testy, recenzent zatwierdza, potok CI buduje i wdraża. Dla zespołów tworzących oprogramowanie obronne ta sama ścieżka dostarczania musi przejść przez fundamentalnie odmienną przestrzeń ograniczeń: przepisy eksportowe ITAR ograniczające dostęp do artefaktów kompilacji, wymagania zgodności STIG definiujące konfigurację każdej warstwy stosu, mandaty SBOM wymagające czytelnego maszynowo rejestru każdej zależności oraz środowiska wdrożeniowe, które mogą nie mieć połączenia z internetem w ogóle. W rezultacie wiele programów obronnych albo całkowicie rezygnuje z CI/CD na rzecz ręcznych, wielobramkowych procesów wydania — albo wdraża komercyjne narzędzia CI/CD bez odpowiedniego okablowania zgodności i tworzy ryzyko podczas audytu.

Żaden z tych wyników nie jest konieczny. Potok CI/CD dla oprogramowania obronnego spełniający wymagania ITAR, produkujący artefakty zgodne z STIG, generujący podpisane SBOM i wdrażający w środowiskach izolowanych jest osiągalny przy użyciu dostępnych narzędzi open source i jasnego wzorca architektonicznego. Ten artykuł opisuje ten wzorzec, obejmując wybory infrastruktury potoku, etapy automatycznego testowania, generowanie SBOM, hartowanie kontenerów, wdrożenie w środowiskach izolowanych, procedury cofania oraz wymagania dotyczące ścieżki audytu.

Ograniczenia oprogramowania obronnego: ITAR, STIG i obsługa klasyfikacji w CI

Międzynarodowe przepisy o ruchu broni (ITAR) kontrolują eksport artykułów i usług obronnych, w tym danych technicznych związanych z systemami obronnymi. W kontekście CI/CD kod źródłowy, artefakty kompilacji i wyniki testów mogą podlegać kontroli eksportowej, a dostęp musi być ograniczony do osób z USA. Wykonawcy kompilacji przetwarzający kod kontrolowany przez ITAR muszą działać w systemach, gdzie dostęp jest egzekwowany na poziomie infrastruktury — samodzielnie zarządzane wykonawcy na sprzęcie lokalnym lub wykonawcy w enklawie FedRAMP High lub DoD IL4/IL5 z udokumentowanymi kontrolami dostępu.

Plan kontroli technologii programu (TCP) musi obejmować infrastrukturę CI/CD w swoim zakresie. Obsługa klasyfikacji dodaje kolejne ograniczenie: sam potok CI/CD działa na najwyższym poziomie klasyfikacji dowolnego produkowanego artefaktu.

Architektura potoku: GitLab on-premises kontra SaaS, uwagi dotyczące środowisk izolowanych

GitLab z własnym zarządzaniem jest dominującym wyborem platformy CI/CD dla wrażliwych programów obronnych. Działa całkowicie w kontrolowanej przez ciebie infrastrukturze, obsługuje w pełni offline instalację, integruje się z Active Directory i LDAP do kontroli dostępu i ma dużą bazę instalacji w programach DoD. Rejestr artefaktów musi również działać w kontrolowanej przez ciebie infrastrukturze — Harbor dla kontenerów, Artifactory lub Nexus dla zależności ekosystemu językowego. W przypadku wdrożeń izolowanych proces odświeżania lustrzanego przenosi zewnętrzną zawartość przez izolację według udokumentowanego harmonogramu.

Etapy automatycznego testowania: od jednostkowych do skanowania zgodności STIG

Potok CI/CD dla obrony wymaga: testów jednostkowych i integracyjnych przy każdym zatwierdzeniu; SAST (Semgrep lub SonarQube) przy każdym żądaniu scalenia; DAST (OWASP ZAP) wobec wdrożonej instancji testowej; analizy składu oprogramowania (Grype lub Trivy) wobec wewnętrznego lustrzanego repozytorium podatności; skanowania zgodności STIG (InSpec z profilami DISA lub OpenSCAP); wykrywania sekretów; oraz zgodności licencyjnej. Każdy etap zatrzymuje potok przy naruszeniach zasad bez możliwości ręcznego pominięcia.

Generowanie SBOM: CycloneDX/SPDX, Grype/Trivy, zgodność licencyjna

Sekcja 1655 NDAA (FY2023) zobowiązała DoD do opracowania wytycznych wymagających SBOM od dostawców oprogramowania. SBOM są generowane w czasie kompilacji przy użyciu Syft lub cdxgen w formacie CycloneDX lub SPDX, podpisywane wraz z artefaktem kompilacji przy użyciu Cosign i przechowywane w rejestrze artefaktów jako artefakty pierwszej klasy. Grype lub Trivy porównują komponenty SBOM z bazami CVE i produkują adnotacje VEX. Zgodność licencyjna jest egzekwowana jako równoległa bramka.

Hartowanie kontenerów: bazy distroless, wykonanie bez root, seccomp, podpisywanie obrazów

Obrazy kontenerów dla obciążeń obronnych używają baz distroless lub DISA STIG-hardened, działają jako użytkownicy nie-root, używają systemów plików root tylko do odczytu, stosują profile seccomp RuntimeDefault lub niestandardowe i są podpisywane przy użyciu Cosign lub Notary v2. Kontrolery dopuszczenia (OPA/Gatekeeper lub Kyverno) egzekwują te wymagania podczas planowania podów we wszystkich klastrach.

Wdrożenie w środowiskach niejawnych: transfer przez nośniki wymienne, weryfikacja hasza, podpisywanie manifestu

Potok produkuje podpisany pakiet wdrożeniowy zawierający: podpisane pliki binarne lub obrazy kontenerów, SBOM, wyniki skanowania podatności, atestację pochodzenia SLSA, manifest wdrożenia i plik hasza SHA-256. Transfer przez izolację odbywa się za pośrednictwem akredytowanego rozwiązania między domenami lub udokumentowanych procedur z nośnikami wymiennymi. Po stronie niejawnej skrypt instalacyjny weryfikuje hasz i podpis przed przystąpieniem do działania.

Procedury cofania: blue-green dla usług, migawki SQLite dla systemów wbudowanych

Usługi sieciowe używają wdrożeń blue-green — cofanie to przełączenie ruchu, nie ponowne wdrożenie. Systemy wbudowane i aplikacje korzystające z SQLite używają wersjonowanych migawek przed uaktualnieniem. Potok CI testuje ścieżkę migawki/przywracania w testach integracyjnych. Wszystkie zdarzenia cofania są rejestrowane w niezmiennej ścieżce audytu.

Wymagania dotyczące ścieżki audytu: niezmienne dzienniki, zatwierdzenia zmian, śledzenie wymagań

Dzienniki potoku są przechowywane w jednokrotnym zapisie SIEM lub zasobnik obiektu z blokowaniem obiektów. Każde wdrożenie odwołuje się do zatwierdzonego biletu zmiany. Śledzenie łączy elementy pracy deweloperskiej z elementami wymagań, a wyniki testów są dołączane do elementów pracy. Potok dołącza podsumowania wyników testów i hasza artefaktów do odpowiedniego zgłoszenia po zakończeniu wdrożenia.