Tak, CRA wymaga SBOM. Producent ma identyfikować i dokumentować komponenty oraz podatności produktu, w tym sporządzić SBOM (wykaz komponentów oprogramowania) w powszechnie używanym formacie nadającym się do odczytu maszynowego, obejmujący co najmniej zależności najwyższego poziomu. SBOM jest częścią dokumentacji technicznej. Nie trzeba go publikować, ale organ nadzoru rynku może go zażądać.
- Podstawa: załącznik I część II pkt 1. SBOM to w polskim tekście „zestawienie podstawowych materiałów do produkcji oprogramowania”.
- Minimum: powszechnie używany format do odczytu maszynowego i zależności najwyższego poziomu.
- CRA nie wskazuje konkretnego formatu. Format i elementy może określić Komisja w akcie wykonawczym.
- SBOM należy do dokumentacji technicznej. Producent nie musi go upubliczniać.
- SBOM ma sens tylko wtedy, gdy jest aktualny dla każdej wydanej wersji i ktoś na jego podstawie śledzi podatności.
Czym jest SBOM?
SBOM (Software Bill of Materials) to formalny zapis składników, z których zbudowane jest oprogramowanie produktu, razem z relacjami między nimi w łańcuchu dostaw. Polski tekst CRA nazywa go „zestawieniem podstawowych materiałów do produkcji oprogramowania” (art. 3 pkt 39). W praktyce to plik z listą bibliotek, modułów i ich wersji.
Celem jest analiza podatności. Motyw 77 wyjaśnia, że SBOM pomaga producentom i użytkownikom śledzić znane i nowo pojawiające się podatności oraz lepiej rozumieć łańcuch dostaw.
Czego dokładnie wymaga CRA?
Załącznik I część II pkt 1 wymaga, żeby producent identyfikował i dokumentował podatności oraz komponenty zawarte w produkcie, w tym sporządził SBOM w powszechnie używanym formacie nadającym się do odczytu maszynowego, obejmujący co najmniej zależności najwyższego poziomu. Obowiązek dotyczy każdego produktu z elementami cyfrowymi, niezależnie od kategorii.
| Przepis | Co mówi o SBOM |
|---|---|
| Załącznik I część II pkt 1 | Obowiązek sporządzenia SBOM: format do odczytu maszynowego, co najmniej zależności najwyższego poziomu |
| Załącznik VII pkt 2 lit. b | SBOM jest częścią dokumentacji technicznej, wśród informacji o obsłudze podatności |
| Załącznik VII pkt 8 | Organ nadzoru rynku może zażądać SBOM na uzasadniony wniosek, jeśli jest to niezbędne do sprawdzenia zgodności |
| Załącznik II pkt 9 | Jeśli producent udostępnia SBOM użytkownikom, podaje, gdzie można go uzyskać |
| Art. 13 ust. 24 | Komisja może w akcie wykonawczym określić format i elementy SBOM |
| Art. 13 ust. 25 | Organy nadzoru rynku mogą poprosić producentów określonych kategorii produktów o SBOM na potrzeby ogólnounijnej oceny zależności |
W tym artykule nie przesądzamy, czy Komisja przyjęła już akt wykonawczy o formacie SBOM. Przed wyborem formatu sprawdź aktualny stan na stronie Komisji.
Co powinien zawierać SBOM?
Rozporządzenie określa tylko minimum: format do odczytu maszynowego i zależności najwyższego poziomu. Żeby SBOM nadawał się do śledzenia podatności, w praktyce zawiera dla każdego komponentu nazwę, wersję, dostawcę, jednoznaczny identyfikator oraz powiązanie z wersją produktu, której dotyczy. Poniższa lista to dobra praktyka, a nie wymóg przepisu.
- nazwa i wersja produktu oraz data wygenerowania SBOM,
- nazwa, wersja i dostawca każdego komponentu,
- jednoznaczny identyfikator komponentu, np. PURL lub CPE, który pozwala dopasować go do baz podatności,
- relacje między komponentami: co od czego zależy,
- licencja komponentu, jeśli jest znana,
- suma kontrolna lub inny sposób potwierdzenia, że chodzi o ten sam plik.
Czy SBOM trzeba komuś pokazywać?
SBOM nie jest dokumentem publicznym. Producent przechowuje go w dokumentacji technicznej i przekazuje organowi nadzoru rynku na uzasadniony wniosek. Może, ale nie musi, udostępnić go użytkownikom. Osobną sprawą są umowy: odbiorca biznesowy może zażądać SBOM w kontrakcie, niezależnie od CRA.
Jak przygotować SBOM dla urządzenia z firmware?
SBOM powinien powstawać automatycznie w procesie budowania firmware, dla każdej wydanej wersji. Ręcznie prowadzona lista szybko przestaje odpowiadać temu, co faktycznie trafia do urządzeń. W urządzeniu wbudowanym trzeba objąć nie tylko własny kod, ale też system operacyjny, SDK producenta układu, stosy komunikacyjne i biblioteki dołączone statycznie.
Firmware bramki IoT składa się z systemu czasu rzeczywistego, SDK układu radiowego, stosu TLS, biblioteki MQTT i kodu aplikacji. Proces budowania generuje plik SBOM dla każdej wersji i zapisuje go obok pliku firmware. Gdy w bibliotece TLS zostaje opublikowana podatność, zespół w kilka minut sprawdza, które wersje firmware ją zawierają i w których modelach są zainstalowane.
Bez SBOM ta sama odpowiedź wymagałaby przeglądania repozytoriów, a przy aktywnie wykorzystywanej podatności producent ma 72 godziny na zgłoszenie obejmujące informacje o produkcie.
Typowe trudności w systemach wbudowanych:
- Kod skopiowany do repozytorium. Biblioteka wklejona do drzewa źródeł nie pojawi się w SBOM, jeśli narzędzie czyta tylko menedżer pakietów.
- Binarne komponenty dostawców. Trzeba uzyskać od dostawcy listę ich składników albo jego własny SBOM.
- Wiele wariantów sprzętowych. Każdy wariant z inną konfiguracją budowania ma własny SBOM.
- Zmodyfikowane biblioteki. Wersja z własnymi poprawkami powinna być oznaczona tak, żeby nie mylić jej z oryginałem.
Co robić z SBOM po jego przygotowaniu?
Sam plik nie spełnia celu przepisu. SBOM trzeba regularnie porównywać z bazami znanych podatności, oceniać, czy podatność komponentu faktycznie dotyczy produktu, i na tej podstawie decydować o aktualizacji. CRA wymaga należytej staranności wobec komponentów stron trzecich oraz zgłaszania wykrytych w nich podatności podmiotowi, który je utrzymuje.
Cały proces opisuje artykuł Zarządzanie podatnościami w CRA: proces krok po kroku.
Co powinien zrobić producent?
Producent powinien wybrać format, włączyć generowanie SBOM do procesu budowania, uzupełnić dane o komponentach dostawców i wyznaczyć osobę, która na podstawie SBOM śledzi podatności. SBOM jest częścią dokumentacji technicznej i jest przechowywany razem z nią. W praktyce warto zachować SBOM każdej wydanej wersji.
- Wybierz format do odczytu maszynowego obsługiwany przez Twoje narzędzia i sprawdź, czy Komisja określiła wymagania w akcie wykonawczym.
- Generuj SBOM przy każdym wydaniu, automatycznie, z tego samego procesu, który buduje firmware.
- Uzupełnij to, czego narzędzie nie widzi: kod skopiowany, biblioteki statyczne, komponenty binarne.
- Zażądaj danych od dostawców. SBOM lub lista składników SDK i modułów powinna być zapisem w umowie.
- Połącz SBOM ze śledzeniem podatności i ustal, kto ocenia wyniki.
- Przechowuj SBOM z dokumentacją techniczną co najmniej 10 lat albo przez okres wsparcia, jeśli jest dłuższy.
Miejsce SBOM w dokumentacji opisuje artykuł Dokumentacja techniczna CRA, a pozostałe wymagania wobec urządzenia artykuł CRA dla producentów IoT i elektroniki.