CRA pre softvérové firmy: čo riešiť ako prvé

Jedna softvérová firma môže súčasne:

• vyvíjať aplikáciu na mieru pre klienta,
• licencovať vlastný štandardizovaný modul,
• prevádzkovať cloudovú službu,
• poskytovať mobilnú aplikáciu,
• udržiavať staršie verzie produktu,
• používať desiatky open-source knižníc.

Z obchodného pohľadu je to všetko „softvér“. Z pohľadu CRA však nemusia mať tieto činnosti rovnaké postavenie.

Pri vlastnom produkte môže byť firma výrobcom a niesť celý rozsah povinností. Pri zákazkovom vývoji môže byť iba dodávateľom klienta. Samostatná cloudová služba nemusí automaticky patriť do CRA, zatiaľ čo vzdialené spracovanie nevyhnutné pre fungovanie konkrétneho produktu už môže byť jeho súčasťou.

Práve preto sa dobrá príprava nezačína veľkým zoznamom kontrol. Začína sa mapovaním produktov, rolí a zodpovedností.

CRA reguluje produkty, nie softvérové firmy ako celok

Cyber Resilience Act je európsky rámec pre kybernetickú bezpečnosť hardvérových a softvérových produktov s digitálnymi prvkami, ktoré sa sprístupňujú na trhu Európskej únie. Zahŕňa finálne produkty aj samostatne uvádzané softvérové alebo hardvérové komponenty. Produkt patrí do rozsahu najmä vtedy, keď jeho zamýšľané alebo rozumne predvídateľné použitie zahŕňa priame alebo nepriame dátové pripojenie k zariadeniu alebo sieti.

To znamená, že CRA sa neposudzuje iba podľa toho, či je organizácia „softvérovou firmou“. Rozhoduje konkrétny produkt a spôsob, akým sa dostáva k používateľovi.

Predbežne môžu jednotlivé modely vyzerať takto:

Situácia	Predbežné postavenie
Firma licencuje vlastnú aplikáciu pod vlastnou značkou	Pravdepodobne výrobca podľa CRA
Firma samostatne predáva vlastný SDK, plugin alebo softvérový modul	Môže ísť o samostatný produkt v rozsahu CRA
Vývojový tím vytvára systém na mieru, ktorý pod svojím menom uvádza klient	Výrobcom môže byť klient; vývojár zostáva významným dodávateľom
Firma vyvíja nástroj výlučne pre vlastnú internú potrebu	Spravidla mimo CRA, ak sa neposkytuje v rámci komerčnej činnosti
Firma prevádzkuje samostatnú SaaS službu	Nie automaticky v rozsahu; treba posúdiť produkt a vzdialené spracovanie
Firma udržiava open-source projekt	Rozhoduje komerčný kontext a konkrétna rola organizácie

Tabuľka je iba orientačná. Definitívne postavenie môže závisieť od zmlúv, obchodného modelu, vlastníctva produktu, spôsobu distribúcie a zodpovednosti za jeho ďalšiu podporu.

Prvá otázka: kto je výrobcom?

Za výrobcu CRA považuje subjekt, ktorý produkt vyvíja alebo vyrába, prípadne si ho necháva navrhnúť či vyvinúť, a následne ho uvádza na trh pod svojím menom alebo ochrannou známkou. Produkt môže byť poskytovaný za odplatu, monetizovaný iným spôsobom alebo za určitých okolností aj bezplatne.

Pri štandardnom vlastnom softvéri býva odpoveď pomerne jasná.

Komplikovanejšie sú:

• zákazkové projekty,
• white-label riešenia,
• spoločný vývoj s klientom,
• produkty postavené na riešení tretej strany,
• moduly integrované do väčšieho systému,
• platformy, pri ktorých jedna firma vyvíja frontend a iná backend,
• riešenia poskytované pod značkou obchodného partnera.

Názov dodávateľa uvedený na faktúre ešte sám osebe neurčuje rolu výrobcu.

Pri každom produkte treba vedieť najmä:

• kto definuje jeho zamýšľaný účel,
• pod čím menom alebo značkou sa poskytuje,
• kto rozhoduje o vydaní novej verzie,
• kto vedie produktovú a technickú dokumentáciu,
• kto zabezpečuje bezpečnostné aktualizácie,
• kto prijíma a vyhodnocuje hlásenia o zraniteľnostiach,
• kto určuje obdobie podpory.

Ak tieto zodpovednosti drží klient, vývojová firma nemusí byť priamo výrobcom. Klient na ňu však pravdepodobne prenesie významnú časť požiadaviek cez zmluvu.

Môže požadovať bezpečný vývoj, kontrolu závislostí, dokumentovanie zmien, bezpečnostné testovanie, nápravu zraniteľností v určených lehotách či poskytovanie dôkazov do technickej dokumentácie. Zákonnú zodpovednosť výrobcu nemožno jednoduchým zmluvným ustanovením úplne odovzdať dodávateľovi, ale bez jeho súčinnosti výrobca často nebude schopný svoj súlad preukázať.

Čo teda riešiť ako prvé? Produktovú a rolovú mapu

Prvým praktickým výstupom by nemala byť nová bezpečnostná smernica.

Mala by ním byť stručná mapa, ktorá pri každom riešení určí:

• názov produktu alebo produktovej rodiny,
• jednotlivé edície a podporované verzie,
• spôsob dodania – licencia, mobilná aplikácia, komponent, cloud alebo zákazkový vývoj,
• trhy, na ktorých sa produkt poskytuje,
• značku, pod ktorou sa uvádza,
• predpokladanú rolu firmy podľa CRA,
• zodpovednosť za vývoj, vydávanie verzií a podporu,
• zodpovednosť za zraniteľnosti a aktualizácie,
• súvisiace vzdialené služby a externé komponenty.

Tento krok rozhodne o rozsahu všetkého, čo bude nasledovať.

Bez produktovej mapy firma nevie spoľahlivo určiť:

• pre ktoré produkty má vykonať posúdenie rizík,
• ktoré komponenty patria do konkrétneho SBOM,
• aké verzie musí podporovať,
• pri ktorých produktoch môže vzniknúť oznamovacia povinnosť,
• akú technickú dokumentáciu potrebuje,
• aký spôsob posudzovania zhody sa použije.

Európska komisia v júli 2026 zverejnila praktické usmernenie k CRA, ktoré sa venuje práve otázkam rozsahu, vzdialeného spracovania dát, open-source softvéru, zásadných modifikácií, obdobia podpory, oznamovania a posudzovania rizík. Usmernenie nie je právne záväzné, ale obsahuje 67 praktických príkladov a pomáha firmám aplikovať nariadenie na konkrétne obchodné a produktové modely.

Kde sa končí produkt a začína služba?

Pri modernom softvéri produkt často nie je jeden súbor, ktorý si zákazník nainštaluje.

Môže pozostávať z:

• lokálnej aplikácie,
• mobilného klienta,
• backendu,
• API,
• aktualizačnej služby,
• autentifikačnej vrstvy,
• databázy,
• vzdialenej analytiky,
• externých cloudových služieb.

CRA zahŕňa aj vzdialené spracovanie dát, ak bolo navrhnuté výrobcom alebo pod jeho zodpovednosťou a bez neho by produkt nedokázal vykonávať niektorú zo svojich funkcií.

Z toho vyplýva dôležitá nuansa:

Nie každé SaaS riešenie je automaticky produktom podľa CRA. Vzdialená služba však môže byť súčasťou produktu, ak je nevyhnutná pre jeho fungovanie.

Softvérová firma preto potrebuje určiť hranice produktu ešte pred tým, ako začne pripravovať jeho dokumentáciu.

Ak mobilná aplikácia bez konkrétneho backendu nefunguje, posudzovanie iba samotnej aplikácie môže byť nedostatočné. Ak naopak firma poskytuje všeobecnú cloudovú službu nezávislú od konkrétneho produktu, jej postavenie môže byť odlišné.

Nezačínajte nákupom SBOM nástroja

SBOM – softvérový kusovník – je formálny záznam komponentov a vzťahov v softvéri. V prostredí CRA bude predstavovať dôležitú súčasť riadenia softvérového dodávateľského reťazca.

Výrobca musí pri integrovaní komponentov tretích strán postupovať s náležitou starostlivosťou, aby tieto komponenty nenarušili bezpečnosť výsledného produktu. CRA zároveň počíta s evidenciou komponentov a s vytvorením SBOM v bežne používanom, strojovo spracovateľnom formáte.

To však neznamená, že prvým krokom má byť výber nástroja.

SBOM odpovie na otázku:

Čo sa v produkte nachádza?

Sám osebe však neodpovie:

• či sa zraniteľnosť konkrétneho komponentu dá v produkte zneužiť,
• ktoré verzie produktu sú zasiahnuté,
• kto musí rozhodnúť o oprave,
• ako rýchlo musí vzniknúť aktualizácia,
• ako sa oprava dostane k zákazníkom,
• či udalosť treba oznámiť,
• aké dôkazy zostanú po vykonaní nápravy.

ENISA vo svojej správe z júna 2026 uvádza, že CRA už urýchľuje zavádzanie SBOM. Zo skúmaných organizácií začalo so zavádzaním 78 %, ale iba 9 % uvádzalo plne vyspelé a automatizované používanie. Rozdiel medzi „vieme SBOM vygenerovať“ a „vieme ho aktívne používať pri riadení rizík“ je preto stále významný.

Dobrý postup je opačný:

1. určiť produkty a ich hranice,
2. zmapovať vývojové a dodávateľské reťazce,
3. zistiť, aké informácie už dnes vznikajú,
4. až potom vybrať formát, nástroj a úroveň automatizácie.

Open-source komponent nie je spôsob, ako preniesť zodpovednosť

Veľká časť moderného softvéru vzniká z open-source knižníc, frameworkov, kontajnerových obrazov a ďalších externých komponentov.

Free and open-source softvér poskytovaný mimo komerčnej činnosti môže byť mimo priameho rozsahu CRA. Nariadenie zároveň pozná osobitnú rolu open-source software stewarda pre právnické osoby, ktoré dlhodobo a systematicky podporujú vývoj konkrétneho open-source softvéru určeného na komerčné použitie.

Pre výrobcu komerčného produktu je však podstatná iná otázka:

Vieme, aké open-source komponenty používame, kto ich udržiava a ako reagujeme, keď sa v nich objaví zraniteľnosť?

Zahrnutie open-source knižnice do komerčného produktu nezbavuje výrobcu zodpovednosti za bezpečnosť výsledného riešenia.

Firma potrebuje vedieť:

• sledovať stav používaných závislostí,
• rozpoznať opustené alebo neudržiavané projekty,
• vyhodnocovať bezpečnostné upozornenia,
• aktualizovať komponenty bez neprimeraného narušenia produktu,
• zdokumentovať rozhodnutie, ak aktualizáciu nie je možné vykonať,
• riadiť závislosti vytvorené subdodávateľmi.

Najbližšia povinnosť nie je CE, ale oznamovanie

Hlavné produktové povinnosti CRA sa začnú vo všeobecnosti uplatňovať od 11. decembra 2027. Oznamovacie povinnosti však začínajú už 11. septembra 2026.

Výrobca bude prostredníctvom jednotnej platformy CRA oznamovať:

• aktívne zneužívané zraniteľnosti,
• závažné incidenty s vplyvom na bezpečnosť produktu.

Prvé varovanie sa podáva do 24 hodín od zistenia udalosti a hlavné oznámenie do 72 hodín. Pri aktívne zneužívanej zraniteľnosti nasleduje záverečná správa najneskôr do 14 dní od dostupnosti nápravného alebo zmierňujúceho opatrenia; pri závažnom incidente spravidla do jedného mesiaca. Platformu prevádzkuje ENISA a má byť funkčná od začiatku oznamovacej povinnosti.

Oznamovanie sa navyše vzťahuje aj na produkty, ktoré boli na trhu už pred 11. decembrom 2027.

Pre softvérovú firmu je preto prvou bezprostrednou prevádzkovou témou proces, ktorý prepája:

zistenie zraniteľnosti → určenie dotknutých produktov → posúdenie udalosti → eskaláciu → rozhodnutie → oznámenie → nápravu

Ak firma nevie rýchlo prepojiť zraniteľný komponent s produktmi a podporovanými verziami, 24-hodinová lehota sa môže minúť iba interným zisťovaním.

Secure by design musí vstúpiť do bežného vývoja

CRA vyžaduje, aby posúdenie kybernetických rizík ovplyvňovalo plánovanie, návrh, vývoj, výrobu, dodanie aj údržbu produktu. Nejde teda o kontrolu vykonanú až pred vydaním.

Pre softvérovú firmu to neznamená, že musí vytvoriť druhý paralelný vývojový proces.

Bezpečnosť je potrebné vložiť do existujúceho SDLC:

• bezpečnostné požiadavky do návrhu produktu,
• primerané modelovanie hrozieb,
• kontrolu zmien a závislostí,
• bezpečné programovanie a overovanie,
• release kritériá,
• riadenie zraniteľností a opráv,
• logging a monitoring tam, kde sú relevantné,
• bezpečné predvolené nastavenia,
• evidenciu rozhodnutí a výsledkov testovania.

ENISA v júli 2026 vydala praktický Secure by Design and Default Playbook pre menšie a stredné podniky. Obsahuje 22 oblastí, medzi nimi minimalizáciu útočnej plochy, least privilege, autentifikáciu, bezpečné programovanie, monitoring, patch management, dodávateľský reťazec, automatizované aktualizácie a bezpečnú obnovu. Dôležitou súčasťou playbooku sú aj príklady dôkazov, ktorými možno preukázať, že daný princíp nebol iba deklarovaný, ale reálne zavedený.

To je dôležitý posun aj pre vývojové tímy:

Nestačí vykonať bezpečnostnú aktivitu. Treba vedieť zachovať primeraný dôkaz, že bola vykonaná a s akým výsledkom.

Obdobie podpory už nebude iba obchodným údajom

Výrobca bude musieť pri produkte určiť obdobie podpory a počas neho zabezpečovať účinné riešenie zraniteľností. Koncový dátum obdobia podpory má byť používateľovi oznámený jasne a zrozumiteľne.

Pre softvérové firmy to otvára praktické otázky:

• Koľko verzií produktu podporujeme súčasne?
• Ktoré opravy spätne prenášame do starších verzií?
• Kedy sa verzia dostáva do režimu end-of-life?
• Ako o ukončení podpory informujeme zákazníkov?
• Čo sa stane, ak klient odmieta vykonať aktualizáciu?
• Vieme ešte zostaviť, otestovať a bezpečne vydať opravu pre staršiu vetvu?

Ak tieto pravidlá dnes existujú iba neformálne v hlavách vývojárov alebo obchodníkov, CRA ich prinúti premeniť na riadený produktový proces.

CE a posudzovanie zhody treba naplánovať vopred

Pred uvedením produktu na trh musí výrobca vykonať príslušný postup posudzovania zhody. Po úspešnom preukázaní požiadaviek vypracuje EÚ vyhlásenie o zhode a na produkt umiestni označenie CE. Technická dokumentácia pritom musí zachytiť produkt, posúdenie rizík, uplatnené požiadavky a dôkazy o ich splnení.

Pri väčšine bežných produktov, medzi ktoré Komisia zaraďuje napríklad mobilné aplikácie alebo počítačové hry, môže byť povolené interné posúdenie výrobcom.

Pri dôležitých produktoch, ako sú operačné systémy, antivírusové riešenia či niektoré nástroje na riadenie siete, môže byť potrebné použiť harmonizované normy alebo zapojiť notifikovaný orgán. Pri kritických produktoch je posúdenie treťou stranou povinné.

Klasifikáciu produktu preto netreba nechávať na koniec projektu. Ovplyvní:

• potrebné dôkazy,
• spôsob testovania,
• časový plán,
• rozpočet,
• výber externého posudzovateľa.

Harmonizované normy majú výrobcom uľahčiť preukazovanie súladu a pri ich použití umožniť právnu domnienku zhody s príslušnými požiadavkami. Komisia zadala prípravu 41 horizontálnych a produktovo špecifických noriem, no ich vývoj stále pokračuje. Firmy by preto nemali odkladať prípravu dovtedy, kým bude hotový celý normalizačný rámec.

Slovenský rámec dohľadu sa pripravuje

Slovenská vláda v auguste 2026 schválila návrh zákona o kybernetickej odolnosti. Návrh bol 27. augusta doručený do Národnej rady SR ako parlamentná tlač 1450.

Jeho cieľom je vytvoriť vnútroštátny rámec pre uplatňovanie CRA, upraviť pôsobnosť Národného bezpečnostného úradu, dohľad nad trhom, kontroly a súvisiace národné postupy. V čase prípravy tohto článku ide stále o návrh zákona v legislatívnom procese, nie o schválený právny predpis.

Pre výrobcov to nemení základnú logiku CRA. Nariadenie platí priamo na úrovni EÚ. Slovenská legislatíva má vytvoriť domáci mechanizmus dohľadu a vymáhania.

Sedem otázok, ktoré by mala softvérová firma zodpovedať

Pred nákupom nástroja alebo začiatkom rozsiahleho projektu by malo vedenie spolu s produktovými a vývojovými tímami vedieť odpovedať na tieto otázky:

1. Ktoré naše riešenia sú samostatnými produktmi alebo komponentmi uvádzanými na trh?
2. Pri ktorých produktoch vystupujeme ako výrobca a pri ktorých iba ako dodávateľ klienta?
3. Kde sa nachádza hranica produktu vrátane backendu a vzdialených služieb?
4. Ktoré verzie sú stále podporované a dokedy?
5. Vieme ku každému produktu identifikovať použité komponenty a závislosti?
6. Máme funkčný proces prijímania, posudzovania, opravy a oznamovania zraniteľností?
7. Vznikajú počas vývoja dôkazy použiteľné v technickej dokumentácii a pri posudzovaní zhody?

Ak odpoveď na prvé tri otázky nie je jasná, ešte nie je správny čas vytvárať univerzálny CRA checklist pre celú firmu.

Čo má byť výsledkom prvého posúdenia

Úvodné CRA posúdenie nemusí byť rozsiahly audit všetkých vývojových procesov.

Malo by predovšetkým vytvoriť:

• prehľad produktových rodín,
• určenie role firmy pri jednotlivých produktoch,
• hranice produktov a súvisiacich vzdialených služieb,
• predbežnú klasifikáciu produktov,
• zoznam podporovaných verzií,
• prehľad bezprostredných oznamovacích povinností,
• identifikáciu najväčších rozdielov v SDLC, komponentoch, zraniteľnostiach a dokumentácii,
• prioritizovaný plán ďalšej prípravy.

Až potom sa dá zodpovedne rozhodnúť, kde je potrebné zaviesť SBOM, upraviť vývojový proces, doplniť zmluvy s dodávateľmi, vybudovať vulnerability disclosure proces alebo pripraviť posudzovanie zhody.

CRA nezačína dokumentom. Začína vlastníctvom produktu

Najväčšou chybou softvérovej firmy nemusí byť to, že ešte nemá úplnú technickú dokumentáciu.

Väčším problémom je situácia, keď organizácia nevie:

• čo presne považuje za produkt,
• pod čím menom sa produkt poskytuje,
• kto zaň zodpovedá po vydaní,
• ktoré verzie sa ešte podporujú,
• kto rozhoduje pri zraniteľnosti.

Bez týchto odpovedí sa CRA rozdelí medzi právnikov, bezpečnosť, vývoj, produktový tím a support – ale nebude mať jedného vlastníka ani spoločný plán.

Prvým krokom preto nie je implementovať všetko. Prvým krokom je správne určiť rozsah, produktové role a priority.

Na takomto základe možno vytvoriť primeranú implementačnú mapu, ktorá nevytvorí druhý paralelný vývojový proces, ale zapracuje požiadavky CRA do spôsobu, akým firma produkty už dnes navrhuje, vydáva, podporuje a aktualizuje.

Text zachytáva stav k 2. septembru 2026 a má všeobecný informačný charakter. Nenahrádza individuálne právne, regulačné ani technické posúdenie.

Zdroje a ďalšie informácie

Európska komisia

• Cyber Resilience Act – základný prehľad regulácieZákladné informácie o CRA, jeho cieľoch, rozsahu a termínoch uplatňovania. Digital Strategy EU
• The Cyber Resilience Act – Summary of the legislative text Súhrn právneho textu CRA vrátane rozsahu, definícievýrobcu, produktov s digitálnymi prvkami, vzdialeného spracovania, open-source softvéru, podpory, technickej dokumentácie a povinností hospodárskych subjektov. Digital Strategy EU
• Commission publishes new guidance to support timely Cyber Resilience Act implementation Praktické usmernenieKomisie z 27. júla 2026 k rozsahu CRA, vzdialenému spracovaniu, open-source softvéru, zásadným modifikáciám, obdobiu podpory, oznamovaniu a posudzovaniu rizík. Digital Strategy EU
• Cyber Resilience Act – Reporting obligationsInformácie o oznamovacích povinnostiach od 11. septembra 2026, lehotách 24 a 72 hodín a záverečných správach pri zraniteľnostiach a incidentoch. Digital Strategy EU
• Cyber Resilience Act – Conformity assessmentInformácie o kategóriách produktov, internom posúdení výrobcom, zapojení notifikovaných osôb, EÚ vyhlásení o zhode a označení CE. Digital Strategy EU
• Cyber Resilience Act – StandardisationInformácie o harmonizovaných normách, domnienke zhody a pripravovaných horizontálnych a produktových normách na podporu CRA. Digital Strategy EU

ENISA – Agentúra Európskej únie pre kybernetickú bezpečnosť

• SBOM Adoption – State of Play 2026Správa o zavádzaní SBOM, jeho využití pri riadení zraniteľností a dodávateľského reťazca a o aktuálnej úrovni pripravenosti organizácií. ENISA
• ENISA Secure by Design and Default PlaybookPraktický rámec bezpečnosti od návrhu a predvolených bezpečných nastavení vrátane príkladov opatrení a dôkazov o ich zavedení. ENISA

Národný bezpečnostný úrad SR

• Vláda Slovenskej republiky schválila návrh zákona o kybernetickej odolnosti Informácie o pripravovanom slovenskom rámci dohľadu nad trhom, kontrolách a pôsobnosti NBÚ pri uplatňovaní CRA.