Cyber Resilience Act (CRA) — Bezpieczeństwo produktu już w fazie projektowania
Cyber Resilience Act czyni bezpieczeństwo produktu prawnym wymogiem dla wszystkiego z elementem cyfrowym sprzedawanego na rynku UE. CYBORA przekształca istotne wymagania załącznika I w dowody podatności zebrane przed wydaniem, ciągły proces obsługi w całym okresie wsparcia oraz monitoring dostosowany do zegara zgłoszeń CRA — tak by dokumentacja odzwierciedlała to, co Twój produkt faktycznie robi.
Standard w prostych słowach
Rozporządzenie (UE) 2024/2847 ustanawia ogólnounijne wymagania cyberbezpieczeństwa dla produktów z elementami cyfrowymi — zarówno sprzętu, jak i oprogramowania. Zobowiązuje producentów do wyeliminowania znanych możliwych do wykorzystania podatności przed wydaniem, prowadzenia skutecznej obsługi podatności przez cały okres wsparcia produktu (co najmniej pięć lat dla większości produktów) oraz zgłaszania ENISA aktywnie wykorzystywanych podatności według ścisłego harmonogramu. Pełne stosowanie rozpoczyna się 11 grudnia 2027 r.; obowiązek zgłaszania z art. 14 zaczyna obowiązywać wcześniej, 11 września 2026 r.
Przeczytaj tekst regulacji, artykuł po artykule, prostym językiem →Czy to dotyczy Ciebie?
Każdy producent, importer lub dystrybutor wprowadzający na rynek UE sprzęt lub oprogramowanie z elementem cyfrowym — od wbudowanych urządzeń IoT po komponenty SaaS — przy czym największy ciężar dowodowy spoczywa na tym, kto podpisuje deklarację zgodności.
Wymagania w skrócie
Brak znanych możliwych do wykorzystania podatności w chwili wydania
Załącznik I, część I, pkt 2 wymaga, aby produkty były wprowadzane do obrotu bez znanych możliwych do wykorzystania podatności — oznacza to udokumentowaną ocenę podatności przed wydaniem, a nie deklarację polityki.
Regularne testy bezpieczeństwa
Załącznik I, część II, pkt 7 wymaga skutecznych, regularnych testów i przeglądów przez cały cykl życia produktu — audytorzy chcą widzieć rytm testów i rzeczywiste wyniki, a nie tylko spisaną politykę.
Obsługa podatności przez cały okres wsparcia
Artykuł 13(8) czyni obsługę podatności ciągłym obowiązkiem przez cały okres wsparcia — dla większości produktów co najmniej pięć lat — a nie jednorazowym punktem kontrolnym przy wydaniu.
Ścisły zegar zgłaszania
Artykuł 14 wymaga zgłaszania aktywnie wykorzystywanych podatności za pośrednictwem Jednolitej Platformy Zgłoszeń ENISA: wczesne ostrzeżenie w ciągu 24 godzin, pełne powiadomienie w ciągu 72 godzin i raport końcowy w ciągu 14 dni od wydania poprawki.
From gap to Cyber Resilience Act (CRA), on one platform
Każda kontrola mapowana jest raz, dowody zbierane są w sposób ciągły, a jeden zespół odpowiada za wszystko od analizy luk po audyt.
Dowody podatności przed wydaniem
Zaangażowania Offensive Security i zaplanowane skanowania generują udokumentowane, opatrzone datą dowody, że wydanie zostało wypuszczone bez znanych możliwych do wykorzystania podatności — to nie odhaczenie checkboxa, lecz ślad audytowy.
Potwierdzone ustalenia, nie szum skanera
Ustalenia są ręcznie walidowane dowodem koncepcji, zanim trafią do kolejki naprawczej, i ponownie testowane po naprawie — to warstwowa głębia, jakiej wymaga wymóg testowania z załącznika I, wykraczająca poza samo automatyczne skanowanie.
Ciągła obsługa przez cały okres wsparcia
HybridSOC nadal obserwuje produkt po wydaniu, a Agentic GRC utrzymuje zapisy obsługi podatności aktualne przez cały okres wsparcia, a nie tylko w dniu wydania.
Zaprojektowane pod zegar zgłaszania
Alerty HybridSOC dotyczące aktywnie wykorzystywanych CVE oraz eksportowalne pakiety dowodów Agentic GRC są zaprojektowane tak, by działać wystarczająco szybko na potrzeby 24-godzinnego wczesnego ostrzeżenia — zgłoszenie do ENISA nadal składasz Ty, my dbamy o to, byś miał co zgłosić.
Najczęściej zadawane pytania
Czy CYBORA generuje SBOM wymagany przez CRA (załącznik I, część II, pkt 1)?
Nie — CYBORA jest warstwą oceny podatności i dowodów, a nie generatorem SBOM. Połącz swoje istniejące narzędzia SBOM z testowaniem i monitoringiem CYBORA, aby pokryć oba obowiązki.
Czy CYBORA prowadzi skoordynowany proces ujawniania podatności (CVD) wymagany przez CRA?
CYBORA przygotowuje politykę CVD i security.txt w ramach naszych szablonów polityk, ale infrastrukturę przyjmowania i triażu prowadzisz Ty sam — przekazujemy Ci zwalidowane ustalenia, a nie publiczną skrzynkę zgłoszeń.
Czy testy z CYBORA sprawiają, że nasz produkt jest zgodny z CRA?
Nie. Pełna zgodność nadal wymaga oceny zgodności, deklaracji zgodności i oznakowania CE, dokonanych przez producenta (z jednostką notyfikowaną tam, gdzie wymaga tego CRA). CYBORA dostarcza techniczne dowody podatności, od których ta ocena zależy — nie zastępuje jej.
Jak CYBORA pomaga w dotrzymaniu terminu zgłoszenia z art. 14?
Na dwa sposoby: HybridSOC ostrzega w chwili, gdy monitorowany zasób odpowiada aktywnie wykorzystywanemu CVE, a Agentic GRC eksportuje ślad dowodowy jako PDF, DOCX lub JSON, byś zdążył w 24-godzinnym terminie wczesnego ostrzeżenia. Samo zgłoszenie do Jednolitej Platformy Zgłoszeń ENISA nadal pozostaje obowiązkiem producenta.
Czy CYBORA może testować wbudowane, lokalne lub odizolowane środowiska produktu?
Tak — zaangażowania są dopasowane do Twojego rzeczywistego środowiska, w tym sieci wewnętrznych i wdrożeń lokalnych, a nie tylko tego, co jest dostępne z internetu.
Czy samo automatyczne skanowanie spełnia wymóg "regularnego testowania"?
Nie. Załącznik I, część II, pkt 7 wymaga testowania warstwowego — ciągłego automatycznego skanowania, okresowych ręcznych testów penetracyjnych i modelowania zagrożeń na etapie projektowania. CYBORA prowadzi warstwę automatyczną i ręczną razem; modelowanie zagrożeń jest ujęte jako część zaangażowania.
Zobacz to na własnym perymetrze
Tell us where you are today. A CYBORA engineer — not a salesperson — will come back with what actually applies to your situation.
- Reply within one business day
- Scoped to your regulatory frameworks
- No obligation, no sales pitch
Take control of your perimeter
Register for a pilot demonstration of the CYBORA GRC and HybridSOC platform. One team, accountable for your full cyber security lifecycle.