SBOM dla zamówień obronnych: przejrzystość łańcucha dostaw oprogramowania

Zestawienie składników oprogramowania (SBOM) — formalny dokument inwentaryzacyjny wymieniający każdy komponent, bibliotekę i zależność w produkcie programowym — szybko przekształcił się z technicznej praktyki DevOps w wymóg regulacyjny dla zamówień obronnych. Rozporządzenie wykonawcze USA 14028 "Poprawa cyberbezpieczeństwa narodu" (2021) wymaga od dostawców oprogramowania sprzedających agencjom federalnym dostarczania SBOM. Akt o Odporności Cybernetycznej UE (CRA), który wszedł w życie w 2024 roku, wprowadza obowiązkowe wymagania bezpieczeństwa i SBOM dla produktów z elementami cyfrowymi sprzedawanych na rynku UE.

Dla wykonawców obronnych oba wymogi regulacyjne zbiegają się: programy obronne są systemami krytycznymi podlegającymi najsurowszym reżimom zgodności, a SBOM staje się standardowym artefaktem kontraktowym obok dokumentacji bezpieczeństwa systemu i raportów z testów. W Polsce MON (Ministerstwo Obrony Narodowej) coraz częściej włącza wymagania dotyczące bezpieczeństwa łańcucha dostaw oprogramowania do umów na systemy informatyczne.

Formaty SBOM: SPDX i CycloneDX

SPDX (Software Package Data Exchange) jest standardem ISO (ISO/IEC 5962:2021) dla SBOM, opracowanym przez społeczność Linux Foundation. SPDX definiuje schemat opisywania pakietów oprogramowania, ich zależności i informacji licencyjnych. Dokumenty SPDX mogą być wyrażone w kilku formatach: tag-value (format tekstowy czytelny dla człowieka), JSON, RDF i YAML.

CycloneDX jest standardem OWASP dla specyfikacji BOM (Bill of Materials), opracowanym z bezpośrednim naciskiem na zastosowania bezpieczeństwa. CycloneDX obsługuje nie tylko SBOM, ale także HBOM (sprzęt), MBOM (uczenie maszynowe) i CBOM (kryptografia) — co czyni go szczególnie istotnym dla systemów obronnych, gdzie przejrzystość sprzętu i kryptografii jest ważna. CycloneDX zawiera rozszerzenie VEX (Vulnerability Exploitability eXchange), które umożliwia dostawcom komunikowanie, czy konkretne znane podatności są rzeczywiście możliwe do wykorzystania w ich produkcie.

Generowanie SBOM: Syft i cdxgen

Syft od Anchore jest wiodącym narzędziem open-source do generowania SBOM. Obsługuje szeroki zakres ekosystemów pakietów (Alpine, DEB, RPM, Maven, npm, PyPI, moduły Go, NuGet i inne) i może analizować katalogi systemu plików, obrazy kontenerów i artefakty OCI. Syft generuje SBOM w formatach SPDX i CycloneDX, zapewniając elastyczność w spełnianiu różnych wymagań audytorów i klientów.

Dla pipeline CI/CD Syft może być zintegrowany jako krok po budowie: po pomyślnym zbudowaniu obrazu kontenera Syft generuje SBOM dla tego obrazu, który jest następnie podpisywany (za pomocą Cosign) i publikowany wraz z obrazem w rejestrze kontenerów. Powiązany SBOM nadaje każdemu obrazowi w rejestrze czytelny maszynowo inwentarz komponentów.

cdxgen (CycloneDX Generator) jest alternatywnym generatorem zoptymalizowanym dla CycloneDX, ze szczególnie silnym wsparciem dla projektów Java/Kotlin (Maven/Gradle), JavaScript/TypeScript (npm/yarn) i Python (pip/poetry). cdxgen analizuje pliki manifestów pakietów i pliki lock w celu określenia zależności przechodnich — nie tylko bezpośrednich zależności, ale zależności ich zależności na całej głębokości drzewa zależności.

VEX: komunikowanie możliwości wykorzystania podatności

SBOM identyfikuje komponenty; SBOM w połączeniu z NVD lub innymi bazami danych podatności identyfikuje, które znane CVE wpływają na te komponenty. Ale obecność CVE w komponencie nie oznacza automatycznie, że wdrożone oprogramowanie jest podatne: podatna ścieżka kodu może być nieosiągalna; konfiguracja ograniczająca może uczynić podatność niemożliwą do wykorzystania; dostawca mógł już zintegrować poprawkę bez aktualizacji wersji pakietu.

VEX (Vulnerability Exploitability eXchange) rozwiązuje ten problem, zapewniając dostawcom mechanizm komunikowania statusu możliwości wykorzystania podatności w ich konkretnych produktach. Dokument VEX może stwierdzać, że konkretna CVE: "Nie wpływa" — podatna funkcja nie jest obecna lub używana; "Wpływa" — podatność jest rzeczywiście podatna z zalecanymi działaniami; "W trakcie naprawy" — dostawca potwierdził podatność i planuje naprawę; "Naprawiona" — podatność jest naprawiona ze szczegółami konkretnej wersji.

Wymagania SBOM w zamówieniach obronnych

Dla wykonawców MON sprzedających lub planujących sprzedaż oprogramowania klientom obronnym UE i USA, zgodność SBOM staje się wymogiem kontraktowym. Praktyczne wymagania obejmują: posiadanie dokumentu SBOM w czytelnym maszynowo standardowym formacie (SPDX lub CycloneDX) obejmującym wszystkie zależności, w tym przechodnie; SBOM musi być podpisany w celu weryfikacji integralności; SBOM musi być aktualizowany przy każdym wydaniu; podatności muszą być ujawnione z odpowiednimi twierdzeniami VEX i harmonogramami usuwania.

Integracja SBOM z zarządzaniem podatnościami

SBOM jest najcenniejszy w połączeniu z ciągłym zarządzaniem podatnościami. Zautomatyzowany proces wygląda następująco: gdy publikowane jest nowe CVE, SBOM jest automatycznie odpytywany w celu ustalenia, czy dotknięty pakiet wpływa na jakikolwiek wdrożony produkt; jeśli tak, incydent zarządzania podatnościami jest otwierany automatycznie z dowodami produktu, wersji i dotkniętych wdrożeń; twierdzenia VEX są aktualizowane w miarę postępu dochodzenia; zapisy napraw są dokumentowane w odniesieniu do CVE w ostatecznym stanie VEX.