Egzekwowanie SBOM w obronnych pipeline'ach CI/CD: od CycloneDX do bramek zgodnych z NDAA

Software Bill of Materials (SBOM) przeszedł z opcjonalnego artefaktu w obowiązek kontraktowy szybciej, niż większość kontraktorów obronnych się spodziewała. W 2021 było to zalecenie ukryte w Executive Order 14028. W 2026 jest to warunek bramki — każdy binarny artefakt dostarczany klientowi z USA lub NATO musi mieć dołączony aktualny, podpisany, czytelny maszynowo SBOM, a pipeline, który go wyprodukował, musi być w stanie udowodnić w momencie audytu, że SBOM został wygenerowany z tych samych źródeł, w tym samym buildzie, co artefakt. Ten artykuł omawia decyzje inżynierskie decydujące o tym, czy twój pipeline CI/CD przetrwa ten audyt.

1. Dlaczego SBOM stał się obronnie obowiązkowy

Zbiegły się cztery wątki regulacyjne. Executive Order 14028 (maj 2021) zobowiązał federalnych dostawców oprogramowania do dostarczania SBOM i położył podwalinę pod „minimalne elementy” NTIA. NDAA Section 1655 (FY2023, doprecyzowany przez poprawki FY2026) rozszerzył wymogi SBOM na zakupy obronne, nakazując głównym kontraktorom DoD i podwykonawcom dostarczanie SBOM dla każdego oprogramowania dostarczanego do Departamentu, z konkretnymi przepisami o komponentach pochodzenia chińskiego i dostawcach z państw wrogich. NIS2 wywarł podobną presję w bazie obronnej UE, wymagając udokumentowanego zarządzania ryzykiem łańcucha dostaw dla podmiotów istotnych i ważnych. NIST SP 800-218 — Secure Software Development Framework (SSDF) — skodyfikował generowanie SBOM jako oczekiwaną praktykę dla każdego dostawcy samoatestującego się pod OMB M-22-18 i M-23-16.

Praktyczny efekt jest taki, że obronny dostawca oprogramowania bez narzędzi SBOM w 2026 nie jest konkurencyjnym dostawcą. RFP zawierają klauzule SBOM. Audyty zawierają sprawdzenia SBOM. Brakujący SBOM jest traktowany tak samo, jak brakujący raport testowy — jako dowód, że proces inżynierski dostawcy jest niekompletny. Dobra wiadomość dla zespołów inżynierskich: generowanie SBOM, raz prawidłowo oprzyrządowane, jest tanie w utrzymaniu. Zła wiadomość: „prawidłowo oprzyrządowane” skrywa długą listę decyzji architektonicznych, z których większość jest robiona źle za pierwszym razem.

2. CycloneDX vs SPDX

Istotne są dwa formaty SBOM: CycloneDX (powstały w OWASP, obecnie standard Ecma) i SPDX (powstały w Linux Foundation, ISO/IEC 5962:2021). Pokrywają tę samą koncepcyjnie domenę — komponenty, wersje, licencje, hashe, relacje — ale dialekty rozchodzą się w sposób istotny dla narzędzi.

CycloneDX jest zoptymalizowany pod kątem bezpieczeństwa: natywne wsparcie VEX, pola podatności pierwszej klasy, lekki JSON, ścisła integracja z ekosystemem OWASP (Dependency-Track, dependency-check). To format, który zespoły bezpieczeństwa produkują domyślnie. SPDX jest zoptymalizowany pod kątem licencji i proweniencji: bogatszy język wyrażeń licencyjnych, dłuższy rodowód w audytach zgodności open-source, pieczęć ISO, której zespoły prawne i procurementowe wymagają w regulowanych branżach.

Klienci obronni pytają o oba. Kontrakty zgodne z NDAA coraz częściej specyfikują „SPDX 2.3 lub nowszy, lub CycloneDX 1.5 lub nowszy”, pozostawiając wybór formatu dostawcy — do momentu, gdy narzędzia downstream klienta wymuszą jeden lub drugi. Pragmatyczny wzorzec to dual-emit: wygeneruj SBOM CycloneDX w buildzie dla wewnętrznych narzędzi podatności, a następnie przekształć do SPDX w czasie dostawy używając konwertera (open-source cyclonedx-py, cdx2spdx lub łańcucha narzędzi SPDX). Traktuj jeden jako źródło prawdy, drugi jako artefakt pochodny; trzymaj oba wersjonowane obok binarki.

3. Generowanie SBOM w czasie buildu vs po buildzie

Pojedynczy największy czynnik determinujący wiarygodność SBOM to moment, w którym SBOM jest produkowany. Są dwa obozy. Skanery po-buildowe (Trivy, Snyk, natywny dependency graph GitHuba w trybie skanowania) konsumują gotowy obraz kontenera lub binarkę i odtwarzają jej komponenty wstecznie. Generatory build-time (Syft podłączony do buildu, cdxgen, narzędzia językowe jak cargo cyclonedx, mvn cyclonedx, npm sbom) obserwują faktyczny proces buildu i emitują SBOM z rozwiązanego grafu zależności, którego build użył.

Tylko generowanie build-time jest wiarygodne przy audycie. Powód jest prosty: skaner po-buildowy identyfikuje to, co widzi — nie odróżnia biblioteki, która jest statycznie zlinkowana w binarce, od biblioteki, która została wciągnięta dla narzędzia build-time, ale nigdy nie została dostarczona. Nie widzi prywatnych rejestrów, do których skaner nie ma poświadczeń. Nie widzi generowania kodu w czasie kompilacji. Recenzent pytający „skąd wiesz, że ten SBOM jest kompletny?” dostaje wykonalną odpowiedź tylko wtedy, gdy SBOM został wyprodukowany przez sam build, z proweniencją do lockfile'ów. Skanowanie post-build to użyteczna druga opinia. Nie jest to artefakt podstawowy.

W praktyce zespoły zbiegają się na stosie: Syft dla warstw OS i kontenerów, natywne dla języka generatory (cargo, npm, pip, mvn, go-licenses z wyjściem CycloneDX) dla komponentów źródłowych, cdxgen, gdy repozytoria polyglot potrzebują pojedynczego przejścia, i Trivy lub natywny eksport SBOM GitHuba jako post-buildowy cross-check. Pipeline scala wyjścia natywne dla języka w pojedynczy dokument CycloneDX, podpisuje go i dołącza do wydanego artefaktu.

4. Podpisywanie SBOM i atestacja

Niepodpisany SBOM nie jest dowodem. Recenzent nie może zweryfikować, że został wyprodukowany przez build, który wyprodukował binarkę; nie może zweryfikować, że nie był edytowany; nie może udowodnić, że środowisko buildu było zaufane. Rozwiązanie to atestacja — podpisane oświadczenie wyprodukowane przez system buildu, wiążące SBOM z konkretnym hashem artefaktu.

Dominujące prymitywy to sigstore/cosign dla keyless signing (certyfikaty związane z OIDC, transparency log w Rekor) i atestacje in-toto dla formatu oświadczenia. Atestacja in-toto ma trzy części: subject (hash atestowanego artefaktu), typ predykatu (np. https://cyclonedx.org/bom lub typ proweniencji SLSA) i ciało predykatu (sam SBOM lub proweniencja buildu). Cosign podpisuje atestację, dołącza jako artefakt OCI obok obrazu kontenera i wypycha podpis do transparency log Rekor.

Framework SLSA (Supply-chain Levels for Software Artifacts) to model dojrzałości, do którego odnoszą się klienci obronni, gdy chcą pojedynczej liczby zakotwiczającej ich wymagania. SLSA 1 oznacza, że istnieje proweniencja. SLSA 2 oznacza, że jest podpisana, a usługa buildu jest hostowana. SLSA 3 oznacza, że build jest izolowany, a proweniencja nie do sfałszowania przez sam projekt. SLSA 4 oznacza dwustronny przegląd i hermetyczne, reprodukowalne buildy. Większość kontraktów obronnych w 2026 wymaga SLSA 3 jako podłogi dla oprogramowania dostarczanego do środowisk operacyjnych; SLSA 2 jest akceptowalne dla niewdrażanych narzędzi. SLSA 4 pozostaje rzadkie poza obciążeniami najwyższej klasyfikacji.

5. Warstwa korelacji podatności

SBOM to lista komponentów; sam w sobie nie jest raportem podatności. Warstwa korelacji łączy SBOM z bazami podatności (NVD, OSV, GitHub Advisory Database), produkując listę podatności per artefakt. To tu większość zespołów odkrywa, że 80% raportowanych podatności w ich SBOM nie jest wykorzystywalna w ich kontekście — podatna funkcja nigdy nie jest wywoływana, dotknięta konfiguracja nigdy nie jest włączona lub ścieżka jest nieosiągalna z żadnej zewnętrznej powierzchni.

Wystandaryzowany sposób komunikowania tego to VEX (Vulnerability Exploitability eXchange). Oświadczenie VEX deklaruje dla konkretnego CVE wobec konkretnej wersji produktu jeden z czterech statusów: not_affected, affected, fixed lub under_investigation, z uzasadnieniem (np. vulnerable_code_not_in_execute_path). CycloneDX wspiera VEX natywnie; SPDX wspiera go przez towarzyszący format CSAF (Common Security Advisory Framework). Klient obronny recenzujący twój SBOM oczekuje zobaczenia oświadczeń VEX wyjaśniających otwarte CVE — nie ciszy.

Przepływ operacyjny wygląda tak: SBOM generowany w buildzie → skanowanie podatności wobec OSV/NVD → triage w narzędziu jak Dependency-Track → inżynier składa oświadczenie VEX z uzasadnieniem → VEX dołączony jako podpisana atestacja in-toto obok SBOM. Audytor klienta widzi spójną historię dla każdego CVE.

6. Logika bramek CI

SBOM i oświadczenia VEX wymuszają higienę łańcucha dostaw tylko wtedy, gdy pipeline na nich blokuje. Bramka siedzi między „build się powiódł” a „artefakt wydania promowany”. Nowoczesne zespoły piszą bramkę jako politykę w Rego (Open Policy Agent) lub Kyverno, oceniana wobec wejść SBOM i VEX.

Wykonalna polityka egzekwuje cztery reguły. Pierwsza: żadnych krytycznych CVE bez uzasadnienia VEX. Druga: żadnych komponentów z listy zakazanej rodzin licencji (AGPL w deliverable'ach proprietarnych, cokolwiek z klauzulą pochodzenia kontrolowanego eksportowo USA). Trzecia: żadnych komponentów z rejestrów państw objętych sankcjami (tu żyje NDAA 1655 — pakiety pochodzenia chińskiego flagowane automatycznie). Czwarta: SBOM musi być podpisany, proweniencja buildu musi twierdzić SLSA 3 lub wyższy, a wpis w transparency log Rekor musi istnieć.

Waivery (zwolnienia) to miejsce, gdzie większość polityk zawodzi w praktyce. Blanket'owe „ignoruj to CVE na zawsze” to wzorzec niepowodzenia audytu. Wzorcem przeżywającym audyt jest waiver z uzasadnieniem i terminem wygaśnięcia: plik waivera żyje w repo, jest recenzowany w pull requeście, nazywa CVE i artefakt, zawiera pisemne uzasadnienie (te same pola uzasadnienia VEX) i ma datę wygaśnięcia. Pipeline akceptuje waiver tylko, dopóki nie wygasł. Audytorzy uwielbiają ten wzorzec, bo produkuje pisemny ślad decyzji o ryzyku; inżynierowie go tolerują, bo to skończona praca.

7. Dostawa do klienta

SBOM to nie tylko artefakt buildu — to deliverable kontraktowy. Kontrakty obronne w 2026 rutynowo zawierają klauzule o formacie SBOM, podpisywaniu, mechanizmie dostawy i kadencji aktualizacji. Negocjacja formatu odbywa się zwykle przy podpisywaniu kontraktu: dostawca proponuje CycloneDX 1.5 JSON, klient kontrproponuje SPDX 2.3, bo jego narzędzie downstream tego wymaga, a dostawca zobowiązuje się do dual-emit. Dostawa odbywa się zwykle przez kontrolowany przez klienta rejestr lub portal — nigdy przez załączniki email, których polityka bezpieczeństwa informacji klienta zabrania.

Obowiązek powracających aktualizacji to klauzula, którą większość dostawców niedoszacowuje. Kontrakty zgodne z NDAA zazwyczaj wymagają zaktualizowanego SBOM przy każdym wydaniu poprawkowym, każdym kwartalnym wydaniu utrzymaniowym i w ciągu 72 godzin od ujawnienia jakiegokolwiek CVE w zakresie. Jeśli twój proces wydania trwa tydzień, nie spełnisz zegara 72 godzin. Rozwiązanie to uczynienie emisji SBOM automatyczną przy każdym wydaniu, włącznie z wydaniami poprawkowymi, tak by SBOM był zawsze aktualny z binarką, którą klient uruchamia. Dostawcy próbujący regenerować SBOM ręcznie po wydaniu kończą tłumacząc luki recenzentom akredytacji — patrz też jak ograniczenia poświadczeń i personelu wpływają na to, co twój zespół może dostarczyć.

8. Przetrwanie audytu

Recenzent akredytacji przybywa. Zadaje trzy pytania. Pokaż mi SBOM dla wersji 2.4.1, którą uruchamiamy w produkcji. Twój rejestr zwraca podpisany dokument CycloneDX z atestacją in-toto wskazującą na hash binarki, którą klient zainstalował. Pokaż mi oświadczenia VEX dla każdego „high” CVE w tym SBOM. Twój rejestr zwraca pakiet VEX z uzasadnieniami i datami. Pokaż mi, jak dowiedziałbyś się dziś, że ujawniono nowe CVE wobec dowolnego komponentu w tym SBOM. Pokazujesz im ciągły skan działający wobec korpusu SBOM oraz SLA powiadomienia klienta.

Pipeline odpowiadający na te trzy pytania czysto to pipeline, który przetrwa. Pipeline, który nie potrafi — bo SBOM został wygenerowany post-hoc, oświadczenia VEX żyją w arkuszu kalkulacyjnym lub nikt nie śledzi ujawnień CVE wobec wydanych SBOM — to pipeline, który traci kontrakt przy odnowieniu. Inwestycja jest skończona; konsekwencja jej nie podjęcia nie jest. Dla szerszego ujęcia łańcucha dostaw zobacz nasz przegląd SBOM w oprogramowaniu obronnym, kompletny przewodnik po cyberbezpieczeństwie obronnym oraz deep-dive DevSecOps + zero trust, który siedzi warstwę wyżej niż ta praca pipeline'owa.