CRA to nie skaner podatności

Producent, który traktuje Cyber Resilience Act jako „zeskanuj firmware i spisz CVE”, nie złoży pliku, nawet jeśli skaner jest dobry. Rozporządzenie (UE) 2024/2847 to reguła bezpieczeństwa wyrobu dla produktów z elementami cyfrowymi. Pyta, co wprowadzacie na rynek Unii, jakie ryzyko przyjęliście, z czego wyrób się składa i jak utrzyacie go przez okres wsparcia.

Obsługa podatności zostaje. Jest jednym obowiązkiem wewnątrz Annex I część II i zegara art. 14. Nie jest całym produktem.

Dlaczego historia ze skanerem wraca w każdej rozmowie

Skaner ma demo. Katalog PDE nie. Wiersz ryzyka przypięty do Annex I nie zapala dashboardu w pięć minut. Dlatego pierwszym narzędziem w rozmowie o CRA bywa to, za które dział bezpieczeństwa już płaci.

To narzędzie odpowiada na wąskie pytanie: jakie znane słabości są w tym buildzie. CRA pyta szerzej: czy wolno wam wprowadzić ten produkt na rynek i czy utrzyacie go, gdy zadzwoni organ albo CSIRT. To są inne pliki.

Jeśli jedynym artefaktem CRA, który umiecie wyeksportować, jest raport z podatności, nie macie systemu CRA. Macie skaner z nową okładką na slajdzie.

Najpierw mapa produktów

Główny adresat to producent: osoba, która wprowadza produkt z elementami cyfrowymi na rynek Unii pod własną nazwą lub znakiem. Tym produktem może być urządzenie, samodzielne oprogramowanie albo komponent sprzedawany osobno. Importerzy i dystrybutorzy ciągną własne obowiązki. Tego skan nie widzi.

Zanim mówicie o kolejce CVE, potrzebujecie katalogu. Nazwa, wersja, typ, rynki, data udostępnienia, koniec wsparcia z miesiącem i rokiem. CRA dotyczy produktu, nie raz całej firmy. Istotna zmiana to nowe wprowadzenie na rynek.

Bez tej mapy nie wiecie, który SBOM należy do którego SKU, które luki Annex I są otwarte i do którego CSIRT zgłaszacie, gdy 11 września 2026 ruszy art. 14. Skaner, który nie zna tożsamości wyrobu, skanuje blob.

Ryzyko jest przypięte do Annex I, nie do koloru CVSS

Art. 13 chce oceny ryzyka cyberbezpieczeństwa przez cały cykl życia, nie slajdu przed premierą. Annex I dzieli się na dwie części.

Część I to właściwości produktu: odpowiedni poziom cyberbezpieczeństwa względem ryzyka, brak znanych podatności do wykorzystania przy wprowadzeniu, bezpieczna konfiguracja domyślna, aktualizacje (w tym automatyczne z jasnym opt-out), kontrola dostępu, integralność, poufność, mniejsza powierzchnia ataku, minimalizacja danych.

Część II to obsługa podatności: identyfikacja i dokumentowanie, w tym SBOM; łatanie w okresie wsparcia; testy; publiczna polityka ujawniania; koordynowane ujawnianie; poprawki bez zbędnej zwłoki.

Skaner może zasilać część II. Nie rozstrzygnie, czy hasło domyślne nadal brzmi admin, czy aktualizację da się odrzucić i czy powierzchnia ataku urosła po dodaniu zdalnej diagnostyki. Luka w osobnym Excelu to nie ocena. Wiersz ryzyka musi wskazywać wymaganie, którego nie spełnia.

„Brak znanych podatności do wykorzystania przy wprowadzeniu” to też nie „ostatni skan w piątek był czysty”. To oświadczenie o produkcie, który zaraz wyjdzie z magazynu, z SBOM tej wersji i właścicielem, który to obroni.

SBOM to dowód, nie PDF w szufladzie

Należyta staranność wobec komponentów osób trzecich zostaje przy komponencie. SBOM musi zgadzać się z wersją, którą faktycznie wysyłacie. Wersja w sklepie i wersja w SBOM, które rozjeżdżają się po dwóch sprintach, to typowa porażka.

SBOM zasila kolejkę podatności. Ta kolejka jest realną pracą: 11 września 2026 zaczyna obowiązywać art. 14 dla aktywnie wykorzystywanych podatności i poważnych incydentów. Wczesne ostrzeżenie w 24h, pełne zgłoszenie w 72h, potem raport końcowy, przez jednolity punkt do CSIRT siedziby i do ENISA.

Skaner, który wsypuje 400 CVE do arkusza, nie daje wam właściciela na 24h. Daje szum. Cięcie operacyjne: które z tego jest w wysłanym SBOM, które jest aktywnie wykorzystywane, którego produktu dotyczy, kto składa wczesne ostrzeżenie.

Plik techniczny to to, czego może zażądać organ

Od 11 grudnia 2027 produkt wprowadzany na rynek musi spełniać Annex I, przejść ocenę zgodności, mieć deklarację UE i znak CE. Nadzór rynku może zażądać pliku po latach.

Ten plik to nie raport z podatności. To tożsamość wyrobu, ocena ryzyka, dowody Annex I, SBOM, okres wsparcia, instrukcje, deklaracja i znak. Jeśli któregoś brakuje, ścieżka CE nie jest zamknięta.

Większość wyrobów klasy domyślnej zostaje przy module A. Moduł A i tak potrzebuje tego pliku. Lepszy skaner w 2027 nie napisze deklaracji.

Do czego skaner w CRA się nadaje

Zostawcie skaner. Celujcie nim w build zgodny z SBOM. Otwierajcie nim pozycje części II i odświeżajcie kolejkę. Nie używajcie go jako:

• katalogu produktów,
• oceny z art. 13,
• checklisty Annex I,
• rejestru okresu wsparcia,
• deklaracji UE,
• playbooka art. 14.

Te obiekty mają właścicieli, daty i klucze produktu. Finding ich nie ma.

Co trzyma system

Crado AI jest zbudowany wokół tej pętli, wyłącznie on-premise:

1. Katalog PDE - co wprowadzacie na rynek.
2. Ryzyko i Annex I - które wymagania są spełnione, które nie.
3. SBOM - składniki własne i obce, powiązane z CVE.
4. Art. 14 - zegar 24h / 72h.
5. Plik techniczny i CE - to, co pokażecie, zanim wyrób wyjdzie z magazynu.

Obsługa podatności zostaje. Nie jest całym produktem. Jeśli obecny plan CRA to odnowienie skanera i warsztat CE w 2027, plan jest slajdem, nie plikiem.