Czego wymaga rozporządzenie
Załącznik I część II pkt 1 rozporządzenia (UE) 2024/2847: producenci są zobowiązani do „identyfikowania i dokumentowania podatności i komponentów zawartych w produkcie z elementami cyfrowymi, w tym przez sporządzenie zestawienia podstawowych materiałów do produkcji oprogramowania w powszechnie używanym formacie nadającym się do odczytu maszynowego, obejmującego co najmniej zależności najwyższego poziomu produktów”. Obowiązuje to od 11 grudnia 2027 r. (art. 71).
- Zestawienie jest częścią dokumentacji technicznej, razem z procesami postępowania w przypadku podatności (załącznik VII pkt 2 lit. b)).
- Przekazuje się je organowi nadzoru rynku na jego uzasadniony wniosek (załącznik VII pkt 8). Nie trzeba go publikować (motyw 77).
- Jeśli zdecydują się Państwo udostępnić je użytkownikom, informacje dla użytkownika wskazują, gdzie (załącznik II pkt 9).
- Komisja może określić jego format i elementy w akcie wykonawczym (art. 13 ust. 24). Powszechnie używane formaty to m.in. CycloneDX i SPDX.
Co tworzy ta strona
Plik JSON CycloneDX 1.6 z produktem jako głównym komponentem, każdym pakietem z dokładną wersją i adresem URL pakietu (purl) oraz zależnościami najwyższego poziomu produktu, jeśli plik blokady je wskazuje. Odczytuje:
- npm package-lock.json (lockfileVersion 2 lub 3), Yarn yarn.lock (Yarn 1, 2 i nowsze) oraz pnpm-lock.yaml (lockfileVersion 9.0); pakiety używane tylko przy tworzeniu oprogramowania są pomijane, gdy plik je wskazuje;
- Python requirements.txt z przypiętą wersją każdego pakietu (name==version), tak jak zapisują to pip freeze lub pip-compile;
- Rust Cargo.lock w wersji 3 lub 4 oraz Go go.mod, z modułami pośrednimi;
- drzewo zależności Maven zapisane przez mvn dependency:tree -DoutputFile oraz Gradle gradle.lockfile; pakiety o zakresie test są pomijane;
- PHP Composer composer.lock, bez packages-dev, oraz NuGet packages.lock.json.
Plik niezgodny ze swoim formatem nie jest odczytywany: strona podaje wiersz i powód zamiast zgadywać. Pakiet z innego źródła niż publiczny rejestr jest wymieniany bez adresu URL pakietu, aby plik nigdy nie wskazywał pakietu, którego Państwo nie użyli.
Mają Państwo już SBOM z innego narzędzia? Proszę otworzyć go jako plik JSON CycloneDX albo jako plik JSON SPDX, taki jak eksportowany przez graf zależności GitHuba (Export SBOM), aby sprawdzić jego komponenty w OSV.dev i w katalogu KEV. Jest czytany tylko do sprawdzenia: aby utworzyć nowy SBOM, proszę otworzyć pliki blokady. Tam, gdzie żaden plik blokady nie ustala wersji, plik GitHuba podaje zakres, na przykład ^4.17.0: takie komponenty są wymienione jako niesprawdzone; aby je sprawdzić, proszę otworzyć plik blokady.
Znane wykorzystywane podatności
Sprawdzenie oznacza każdą podatność znalezioną w OSV.dev, której numer CVE figuruje w katalogu znanych wykorzystywanych podatności (KEV) amerykańskiej Agencji ds. Cyberbezpieczeństwa i Bezpieczeństwa Infrastruktury (CISA), wraz z datą wpisu. CISA wpisuje podatność, gdy są wiarygodne dowody, że ją wykorzystano. Od 11 września 2026 r. art. 14 aktu o cyberodporności wymaga zgłoszenia aktywnie wykorzystywanej podatności zawartej w produkcie (art. 3 pkt 42) w ciągu 24 godzin od powzięcia o niej wiadomości. Wpis w KEV nie przesądza tego dla Państwa produktu, ale wskazuje, gdzie spojrzeć najpierw; strona terminów zgłoszeń liczy godziny.
Czego nie obejmuje
Zestawienie wymienia to, co wymieniają pliki blokad. Kodu skopiowanego do produktu, pakietów systemu operacyjnego, oprogramowania układowego i bibliotek w innych językach w nich nie ma: proszę dodać je samodzielnie. Sprawdzenie podatności korzysta z OSV.dev, które wymienia tylko opublikowane podatności; nie zastępuje oceny podatności wymaganej w załączniku I część II.
Pozostałe dokumenty CRA, dokumentację techniczną i deklarację zgodności UE, sporządza pakiet dokumentów CRA. Strona o akcie o cyberodporności wskazuje klasę produktu.