Regulácia Cyber Resilience Act (CRA) posúva bezpečnosť digitálnych produktov z kategórie „nice to have“ medzi podmienky ich predaja v Európskej únii. Výrobca musí vedieť ukázať, ako vyhodnotil riziká, nastavil bezpečnú predvolenú konfiguráciu, preveril zdrojový kód, aby neobsahoval známe zraniteľnosti, a podporuje produkt počas jeho životného cyklu. V praxi preto CRA smeruje firmy k bezpečnému vývojovému cyklu.
Bezpečnosť je pre výrobcov otrava navyše
Z našich skúseností vyplýva, že pri vývoji softvéru veľakrát vyhrávajú skôr rýchly termín dodania, pekný dizajn a nové, atraktívne funkcie. Samotné zamyslenie sa nad tým, či je výrobok bezpečný, má nízku prioritu. Bezpečnosť výrobku z pohľadu kybernetických hrozieb sa väčšinou nerieši už vo fáze dizajnu produktu, ale až neskôr… a ak na ňu zostal čas a rozpočet.
CRA teraz firmám, ktoré uvádzajú na trh výrobky s digitálnymi prvkami, explicitne hovorí, že nestačí, aby funkcia v nejakom zariadení iba fungovala. Musí byť navrhnutá tak, aby bola bezpečná.
CRA prikazuje to, čo už dávno vnímame ako dobrú prax
Väčšina technických princípov CRA dávno patrí medzi odporúčané postupy bezpečného vývoja. Analýza rizík, bezpečné predvolené nastavenia, kontrola knižníc tretích strán, testovanie kódu z pohľadu bezpečnosti (nielen z pohľadu kvality kódu, ako tomu často býva) či vydávanie bezpečnostných opráv alebo minimalizácia útočnej plochy pritom nie sú nové disciplíny. Novinkou je ale právna zodpovednosť výrobcu za to, že ich skutočne uplatňuje.
Firma, ktorá má dobre zavedený DevSecOps a Secure Software Development Lifecycle (SSDLC), teraz určite nemusí začínať budovať bezpečnostné postupy od nuly. CRA nie je revolúcia v bezpečnosti, ale z veľkej časti len premieňa už existujúcu dobrú prax na povinnosť a mnoho firiem sa ľahko adaptuje. Mnohé ale budú musieť výrazne zabrať. Podobne ako GDPR pri osobných údajoch, CRA mení pri výrobkoch s digitálnymi prvkami dobrovoľný prísľubu výrobcu na povinnosť.
Koho sa Cyber Resilience Act týka
CRA sa vzťahuje na produkty s digitálnymi prvkami uvádzané na trh Európskej únie. Patria sem inštalovateľné desktopové a mobilné aplikácie, operačné systémy, firmvér, pripojený hardvér aj samostatne predávané softvérové komponenty. Do rozsahu môže patriť tiež cloudový backend, ak je nevyhnutný pre fungovanie samotného produktu na diaľku (napríklad u smart hodiniek alebo chladničiek). Rozsah je širší, než naznačuje slovo softvér. Smart televízor je z pohľadu útočníka ďalší počítač v sieti, hoci používateľ ho asi vníma ako bežný spotrebič.
Samostatná SaaS služba, ako sólo webová aplikácia vo webovom prehliadači, pod CRA automaticky nespadá. Rozhodujú architektúra, funkcie a spôsob sprístupnenia riešenia. Výrobcom navyše nemusí byť iba pôvodný vývojár. Povinnosti môže prevziať aj firma, ktorá produkt uvádza pod vlastnou značkou na trh alebo ho podstatne upraví. Rozsah CRA preto treba posúdiť pri každom produkte samostatne.
Aj keď patríte iba do kategórie „Default“, nie ste bez povinností
Veľká časť bežných inštalovateľných aplikácií nebude patriť medzi dôležité ani kritické produkty uvedené v prílohách CRA. Zaradí sa do takzvanej základnej kategórie označovanej ako „Default“. Pre slovenské a české softvérové firmy to môže byť najčastejší scenár.
Výhodou je jednoduchšie posudzovanie zhody. Výrobca môže použiť interné samohodnotenie a nepotrebuje povinne zapojiť notifikovanú a certifikovanú tretiu stranu. Stále však musí splniť technické požiadavky, vykonať analýzu rizík, aktívne vydávať nutné bezpečnostné aktualizácie, hlásiť závažné bezpečnostné incidenty a zneužívané známe zraniteľnosti. Zároveň má povinnosť pripraviť dokumentáciu, vydať EÚ vyhlásenie o zhode a pripojiť označenie CE.
Default teda neznamená nevyhnutne nižší štandard bezpečnosti. Hovorí len o tom, že výrobca súlad posúdi a deklaruje sám. Zároveň zaň preberá zodpovednosť.
Prvá povinnosť už platí
Už od 11. septembra 2026 majú výrobcovia prvú povinnosť hlásiť aktívne zneužívané zraniteľnosti a závažné bezpečnostné incidenty do NBÚ cez Jednotný informačný systém kybernetickej bezpečnosti. Plný režim CRA sa začne uplatňovať 11. decembra 2027. Ohlasovacie povinnosti sa vzťahujú aj na produkty uvedené na trh pred týmto dátumom.
Prvé varovanie treba odoslať do 24 hodín od chvíle, keď sa výrobca o udalosti dozvie, a podrobnejšie oznámenie do 72 hodín. Potom nasleduje záverečná správa , pri závažnom incidente do jedného mesiaca od oznámenia.
Ohlasovanie preto nie je iba vyplnením formulára. Firma potrebuje vedieť, ktorého produktu a verzie sa problém týka, aký je jeho dosah, kto rozhodne o hlásení a čo môže oznámiť zákazníkom.
Čo musí bezpečný produkt po novom zvládnuť
CRA premieňa všeobecné slovo „bezpečnosť“ na konkrétne vlastnosti produktu. Z požiadaviek, vyplýva najmä toto:
- Bezpečnosť musí byť zabudovaná do produktu s digitálnymi prvkami od prvého riadku kódu – takzvaná bezpečnosť by default
- Na trh nesmie ísť produkt so známou zraniteľnosťou, ktorú možno reálne zneužiť.
- Ochranné funkcie majú byť zapnuté už v predvolenom nastavení.
- Nepotrebné porty, služby, rozhrania a prístupové body majú zostať vypnuté.
- Dáta treba chrániť pred neoprávneným čítaním aj zmenou cez šifrovanie, autentifikáciu prístupu apod.
- Aktualizácie musia prichádzať bezpečným mechanizmom, ktorý útočník nedokáže podvrhnúť alebo obísť.
- Používateľ musí vedieť svoje dáta a nastavenia z produktu bezpečne odstrániť.
- Spoločným menovateľom je princíp security-by-design a odpoveďou by malo byť prísne uplatňovanie štandardov Secure Software Development Life Cycle.
Bezpečnostné požiadavky musíte premeniť na proces
Secure Software Development Life Cycle vkladá bezpečnostné kontroly do jednotlivých fáz vývoja. Pri plánovaní vzniká analýza rizík a threat model pre obmedzenie útočnej plochy. Pri návrhu sa riešia bezpečné predvolené nastavenia a ochrana dát. Počas programovania nastupujú pravidlá bezpečného kódu a závislosti knižníc tretích strán, kontrola tajomstiev, code review a skenovanie zraniteľností. Bežná kontrola kvality kódu pritom sama osebe nenahrádza bezpečnostnú analýzu.
V CI/CD pipeline možno automatizovať statickú analýzu zdrojového kódu, dependency checks a tvorbu SBOM. Pred vydaním sa pridávajú dynamické testovanie a podľa rizika aj penetračný test. Dôležité je, aby nálezy mali vlastníka, termín nápravy a záznam o opätovnom overení. Práve základná dokumentácia SSDLC následne ukazuje, že bezpečnosť nebola iba jednorazovou záležitosťou pred auditom.
Ak je cudzia knižnica deravá, je to stále váš problém
Moderné aplikácie pozostávajú z množstva open-source a komerčných komponentov. Ak zraniteľná knižnica ohrozí výsledný produkt, výrobca sa nemôže zbaviť zodpovednosti tvrdením, že chybu napísal niekto iný. Musí vedieť, čo do produktu vložil a aké riziko tým prevzal.
Základom je strojovo čitateľný zoznam softvérových komponentov a ich vzťahov. Samotný zoznam ale dáva zmysel až po prepojení s databázami zraniteľností, keď umožňuje rýchlo zistiť, ktorých produktov a verzií sa nová chyba týka.
Zodpovednosť pokračuje aj po predaji
Po uvedení produktu na trh nastupuje manažment zraniteľností. Výrobca potrebuje pre zákazníkov kontaktný bod na prijímanie hlásení, triáž, hodnotenie závažnosti, plán vydávania opráv a koordinované zverejňovanie zraniteľností. Počas deklarovaného obdobia podpory musí produkt bezpečnostne udržiavať a zákazníkov informovať o potrebných opatreniach. Štandardne musí trvať podpora 5 rokov po uvedení produktu na trh.
Ak sa zraniteľnosť začne aktívne zneužívať, do procesu vstupujú incident response a ohlasovacia povinnosť. Firma musí spojiť technické zistenia s konkrétnym produktom, verziou a dotknutými zákazníkmi. Bez aktuálneho inventára, SBOM a jasných zodpovedností sa aj jednoduché hlásenie môže zmeniť na zdĺhavé interné pátranie.
Pred ukončením doby podpory je výrobca povinný včas informovať zákazníkov o dátume ukončenia podpory.
Začať treba tým, čo už firma robí
Prvým krokom je zmapovať produkty, ich verzie, kategóriu podľa CRA, použité komponenty, obdobie podpory a spôsob aktualizácie. Nasledovať môže rozdielová analýza: ktoré požiadavky firma už plní, kde jej chýba dôkaz a kde nemá zavedený ani samotný proces.
Binary Confidence vie pomôcť s technickou časťou prípravy. Od analýzy rizík a základnej dokumentácie SSDLC cez skenovanie zdrojového kódu, dependency checks a SBOM až po testovanie a nastavenie incident reportingu.
CRA nemusí znamenať budovanie bezpečnosti od nuly. Pre firmy, ktoré ju doteraz robili správne, je najmä príležitosťou usporiadať existujúce postupy a vedieť preukázať, že bezpečný produkt nie je iba planý sľub v marketingových materiáloch.
Táto aktivita je podporovaná European Cybersecurity Competence Centre (ECCC) ako súčasť projektu s grantovým kódom: 101145856 a Ministerstvom investícií, regionálneho rozvoja a informatizácie ako súčasť projektu Plán obnovy pod grantovým kódom: 17I04-04-V02-00001.
