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. 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łącznik 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łącznik I, Załącznik II i Załącznik 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

BSI 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łącznik 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
CRA wymaga SBOM, ale nie wymienia żadnych pól danych (Załącznik I część II (1))	TR-03183 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	TR-03183 wskazuje je: „CycloneDX, version 1.6 or higher" lub „System Package Data Exchange (SPDX), version 3.0.1 or higher"
CRA wymaga zgłaszania aktywnie wykorzystywanych podatności do koordynującego CSIRT i ENISA bez określenia publicznego formatu porady (Artykuł 14)	TR-03183 dostosowuje porady do CSAF 2.0 i przywołuje ISO/IEC 20153:2025

Szczegóły tych obowiązków po stronie CRA można znaleźć w artykule Wymagania CRA dotyczące SBOM. Zegar zgłoszeń z art. 14, który sprawia, że aktualne dane o komponentach są operacyjnie ważne, opisuje zgłaszanie podatności i incydentów w CRA.

Pola Required, Additional i Optional

TR-03183 v2.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 pól:

Kategoria	Znaczenie	Przykłady
Required dla samego SBOM	Pola na poziomie dokumentu, które MUSZĄ zawsze być obecne	Autor SBOM, Znacznik czasu
Required dla każdego komponentu	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	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	MOGĄ być uwzględnione	Licencja efektywna, Wartość skrótu kodu źródłowego, URL pliku security.txt

TR-03183 nakłada również wymóg rekurencyjnego rozwiązywania zależności: rozwiązanie zależności jest przeprowadzane dla każdego komponentu objętego zakresem dostawy, a nie tylko dla zależności bezpośrednich. Jest to odpowiedź specyfikacji na niejasne sformułowanie CRA dotyczące „zależności najwyższego poziomu" z Załącznik I część II (1): przejście przez całe drzewo zależności.

Wymagania dla poszczególnych pól

Pola najczęściej pytane przez zespoły, wraz z ich kategorią w wersji 2.1.0.

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

TR-03183 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 obejmuje łącznie mechanikę SBOM i powiadomień o podatnościach. Zasada główna jest prosta: CSAF jest zalecany dla porad i operacyjnie wymagany dla publikacji security.txt. VEX nigdy nie jest nakazane.

Mechanizm	Moc	Znaczenie
CSAF 2.0 jako format porad	Zalecane	„The recommended format for distributing vulnerability information is CSAF (including also VEX as a profile)"
Znacznik CSAF w security.txt	MUSI	Wpis w pliku security.txt odwołujący się do dokumentów CSAF musi zaczynać się od znacznika CSAF:
URI metadanych dostawcy	POWINIEN	Producent POWINIEN udostępnić URI pliku provider-metadata.json dla dokumentów CSAF
ISO/IEC 20153:2025	Odniesienie	Międzynarodowa forma standardowa CSAF v2.0
VEX	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ł 14 jest subtelniejsze, niż sugeruje część komentarzy. Article 14 CRA wyznacza terminy zgłaszania do ENISA i koordynującego CSIRT (24 godziny na wczesne ostrzeżenie, 72 godziny na powiadomienie, raport końcowy 14 dni po udostępnieniu poprawki w przypadku aktywnie wykorzystywanej podatności lub miesiąc po powiadomieniu w przypadku poważnego incydentu). Nie określa publicznego formatu porady. 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 Article 14, ale nie spełni się oczekiwań języka zakupowego i specyfikacji security.txt wynikających z TR-03183.

VEX wymaga osobnego omówienia. TR-03183 wymienia VEX jedynie jako profil CSAF oraz jeden z możliwych kanałów wymiany informacji o podatnościach; nigdy nie jest wymagany. 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, i nie twierdzi, że ma zastosowanie poza granicami Niemiec.

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 żadna inna specyfikacja powiązana z CRA nie zbliża się do tego poziomu szczegółowości, dlatego producenci sięgają po TR-03183 jako praktyczne odniesienie.

Po trzecie, TR-03183 jest zbudowana wokół tych samych załączników CRA, które i tak trzeba spełnić: Załącznik I, Załącznik II i Załącznik VII. Dokumentacja przygotowana zgodnie z TR-03183 generuje techniczne dowody, których organ nadzoru rynku UE oczekuje w pliku Annex VII, wraz z SBOM. Nasz przewodnik o dokumentacji technicznej wymienia wszystko, co musi zawierać Annex 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