# SBOM a Cyber Resilience Act

Wykaz komponentów oprogramowania (Software Bill of Materials, SBOM) to lista składników oprogramowania Twojego produktu. Zgodnie z CRA jest obowiązkowy - i jest jedynym praktycznym sposobem, by odpowiedzieć na pytanie "czy nas to dotyczy?", gdy zostanie opublikowana kolejna podatność.

Source: https://kernwatch.com/pl/sbom · Ostatnia aktualizacja: 2026-10-17

## Najważniejsze fakty

- Załącznik I do CRA wymaga SBOM w powszechnie stosowanym formacie nadającym się do odczytu maszynowego, obejmującego co najmniej zależności najwyższego poziomu.
- CycloneDX (OWASP) i SPDX (ISO/IEC 5962) to dwa najpopularniejsze formaty SBOM.
- SBOM jest częścią dokumentacji technicznej: nie trzeba go publikować, ale organy nadzoru rynku mogą go zażądać.
- Dobra praktyka: jeden SBOM dla każdego wspieranego wydania, generowany w pipeline'ie i codziennie sprawdzany w danych o podatnościach.

## Czym jest SBOM

SBOM wymienia każdy komponent oprogramowania w produkcie: biblioteki open source, system operacyjny, moduły zewnętrznych dostawców i Twoje własne pakiety. Dla każdego komponentu zapisuje:

- nazwę i wersję, na przykład `openssl 3.0.13`

- dostawcę

- unikalny identyfikator - adres pakietu (purl) lub CPE

- licencję

- od jakich innych komponentów zależy

## Czego wymaga CRA

Załącznik I aktu o cyberodporności zobowiązuje producentów do identyfikowania i dokumentowania podatności i komponentów zawartych w produktach, **w tym przez sporządzenie wykazu komponentów oprogramowania w powszechnie stosowanym formacie nadającym się do odczytu maszynowego, obejmującego co najmniej zależności najwyższego poziomu**. SBOM jest częścią dokumentacji technicznej; nie musisz go publikować, ale organy nadzoru rynku mogą go zażądać.

## CycloneDX i SPDX

Powszechnie stosowane są dwa formaty, oba nadają się do odczytu maszynowego:

- **CycloneDX** (OWASP) - zaprojektowany z myślą o bezpieczeństwie, z wbudowaną obsługą oceny wykorzystywalności (VEX).

- **SPDX** (Linux Foundation, ISO/IEC 5962) - pierwotnie do zgodności licencyjnej, obsługiwany przez wiele narzędzi buildowych.

Większość ekosystemów potrafi je generować: na przykład Syft lub cdxgen dla kontenerów i systemów plików, wtyczki CycloneDX dla Maven, Gradle i npm oraz wyjście SPDX projektu Yocto dla wbudowanego Linuksa.

## SBOM jest użyteczny tylko wtedy, gdy jest aktualny

SBOM przygotowany raz do deklaracji zgodności traci aktualność przy następnym wydaniu. W praktyce pomaga:

- jeden SBOM dla każdej dostarczonej wersji, generowany w pipeline'ie;

- codzienne sprawdzanie każdego komponentu w nowych danych o podatnościach;

- udokumentowana decyzja dla każdego wyniku - dotyczy, nie dotyczy lub naprawione;

- różnice między wydaniami widoczne od razu.

## Jak Kernwatch wykorzystuje Twoje SBOM-y

- Import CycloneDX lub SPDX przez przesłanie pliku lub z CI z kluczem API.

- Porównywanie wydań i sprawdzanie, które komponenty dodano, usunięto lub zmieniono.

- Dopasowanie komponentów z identyfikatorem pakietu (purl) do OSV, listy CISA znanych wykorzystywanych podatności i unijnej bazy podatności: codziennie w planach płatnych, co tydzień w planie Free.

- Eksport ocen jako VEX razem z SBOM, gdy pyta klient lub organ.

## Oficjalne źródła

- [Rozporządzenie (UE) 2024/2847, załącznik I, EUR-Lex](https://eur-lex.europa.eu/eli/reg/2024/2847/oj)
- [Specyfikacja CycloneDX](https://cyclonedx.org/)
- [Specyfikacja SPDX](https://spdx.dev/)
- [Baza podatności OSV](https://osv.dev/)
- [Katalog CISA znanych wykorzystywanych podatności](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)