Porównanie narzędzi do zgodności z CRA

Dla kogo jest ta strona

Wytwarzają Państwo produkt z elementami cyfrowymi i wprowadzają go na rynek UE. Cyber Resilience Act, rozporządzenie (UE) 2024/2847, obowiązuje Państwa etapami: obowiązki raportowania od 11 września 2026, a główne przepisy od 11 grudnia 2027. Wybierają Państwo narzędzia do technicznych części tej pracy. Tworzymy CRACI, proszę wziąć to pod uwagę. Każde narzędzie opisujemy na podstawie jego własnej dokumentacji i wskazujemy, gdzie inne narzędzie sprawdza się lepiej.

Przez całą tę stronę przechodzi jedna zasada. Zgodność to proces prowadzony przez producenta, obejmujący ocenę ryzyka, dokumentację i ocenę zgodności. Narzędzia wytwarzają dowody i automatyzują części pracy. Żadne z poniższych narzędzi samo w sobie nie zapewnia zgodności produktu.

Czego wymaga CRA

W przypadku łańcucha dostaw oprogramowania najwięcej zależy od pięciu wymagań.

1. SBOM. Producenci identyfikują i dokumentują komponenty produktu, w tym przez sporządzenie zestawienia komponentów oprogramowania w powszechnie stosowanym formacie czytelnym maszynowo, obejmującego „co najmniej zależności najwyższego poziomu produktów” (załącznik I, część II). Załącznik VII umieszcza je w dokumentacji technicznej, której może zażądać organ nadzoru rynku.
2. Obsługa podatności. Niezwłoczne eliminowanie i usuwanie podatności, w tym przez aktualizacje bezpieczeństwa, regularne testowanie i prowadzenie polityki skoordynowanego ujawniania podatności (załącznik I, część II).
3. Raportowanie. Zgłaszanie aktywnie wykorzystywanych podatności i poważnych incydentów do Państwa CSIRT i ENISA przez CRA Single Reporting Platform: wczesne ostrzeżenie w ciągu 24 godzin, zgłoszenie w ciągu 72 godzin i raport końcowy nie później niż 14 dni po udostępnieniu poprawki lub środka łagodzącego dla podatności albo w ciągu miesiąca dla poważnego incydentu (art. 14).
4. Dowody. Dokumentacja techniczna, ocena zgodności i deklaracja zgodności UE (art. 28, 31 i 32, załącznik VII), dostępne dla organów przez co najmniej 10 lat od wprowadzenia produktu do obrotu lub przez okres wsparcia, w zależności od tego, który z nich jest dłuższy (art. 13).
5. Okres wsparcia. Okres odzwierciedlający, jak długo produkt ma być używany, wynoszący co najmniej pięć lat, chyba że przewidywane użytkowanie jest krótsze, w którym podatności są skutecznie obsługiwane (art. 13).

Jak wybrać

• W której połowie pracy potrzebują Państwo pomocy? Narzędzia techniczne tworzą SBOM, zapisy podatności i dowody z buildu. Platformy zarządzania zgodnością mapują wymagania na środki kontroli, przygotowują projekty polityk i śledzą proces. Większość narzędzi jest silna w jednej połowie, więc należy ustalić, która luka jest większa.
• Budują Państwo oprogramowanie czy je integrują? Jeśli duża część produktu trafia do Państwa od producentów chipów i dostawców w postaci plików binarnych, analiza binarna pozwala zajrzeć do środka. Jeśli budują je Państwo sami, build jest najbardziej bezpośrednim źródłem dowodów.
• Skąd pochodzi Państwa SBOM i skąd wiadomo, że jest kompletny? Skanery, odpytywanie narzędzi buildu i rejestrowanie buildu mogą dać różne odpowiedzi dla tego samego wydania.
• Czy potrafią Państwo znaleźć podatne wydania w ciągu kilku godzin? Wczesne ostrzeżenie w ciągu 24 godzin zależy od wiarygodnego inwentarza dla każdego wydania.
• Czy potrzebują Państwo systemu ewidencji? Przy wielu produktach i dostawcach zarządzanie SBOM z VEX i udostępnianiem staje się osobnym zadaniem.

W skrócie

Dwie tabele: najpierw narzędzia SBOM, SCA i zarządzania SBOM, potem narzędzia stworzone dla firmware'u i urządzeń. Wiersze odpowiadają powyższym wymaganiom. „Nie podano” oznacza, że cytowane przez nas strony dostawców nie rozstrzygają tej kwestii.

SBOM, SCA i zarządzanie SBOM

Firmware i urządzenia

CRACI

CRACI to runner GitHub Actions. W przypadku budowanego przez Państwa oprogramowania rejestruje, co pobrało każde zadanie, łącznie z pakietami przywróconymi z cache CI, i tworzy SBOM CycloneDX lub SPDX ze stanem kompletności dla każdego zadania i każdego cache. Nadal ponownie ocenia SBOM-y tego, co dostarczono, obsługuje VEX i składa zgłoszenia CRA w Państwa imieniu, gdy trzeba zgłosić aktywnie wykorzystywaną podatność. W przypadku Yocto rejestruje to, co pomija własny wynik SPDX Yocto. Pomaga w: generowaniu SBOM, obsłudze podatności, zgłoszeniach CRA, dowodach. Uwaga: nie analizuje plików binarnych, których Państwo nie zbudowali, nie ma mapowania środków kontroli ani zarządzania politykami i obsługuje dziś GitHub Actions (GitLab CI i Jenkins są w planach rozwoju). Zgodność z CRA z CRACI

Zarządzanie SBOM

Cybeats

Cybeats SBOM Studio określa się mianem „systemu ewidencji SBOM”. Przechowuje SBOM-y Państwa produktów i dostawców w SPDX 2.2 do 3.0.1 i CycloneDX 1.2 do 1.7, waliduje je za pomocą Quality Score przed importem, dopasowuje każdy komponent do informacji o podatnościach, wydaje VEX i udostępnia SBOM-y klientom, także przez Transparency Exchange API. Jego przewodnik po regulacjach przedstawia harmonogram CRA: 24 godziny, 72 godziny i 14 dni. Pomaga w: zarządzaniu SBOM, obsłudze podatności, dowodach. Uwaga: w kwestii generowania odsyła do dostawców ze swojego Marketplace, więc sam SBOM pochodzi z innego narzędzia. CRACI vs Cybeats oraz alternatywy dla Cybeats

FOSSA

FOSSA zaczynała od zgodności licencyjnej, a dziś obejmuje cały cykl życia SBOM. Generuje SBOM-y SPDX i CycloneDX, opcjonalnie z oświadczeniami VDR lub VEX, importuje SBOM-y dostawców z politykami dla elementów minimalnych NTIA i FDA, monitoruje je pod kątem podatności i udostępnia przez SBOM Portal w planie Enterprise. Według stanu na wrzesień 2026 ma darmowy plan, a Business kosztuje $20 za projekt miesięcznie przy rozliczeniu rocznym. Pomaga w: SBOM, udostępnianiu organom, licencjach. Uwaga: FOSSA CLI analizuje projekt przez jego narzędzie buildu lub wnioskuje na podstawie kodu źródłowego, zamiast rejestrować build. CRACI vs FOSSA

Anchore

Anchore Enterprise bazuje na Syft i Grype open source. Skanuje obrazy kontenerów, systemy plików i importowane SBOM-y, ponownie skanuje zapisane SBOM-y bez oryginalnego artefaktu, stosuje pakiety polityk, takie jak FedRAMP i NIST, i działa w trybie self-hosted, także w środowiskach air-gapped. Jego materiały o CRA obejmują zarządzanie SBOM, monitorowanie względem źródeł takich jak CISA KEV, wsparcie okien 24- i 72-godzinnych, adnotacje VEX i ścieżki audytu. Pomaga w: SBOM, obsłudze podatności, dowodach. Uwaga: jego SBOM-y opisują to, co skaner znajduje w obrazie lub katalogu, a nie to, co build pobrał i po sobie pozostawił. CRACI vs Anchore

Pakiety SCA

Black Duck

Black Duck SCA łączy skanowanie menedżerów pakietów, sygnatur, fragmentów kodu i plików binarnych, dzięki czemu znajduje open source, którego nikt nie zadeklarował, a jego KnowledgeBase śledzi ponad 2750 licencji. Binary Analysis bada firmware bez kodu źródłowego, Coverity zapewnia SAST z opcją reguł zgodnych z CRA, ogłoszoną w lipcu 2026, a Defensics wykonuje fuzzing. Black Duck dowodzi, że CRA wymaga warstw testowania, a nie samego SCA. Pomaga w: SBOM, obsłudze podatności w komponentach i własnym kodzie, testowaniu. Uwaga: ceny ustalane są indywidualnie, a każda technika bada kod lub wynik, a nie build. CRACI vs Black Duck

Sonatype

Sonatype Lifecycle stosuje politykę open source z danymi o osiągalności i aktualizacjach oraz otwiera Golden Pull Requests. Repository Firewall poddaje kwarantannie komponenty niezgodne z polityką, zanim trafią do Państwa repozytoriów. SBOM Manager importuje, monitoruje i udostępnia SBOM-y z workflow VEX, a Sonatype pozycjonuje go jako swój produkt dla CRA; jego przewodnik wskazuje też Nexus Repository jako witrynę aktualizacji bezpieczeństwa. Pomaga w: obsłudze podatności, zarządzaniu SBOM, zatrzymywaniu złych komponentów. Uwaga: pakietowanie oferty się zmienia (nowi klienci kupują Sonatype Guide), a Lifecycle analizuje to, co build wytworzył, a nie to, co pobrał. CRACI vs Sonatype

Firmware i urządzenia

ONEKEY

ONEKEY analizuje skompilowany firmware „bez potrzeby kodu źródłowego ani dostępu do sieci”. Generuje SBOM z pliku binarnego, importuje SBOM-y dostawców, szuka prawdopodobnych zero-day, takich jak zakodowane na stałe poświadczenia, i codziennie ponownie analizuje firmware. Jego Compliance Wizard prowadzi zespoły przez CRA, IEC 62443-4-2, ETSI EN 303 645 i Radio Equipment Directive. Pomaga w: SBOM firmware'u, którego Państwo nie zbudowali, obsłudze podatności, prowadzonych kontrolach. Uwaga: pracuje na obrazie po buildzie, więc nie rejestruje tego, co build pobrał. CRACI vs ONEKEY oraz alternatywy dla ONEKEY

Finite State

Finite State analizuje firmware, pliki binarne, kod źródłowy i SBOM-y dostawców, z obsługą ponad 50 architektur zestawów instrukcji, i łączy je w jeden zapis produktu. Szereguje znaleziska według osiągalności i danych o exploitach, zapisuje decyzje VEX, a jego workflow zgodności obejmuje mapowanie środków kontroli CRA i raporty gotowe do audytu z artefaktami SBOM i VEX. Pomaga w: SBOM obejmującym dostawców, triage podatności, dowodach. Uwaga: zaczyna od artefaktów, więc kontrola tego, do czego ma dostęp Państwa własny build, jest poza jego zakresem. CRACI vs Finite State oraz alternatywy dla Finite State

Exein

Exein działa na urządzeniu. Exein Runtime używa eBPF do monitorowania i blokowania złośliwych zachowań w embedded Linux, a warstwa Yocto open source meta-exein umieszcza jego agenta Pulsar w Państwa obrazie. Exein Analyzer skanuje firmware przed wydaniem lub Państwa SBOM, gdy plik binarny nie jest dostępny, priorytetyzuje na podstawie oceny osiągalności i mapuje znaleziska na wymagania CRA. Pomaga w: obsłudze podatności w terenie, SBOM firmware'u, mapowaniu CRA. Uwaga: warstwa Yocto zmienia to, co działa na urządzeniu; nie uruchamia ani nie rejestruje Państwa buildu. CRACI vs Exein

Platformy zarządzania zgodnością

Te narzędzia nie generują SBOM-ów ani nie skanują kodu. Zajmują się połową pracy związaną z nadzorem: mapowaniem wymagań CRA na środki kontroli, przygotowywaniem projektów polityk oraz śledzeniem terminów i zatwierdzeń. Potrzebują dowodów technicznych z innych źródeł.

Venvera

Venvera to platforma zgodności zbudowana w UE, która obejmuje CRA obok NIS2, DORA, ISO 27001 i SOC 2. W przypadku CRA śledzi terminy raportowania 24 i 72 godzin, obsługę podatności, SBOM jako utrzymywane wymaganie, ścieżkę oceny zgodności dla każdej klasy produktu oraz dokumentację techniczną z załącznika VII i deklarację zgodności UE. Pomaga w: mapowaniu środków kontroli, terminach raportowania, śledzeniu procesu oceny zgodności. Uwaga: śledzi, czy SBOM istnieje i jest utrzymywany; sam SBOM pochodzi z innego narzędzia.

ZeroRisk

ZeroRisk to agentowa platforma zgodności obejmująca GDPR, ISO 27001, SOC 2, NIS2, DORA i CRA. W przypadku CRA jej agent mapuje wymagania na Państwa organizację, wstępnie wypełnia ocenę gotowości, przygotowuje projekty brakujących środków kontroli i polityk oraz monitoruje dostawców w Państwa produktach, ze sprawdzaniem co 24 godziny i zatwierdzaniem każdego wniosku przez człowieka. Pomaga w: gotowości, politykach, weryfikacji dostawców. Uwaga: jego strona o CRA nie wspomina o generowaniu SBOM ani monitorowaniu podatności w Państwa własnych buildach.

Raportowanie w terminie

Art. 14 nakłada obowiązek zgłoszenia na producenta i obowiązuje od 11 września 2026, także dla produktów już obecnych na rynku. Narzędzia mogą skrócić czas między „ta podatność jest wykorzystywana” a „wiemy, które produkty i wydania ją zawierają”. Zależy to od wiarygodnych inwentarzy dla każdego wydania, ciągłego monitorowania i powiązania każdego dostarczonego artefaktu z jego komponentami. Anchore i Cybeats opisują okna raportowania w swoich materiałach o CRA, Venvera śledzi terminy, a analiza binarna z ONEKEY, Finite State lub Exein obejmuje kod dostawców, którego nie można przebudować. API CRACI zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu, a CRACI składa wczesne ostrzeżenie, zgłoszenie i raport końcowy w imieniu producenta.

Miejsce CRACI

CRACI to runner GitHub Actions. W przypadku budowanego przez Państwa oprogramowania rejestruje, co pobrało każde zadanie, łącznie z pakietami przywróconymi z cache CI, i tworzy SBOM CycloneDX lub SPDX ze stanem kompletności dla każdego zadania i każdego cache. Egzekwuje politykę ruchu wychodzącego w buildzie, nadal ponownie ocenia SBOM-y tego, co dostarczono, obsługuje VEX i eksportuje SBOM-y w formacie CycloneDX lub SPDX, łącznie z podatnościami, jako Państwa dowody dla CRA. Gdy trzeba zgłosić aktywnie wykorzystywaną podatność, CRACI składa zgłoszenia CRA w Państwa imieniu. W przypadku Yocto uruchamia BitBake na runnerach o rozmiarze do 32 vCPU i 96 GB RAM i rejestruje to, co pomija własny wynik SPDX Yocto, na przykład pakiety hosta i package URL dla crate'ów Rust. Widok inwentarza CRACI pokazuje dokładnie, które wersje oprogramowania są wdrożone w których produktach, na całym świecie. CRACI automatyzuje znaczną część widoczności łańcucha dostaw oprogramowania i dowodów potrzebnych firmom w szerszym procesie zgodności z CRA.

Sam w sobie nie wystarczy, jeśli większość Państwa produktu pochodzi od dostawców w postaci plików binarnych albo jeśli potrzebują Państwo prowadzonych kontroli względem standardów, mapowania środków kontroli i zarządzania politykami, ochrony na urządzeniu lub już dziś systemów CI innych niż GitHub Actions (GitLab CI i Jenkins są w planach rozwoju). W przypadku Państwa własnych buildów CRACI obejmuje SBOM, monitorowanie i zgłoszenia CRA w jednym produkcie; w przypadku firmware'u, którego nie można przebudować, analiza binarna widzi to, czego Państwa build nigdy nie widział. Zob. czym jest CRA, zgodność z CRA oraz przemysłowy IoT.

Narzędzia do zgodności z CRA: najczęściej zadawane pytania

Co robi oprogramowanie do zgodności z CRA, a co pozostaje po stronie producenta

Czym jest oprogramowanie do zgodności z CRA?

To oprogramowanie, które pomaga producentowi spełnić wymagania Cyber Resilience Act. Występuje w dwóch rodzajach: narzędzia techniczne, które tworzą SBOM, zapisy podatności i dowody z buildu, oraz platformy zarządzania zgodnością, które mapują wymagania na środki kontroli i śledzą terminy raportowania, ocenę ryzyka i ocenę zgodności. Żadne z nich samo w sobie nie zapewnia zgodności produktu.

Które obowiązki z CRA może zautomatyzować narzędzie?

Głównie po stronie obsługi podatności: generowanie SBOM, monitorowanie go pod kątem nowych podatności, znajdowanie podatnych wydań, zapisywanie decyzji triage i VEX, przygotowywanie i składanie zgłoszeń z art. 14 oraz eksport dowodów do dokumentacji technicznej. Ocena ryzyka, bezpieczne projektowanie, ocena zgodności i deklaracja zgodności pozostają decyzjami producenta.

Czy potrzebuję jednego narzędzia, czy kilku?

Zwykle więcej niż jednego. Narzędzie techniczne daje Państwu SBOM i dowody dotyczące podatności; platforma zarządzania zgodnością lub konsultant obejmuje środki kontroli, polityki i ścieżkę oceny zgodności. W przypadku firmware'u otrzymywanego od dostawców w postaci plików binarnych analiza binarna dodaje to, czego Państwa własny build nie widzi.

Jaki jest termin raportowania w CRA?

Art. 14 obowiązuje od 11 września 2026: wczesne ostrzeżenie w ciągu 24 godzin od uzyskania wiedzy o aktywnie wykorzystywanej podatności, zgłoszenie w ciągu 72 godzin i raport końcowy nie później niż 14 dni po udostępnieniu poprawki lub środka łagodzącego. Dotyczy to także produktów już obecnych na rynku. Pozostałą część CRA stosuje się od 11 grudnia 2027.

Czy CRACI składa zgłoszenia CRA?

Tak. CRACI składa wczesne ostrzeżenie, zgłoszenie i raport końcowy w imieniu producenta. Obowiązek zgłoszenia pozostaje po stronie producenta.

Czy jakieś narzędzie przeprowadza ocenę zgodności z CRA?

Żadne narzędzie programowe jej nie zastępuje. Ocenę przeprowadza producent, w drodze kontroli wewnętrznej lub, w przypadku produktów ważnych i krytycznych, z udziałem jednostki notyfikowanej albo w ramach programu certyfikacji, jeśli CRA tego wymaga. Narzędzia dostarczają dowody, z których korzysta ocena.