BSI TR-03183: poziomy jakości SBOM a zgodność z CRA

Rozporządzenie (UE) 2024/2847 nakłada obowiązek sporządzenia wykazu komponentów oprogramowania (SBOM), pozostawiając jednak szczegóły techniczne innym dokumentom. Załącznik I, część II, punkt 1 wymaga opracowania SBOM w formacie nadającym się do odczytu maszynowego, obejmującego co najmniej zależności najwyższego poziomu produktu, i w tym miejscu szczegółowość regulacji się kończy. Brak listy pól. Brak minimalnej wersji formatu. Brak schematu dla powiadomień o podatnościach. Federalny Urząd ds. Bezpieczeństwa Informacji w Niemczech (BSI) wypełnił tę lukę dokumentem BSI TR-03183: trójelementową wytyczną techniczną, która wskazuje dokładne wersje formatów, wymienia wszystkie wymagane pola i wiąże generowanie SBOM z publikowaniem powiadomień o podatnościach. Należy traktować ją jako praktyczną specyfikację uzupełniającą obowiązek prawny, a nie jako konkurencyjne rozporządzenie.

Czym jest BSI TR-03183

BSI jest niemiecką krajową agencją ds. cyberbezpieczeństwa. Wytyczna techniczna TR-03183 nosi pełny tytuł Cyber Resilience Requirements for Manufacturers and Products i składa się z odrębnie numerowanych oraz wersjonowanych części. Dokument jest skierowany do producentów przygotowujących się do stosowania aktu o cyberodporności i przekłada obowiązki wynikające z Załącznika I CRA na konkretne, weryfikowalne wymagania techniczne.

Trzy części dokumentu, z wersjami aktualnymi w chwili opracowania niniejszego artykułu:

Część	Wersja	Data wydania	Zakres
Część 1	v0.10.0	2025-09-12	Ogólne wymagania dotyczące cyberodporności wynikające z CRA, oparte na Załączniku I, Załączniku II i Załączniku VII
Część 2	v2.1.0	2025-08-20	Wykaz komponentów oprogramowania (SBOM): formaty, pola, generowanie i aktualizacje
Część 3	v1.0.0	2025-08-20	Zgłoszenia i powiadomienia o podatnościach, w tym CVD, security.txt i porady CSAF

Część 1 §1 określa wytyczną jako dokument przejściowy:

"This Technical Guideline will be superseded in the current form as soon as its content is covered by the corresponding standardisation deliverables under the aforementioned standardisation request."

To zdanie pokazuje, jak należy traktować TR-03183. Jest to interpretacja BSI dotycząca tego, jak powinien wyglądać zgodny z CRA program SBOM i zarządzania podatnościami, dopóki zharmonizowane normy CEN/CENELEC pozostają w fazie opracowywania. Gdy te normy zostaną opublikowane, to właśnie one będą miały pierwszeństwo. Do tego czasu TR-03183 jest najbardziej szczegółową publicznie dostępną specyfikacją powiązaną z Załącznikiem I CRA.

graph LR
    A[BSI TR-03183]
    A --- P1[Część 1
Ogólne wymagania
dotyczące CRA]
    A --- P2[Część 2
SBOM]
    A --- P3[Część 3
Zgłoszenia i powiadomienia
o podatnościach]
    P2 --- F1[CycloneDX 1.6
lub SPDX 3.0.1]
    P2 --- F2[Pola wymagane, dodatkowe
i opcjonalne]
    P3 --- C1[CSAF 2.0
porady]
    P3 --- C2[security.txt
znacznik CSAF]
    style A fill:#008080,stroke:#005f5f,color:#fff
    style P1 fill:#e8f4f8,stroke:#008080,color:#333
    style P2 fill:#e8f4f8,stroke:#008080,color:#333
    style P3 fill:#e8f4f8,stroke:#008080,color:#333
    style F1 fill:#f8fafc,stroke:#008080,color:#333
    style F2 fill:#f8fafc,stroke:#008080,color:#333
    style C1 fill:#f8fafc,stroke:#008080,color:#333
    style C2 fill:#f8fafc,stroke:#008080,color:#333

Luki w CRA, które wypełnia TR-03183

Przepisy CRA dotyczące SBOM można przeczytać od początku do końca bez uzyskania informacji o tym, jakie pola powinien zawierać dokument, która wersja formatu spełnia obowiązek lub jak publikować wynikające z niego powiadomienia. TR-03183 wypełnia trzy konkretne luki.

Luka w tekście CRA	Co określa TR-03183
Załącznik I, część II, punkt 1 wymaga SBOM, ale nie wymienia żadnych pól danych	Część 2 §5.2 wylicza pola Required, Additional i Optional zarówno na poziomie dokumentu SBOM, jak i każdego komponentu
CRA stwierdza, że formaty muszą być „powszechnie stosowane i nadające się do odczytu maszynowego", bez wskazania konkretnych formatów	Część 2 §4 stanowi: „CycloneDX, version 1.6 or higher" lub „System Package Data Exchange (SPDX), version 3.0.1 or higher"
Artykuł 14 wymaga zgłaszania aktywnie wykorzystywanych podatności do ENISA bez określenia publicznego formatu porady	Część 3 §4.2.8 i §5.1.6 dostosowują porady do CSAF 2.0 i przywołują ISO/IEC 20153:2025

Szczegóły tych obowiązków po stronie CRA można znaleźć w artykule Wymagania CRA dotyczące SBOM. Kontekst terminów i sankcji, który wyznacza pilność działań, opisuje artykuł Terminy i sankcje dotyczące zgodności SBOM.

Pola Required, Additional i Optional w Części 2

Część 2 w wersji 2.1.0 nie posługuje się pojęciami „Basic", „Standard" ani „Comprehensive". Każdy diagram producenta lub zestawienie, które przedstawia trzy nazwane „poziomy jakości" z tymi etykietami, wprowadza strukturę nieobecną w specyfikacji. Model zgodności w wersji 2.1.0 jest binarny na poziomie pola: pole jest Required (zawsze obecne), Additional (obowiązkowe, gdy dane istnieją) albo Optional.

Trzy kategorie wraz z sekcjami specyfikacji:

Kategoria	Sekcja specyfikacji	Znaczenie	Przykłady
Required dla samego SBOM	§5.2.1	Pola na poziomie dokumentu, które MUSZĄ zawsze być obecne	Autor SBOM, Znacznik czasu
Required dla każdego komponentu	§5.2.2	Pola na poziomie komponentu, które MUSZĄ zawsze być obecne	Nazwa komponentu, Wersja komponentu, Licencje dystrybucyjne, Skrót (SHA-512), Zależności od innych komponentów, Nazwa pliku, Właściwość Executable, Właściwość Archive, Właściwość Structured, Autor komponentu
Additional dla każdego komponentu	§5.2.4	Obowiązkowe, jeśli dane istnieją; w przeciwnym razie pomijane	URI kodu źródłowego, URI wersji komponentu nadającej się do wdrożenia, Inne unikalne identyfikatory (CPE, purl), Oryginalne licencje
Optional dla każdego komponentu	§5.2.5	MOGĄ być uwzględnione	Licencja efektywna, Wartość skrótu kodu źródłowego, URL pliku security.txt

Część 2 nakłada również w §5.1 wymóg rekurencyjnego rozwiązywania zależności: rozwiązanie zależności MUSI być przeprowadzone dla każdego komponentu objętego zakresem dostawy. Jest to odpowiedź specyfikacji na niejasne sformułowanie CRA dotyczące „zależności najwyższego poziomu" z Załącznika I, część II, punkt 1. TR-03183 oczekuje przejścia przez całe drzewo zależności, a nie zatrzymania się na bezpośrednich zależnościach.

Wymagania dla poszczególnych pól

Pełne zestawienie pól najczęściej pytanych przez zespoły, wraz z sekcjami specyfikacji v2.1.0.

Pole	Kategoria	Sekcja specyfikacji	Uwagi
Autor SBOM	Required (poziom SBOM)	§5.2.1	Adres e-mail lub URL producenta
Znacznik czasu	Required (poziom SBOM)	§5.2.1	ISO 8601
Nazwa komponentu	Required	§5.2.2	Zawsze wypełniane dla każdego wpisu
Wersja komponentu	Required	§5.2.2	Dokładna wersja, nie zakres
Autor komponentu	Required	§5.2.2	Odpowiada polu „Supplier" w starszym nazewnictwie
Nazwa pliku komponentu	Required	§5.2.2	Często brakuje w domyślnych danych wyjściowych narzędzi
Zależności od innych komponentów	Required	§5.2.2	Rekurencyjne zgodnie z §5.1
Licencje dystrybucyjne	Required	§5.2.2	Licencje obowiązujące przy dystrybucji
Skrót komponentu nadającego się do wdrożenia	Required	§5.2.2	SHA-512
Właściwość Executable	Required	§5.2.2	Wartość logiczna: czy komponent jest wykonywalny?
Właściwość Archive	Required	§5.2.2	Wartość logiczna: czy komponent jest archiwum?
Właściwość Structured	Required	§5.2.2	Wartość logiczna: wskaźnik strukturalnego ładunku
URI kodu źródłowego	Additional	§5.2.4	Obowiązkowe, gdy jest znane
URI komponentu nadającego się do wdrożenia	Additional	§5.2.4	Obowiązkowe, gdy jest znane
Inne unikalne identyfikatory (CPE, purl)	Additional	§5.2.4	Obowiązkowe, gdy dostępne; nie bezwarunkowo wymagane
Oryginalne licencje	Additional	§5.2.4	Licencja upstream przed dystrybucją
Licencja efektywna	Optional	§5.2.5	Wynik uzgodnienia licencji
Skrót kodu źródłowego	Optional	§5.2.5	Skrót źródła przed kompilacją
URL pliku security.txt	Optional	§5.2.5	Wskaźnik do punktu wejścia ujawniania podatności

Najbardziej zaskakującym wierszem dla wielu zespołów jest Inne unikalne identyfikatory (CPE, purl). Zespoły traktują adresy URL pakietów jako główny klucz SBOM. W TR-03183 Część 2 v2.1.0 purl należy do kategorii Additional: jest obowiązkowy tylko wtedy, gdy dane istnieją. Bezwarunkowym identyfikatorem komponentu jest skrót SHA-512 artefaktu nadającego się do wdrożenia, w połączeniu z nazwą i wersją. Jeśli narzędzie nie może obliczyć purl dla prywatnej biblioteki wewnętrznej, nie narusza to zgodności. Jeśli nie może obliczyć SHA-512, to narusza. Artykuł Typowe błędy SBOM omawia powiązane braki w polach.

Obsługa formatów CycloneDX i SPDX

Część 2 §4 wskazuje akceptowane formaty i minimalne wersje:

"A newly generated or updated SBOM MUST be in JSON- or XML-format and a valid SBOM according to one of the following specifications in one of the specified versions: CycloneDX, version 1.6 or higher"

Powyższy cytat pochodzi bezpośrednio z tekstu specyfikacji. BSI publikuje TR-03183 wyłącznie w językach niemieckim i angielskim, dlatego przytoczony fragment pozostaje w oryginale. W praktyce oznacza to, że nowo wygenerowany lub zaktualizowany SBOM musi być w formacie JSON lub XML i stanowić prawidłowy SBOM zgodny z jedną z wymienionych specyfikacji.

"System Package Data Exchange (SPDX), version 3.0.1 or higher"

Powyższy cytat pochodzi bezpośrednio z tekstu specyfikacji. Drugą akceptowaną specyfikacją jest System Package Data Exchange (SPDX) w wersji 3.0.1 lub wyższej.

Informacje o wydaniach v2.1.0 dokumentują również ścieżkę aktualizacji: v2.0.0 (2024-09-20) podniósł wymagania z CycloneDX 1.4 do 1.5 i SPDX z wcześniejszych wersji do 2.2.1. Wersja v2.1.0 (2025-08-20) podniosła wymagania z CycloneDX 1.5 do 1.6 i SPDX z 2.2.1 do 3.0.1.

W praktyce narzędzia domyślnie generujące dane wyjściowe w formacie CycloneDX 1.4 (nadal powszechne w starszych konfiguracjach CI) są niezgodne z v2.1.0. CycloneDX 1.6 wprowadził ulepszoną obsługę zasobów kryptograficznych i BOM dla modeli ML; SPDX 3.0.1 to gruntowna przebudowa z nowym modelem ładunku. Linia bazowa CI wymaga jawnej flagi --spec-version 1.6 lub jej odpowiednika. Porównanie obu formatów i dojrzałości narzędzi można znaleźć w artykule CycloneDX a SPDX.

Szkielet CycloneDX 1.6 zgodny z TR-03183, z wypełnionymi polami Required na poziomie dokumentu:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2027-01-15T10:00:00Z",
    "tools": [
      { "vendor": "Example", "name": "syft", "version": "1.10.0" }
    ],
    "authors": [
      { "name": "Example GmbH security team", "email": "security@example.de" }
    ],
    "component": {
      "type": "firmware",
      "name": "SmartSensor Pro",
      "version": "2.4.1",
      "supplier": { "name": "Example GmbH", "url": ["https://example.de"] },
      "purl": "pkg:firmware/example/smartsensor-pro@2.4.1"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "openssl",
      "version": "3.0.12",
      "purl": "pkg:generic/openssl@3.0.12",
      "licenses": [{ "license": { "id": "Apache-2.0" } }],
      "hashes": [
        { "alg": "SHA-512", "content": "ddaf35a193617aba..." }
      ],
      "supplier": { "name": "OpenSSL Software Foundation" },
      "properties": [
        { "name": "executable", "value": "true" },
        { "name": "archive", "value": "false" }
      ]
    }
  ],
  "dependencies": [
    {
      "ref": "pkg:firmware/example/smartsensor-pro@2.4.1",
      "dependsOn": ["pkg:generic/openssl@3.0.12"]
    }
  ]
}

Wpisy authors, timestamp oraz hashes SHA-512 to pola Required na poziomie dokumentu i komponentu, których najczęściej brakuje w domyślnych ustawieniach CI. Przed uznaniem danych wyjściowych za zgodne z TR-03183 należy je zweryfikować poleceniem cyclonedx-cli validate --input-version 1.6.

Relacja TR-03183 z CSAF i VEX

TR-03183 rozdziela mechanikę SBOM i powiadomień o podatnościach między Część 2 i Część 3. Zasada główna jest prosta: CSAF jest zalecany w Części 2 i operacyjnie wymagany dla publikacji security.txt w Części 3. VEX nigdy nie jest nakazane.

Mechanizm	Lokalizacja w TR-03183	Moc	Znaczenie
CSAF 2.0 jako format porad	Część 2 §8.1.14	Zalecane	„The recommended format for distributing vulnerability information is CSAF (including also VEX as a profile)"
Znacznik CSAF w security.txt	Część 3 §4.2.8 (b)	MUSI	Wpis w pliku security.txt odwołujący się do dokumentów CSAF musi zaczynać się od znacznika CSAF:
URI metadanych dostawcy	Część 3 §4.2.8 (a)	POWINIEN	Producent POWINIEN udostępnić URI pliku provider-metadata.json dla dokumentów CSAF
ISO/IEC 20153:2025	Część 3 §5.1.6	Odniesienie	Międzynarodowa forma standardowa CSAF v2.0
VEX	Część 2 §1 i §8.1.14	Informacyjne	VEX jest opisany jako profil CSAF oraz jeden z kilku kanałów „should" dla informacji o podatnościach

CSAF (Common Security Advisory Framework) w wersji 2.0 jest standardem OASIS opublikowanym 18 listopada 2022 r., z erratą 01 wydaną 26 stycznia 2024 r. Definiuje schemat JSON dla powiadomień o bezpieczeństwie nadających się do odczytu maszynowego. Niemieckie CERT-y (BSI-CERT, CERT-Bund) domyślnie publikują i przyjmują porady w formacie CSAF. Standardowym zestawem narzędzi jest edytor Secvisogram oraz walidator CSAF OASIS.

Powiązanie z Artykułem 14 jest subtelniejsze, niż sugeruje część komentarzy. Artykuł 14 CRA wyznacza terminy zgłaszania do ENISA i koordynującego CSIRT (24 godziny na wczesne ostrzeżenie, 72 godziny na powiadomienie o podatności i 14 dni na raport końcowy). Nie określa publicznego formatu porady. Część 3 TR-03183 wypełnia tę lukę: po powiadomieniu ENISA dokument CSAF publikowany w ramach security.txt jest artefaktem operacyjnym, który klienci przyjmują do swoich systemów. Bez wdrożonego narzędzia CSAF przed 11 września 2026 r. można nadal spełnić wymagania Artykułu 14, ale nie spełni się oczekiwań języka zakupowego i specyfikacji security.txt wynikających z TR-03183.

VEX wymaga osobnego omówienia. Część 2 §8.1.14 wymienia VEX jako profil CSAF, a Część 2 §1 wskazuje go jako jeden z możliwych kanałów „wymiany informacji o podatnościach". Część 3 nie wspomina VEX w ogóle. Z perspektywy CRA VEX jest przydatny do składania oświadczeń not_affected na poziomie komponentu, co zapobiega zmęczeniu alertami, gdy SBOM zawiera bibliotekę ze znanych CVE, która faktycznie nie jest osiągalna z kodu. VEX nie jest obowiązkiem wynikającym z TR-03183. Warto stosować go tam, gdzie przynosi realną wartość.

Czy TR-03183 obowiązuje poza Niemcami?

TR-03183 jest niemiecką krajową wytyczną techniczną wydaną przez BSI, a nie ogólnounijnym rozporządzeniem. Żadna z trzech części nie twierdzi, że ma zastosowanie poza granicami Niemiec. Część 1 §1 wprost przewiduje, że wytyczna zostanie zastąpiona przez zharmonizowane normy CEN/CENELEC po ich opublikowaniu w ramach wniosku o normalizację CRA.

W praktyce trzy czynniki sprawiają, że TR-03183 jest istotna dla producentów spoza Niemiec.

Po pierwsze, rynek niemiecki jest największym rynkiem w UE, a niemieckie procesy zakupowe w przedsiębiorstwach coraz częściej wprost odwołują się do TR-03183. Sprzedając klientowi z Niemiec, należy spodziewać się zapisów odnoszących się do TR-03183 w kwestionariuszach bezpieczeństwa i umowach dostawcy.

Po drugie, w chwili opracowania niniejszego artykułu nie istnieje alternatywna specyfikacja powiązana z CRA o porównywalnym poziomie szczegółowości. Zharmonizowane normy CEN/CENELEC w ramach wniosku o normalizację CRA wciąż są w fazie opracowywania. TR-03183 jest najbliższym dostępnym odniesieniem.

Po trzecie, Część 1 TR-03183 jest wprost odniesiona do Załącznika I, Załącznika II i Załącznika VII CRA. Producent, który buduje dokumentację zgodnie z TR-03183, wygeneruje treść Załącznika VII (w szczególności punkt 2(b) i punkt 8 dotyczące SBOM), którą każdy organ nadzoru rynku UE jest w stanie odczytać. Pełna lista zawartości dokumentacji technicznej znajduje się w artykule Dokumentacja techniczna Załącznika VII.

Dobrowolne wdrożenie TR-03183 jest uzasadnionym wyborem inżynierskim, ale nie wymogiem prawnym poza Niemcami. Jeśli produkty nie zawierają komponentu sprzętowego, na tym analiza się kończy. Jeśli zawierają, ten sam dokument może zawierać wpisy z HBOM obok komponentów programowych.

Co zrobić dalej