Od pipeline'u do decyzji dla konkretnego wydania
GitLab CI/CD lub wybrane narzędzie generuje artefakt SBOM. Workspace przypisuje go do dokładnego produktu, wariantu klienta i release'u, a obserwacje podatności pozostawia do oceny człowieka.
GitLab SBOM zaczyna się w pipeline CI/CD
Oficjalna dokumentacja GitLab opisuje CycloneDX jako obsługiwany typ raportu CI/CD, a Dependency Scanning może tworzyć osobny SBOM dla wykrytego lockfile'u, manifestu lub eksportu grafu zależności. Pliki są zachowywane jako job artifacts i mogą zasilać dalszy proces bezpieczeństwa.
Dostępność wbudowanych raportów, skanowania i widoków GitLab zależy od wersji, planu oraz sposobu wdrożenia GitLab.com, Self-Managed lub Dedicated. Alternatywą jest uruchomienie zewnętrznego generatora, na przykład Syft, we własnym pipeline i przekazanie wynikowego CycloneDX do kontrolowanego procesu CRA.
- generowanie dla taga lub innego jawnie wybranego momentu wydania
- maszynowo czytelny CycloneDX JSON jako artefakt joba
- zachowanie pipeline ID, job ID, commit SHA i nazwy taga
- brak sekretu w pliku `.gitlab-ci.yml`; token pozostaje chronioną zmienną CI/CD
- walidacja formatu przed aktywacją snapshotu SBOM
Od GitLab repository do kontrolowanego rekordu CRA
| Etap | Co powstaje | Granica |
|---|---|---|
| GitLab repository | kod, manifesty, lockfile'e i konfiguracja pipeline'u | Workspace nie pobiera ani nie uruchamia kodu repozytorium |
| CI/CD pipeline | job generatora przypisany do commita i taga | narzędzie działa w infrastrukturze GitLab klienta |
| CycloneDX SBOM | wersjonowany plik JSON z komponentami i relacjami | plik jest inventory, a nie oceną podatności lub zgodności |
| CRA Workspace | niezmienny Evidence i snapshot dla dokładnego targetu | import nie tworzy automatycznej decyzji AFFECTED |
Product, Customer Variant i Release — SBOM potrzebuje dokładnego targetu
Ten sam projekt GitLab może budować kilka produktów, edycji lub wdrożeń klientów. Dlatego sam project ID nie wystarcza. Connector powinien wskazywać istniejący Product oraz — jeżeli dotyczy — dokładną, niezmienną rewizję Customer Deployment z jej bazowym Product Release.
Dla zakresu wariantu klienta tag pipeline'u musi odpowiadać wersji bazowego release'u przed utworzeniem Evidence. Nowe wydanie tworzy nowy snapshot; nie nadpisuje historii komponentów poprzedniej wersji.
- GitLab instance URL, numeric project ID i canonical project path
- dokładny Product z Product Inventory
- opcjonalna Customer Deployment Revision należąca do tego produktu
- tag zgodny z Product Release
- checksum pliku, format, generator i pipeline provenance
CycloneDX → CVE/OSV → Human Triage
Po walidacji komponenty z GitLab CycloneDX można zestawiać z obserwacjami CVE, OSV albo raportem Dependency Scanning. Dopasowanie powinno opierać się na wiarygodnej tożsamości pakietu i wersji; nierozstrzygnięte lub sprzeczne rekordy muszą pozostać jawne.
Obecność komponentu i znalezienie rekordu podatności nie oznaczają automatycznie, że konkretne wydanie produktu jest podatne. Human triage ocenia używaną funkcję, konfigurację, reachability, zabezpieczenia i dowody dla właściwego release'u lub wariantu.
VEX, remediation i Article 14 są osobnymi etapami
Sfinalizowana ocena człowieka może zostać zapisana jako wersjonowane stanowisko VEX. Jeżeli wydanie jest AFFECTED, osobny Remediation Case łączy plan naprawy z target release'em, fixed release'em, rolloutem aktualizacji i evidence zamknięcia.
Article 14 wymaga oddzielnego Reportability Review. CVE, wynik OSV, finding skanera, status AFFECTED ani wygenerowany SBOM nie są same w sobie wiarygodnym dowodem aktywnego wykorzystania przez złośliwego aktora i nie powinny automatycznie tworzyć zgłoszenia lub terminu.
Cztery kontrolowane profile pipeline'u
CRA Workspace generuje zamknięty szablon YAML z regułą tag-only, stałym endpointem i odwołaniem do chronionej zmiennej tokenu. Nie przechowuje GitLab PAT/OAuth, nie odpytuje GitLab API, nie hostuje runnera i nie pozwala wstrzyknąć dowolnej komendy powłoki.
| Profil | Źródło SBOM | Wynik |
|---|---|---|
| Syft CycloneDX | przypięty generator uruchamiany w GitLab CI | CycloneDX JSON bez automatycznych findings |
| Syft SPDX | przypięty generator uruchamiany w GitLab CI | SPDX JSON 2.3 bez automatycznych findings |
| GitLab Dependency Scanning | artefakty wytworzone przez funkcję GitLab | CycloneDX oraz raport dependency scanning |
| Existing SBOM | istniejący artefakt z własnego joba | wspierany CycloneDX JSON albo SPDX JSON |
Praktyczny model dla software house'u
Software house może utrzymywać pipeline w repozytorium klienta lub produktu, generować SBOM przy tagowanym wydaniu i przekazywać go do dokładnego kontekstu w Workspace. Producent nadal zatwierdza target, ocenę wpływu i dalsze działania; wykonawca nie przejmuje przez sam pipeline prawnej odpowiedzialności za zgodność produktu.
- jeden powtarzalny proces dla wielu repozytoriów i klientów
- oddzielne mapowanie bazowego produktu oraz jego wariantów
- historia SBOM per release zamiast jednego nadpisywanego pliku
- jawne przekazanie od DevSecOps do Product Security i Compliance
- dowody techniczne gotowe do dalszego, ludzkiego przeglądu
GitLab SBOM i CRA — FAQ
Czy GitLab może generować SBOM w formacie CycloneDX?
Tak. Oficjalna dokumentacja GitLab opisuje CycloneDX jako typ raportu CI/CD, a Dependency Scanning może tworzyć pliki CycloneDX dla obsługiwanych lockfile'ów, manifestów lub grafów zależności. Konkretna dostępność zależy od wersji, planu i modelu wdrożenia GitLab.
Czy można użyć własnego generatora SBOM w GitLab CI/CD?
Tak. Pipeline może uruchomić zewnętrzne narzędzie, na przykład przypiętą wersję Syft, zapisać CycloneDX lub SPDX jako artefakt i przekazać plik do Workspace. Generator działa w GitLab CI klienta, nie na serwerze CRACompliance.
Czy CRA Workspace potrzebuje dostępu do repozytorium GitLab?
Nie. Integracja jest push-based. Chroniony job wysyła gotowy SBOM i metadane pipeline'u do stałego endpointu. Workspace nie przechowuje GitLab PAT/OAuth i nie pobiera kodu źródłowego.
Czy GitLab SBOM potwierdza zgodność z Cyber Resilience Act?
Nie. SBOM jest źródłem informacji o komponentach i relacjach. Nie stanowi opinii prawnej, oceny zgodności, certyfikacji ani potwierdzenia zgodności produktu z CRA.
Jak przypisać SBOM do wariantu produktu klienta?
Connector wskazuje dokładny Product i opcjonalną niezmienną Customer Deployment Revision. Pipeline tag musi odpowiadać jej bazowemu Product Release, a import nie może tworzyć ani zmieniać konfiguracji wdrożenia.
Czy finding CVE lub OSV automatycznie uruchamia Article 14?
Nie. Finding jest obserwacją źródłową, a AFFECTED jest oceną wpływu na produkt. Article 14 wymaga osobnego przeglądu ustawowych przesłanek i dostępnych dowodów, w tym dotyczących aktywnego wykorzystania oraz momentu uzyskania wiedzy.
Oficjalne źródła
Podstawa materiału została sprawdzona 5 września 2026.