Cyber Resilience Act: EU nařídila bezpečný vývoj software. Co to znamená pro vaši firmu?

Bezpečnostní komunita léta ví, jak by správný vývoj software měl vypadat: bezpečnost se buduje od začátku, ne záplátuje na konci. Závislosti (dependencies) musí být sledovány a aktualizovány. Zranitelnosti je potřeba hlásit a rychle opravovat. Produkty musí mít bezpečnou výchozí konfiguraci, ne takovou, která uživateli „usnadní život" tím, že věci nechá otevřené.

Problém byl vždy čas a peníze. Bezpečnost se odkládala. Cyber Resilience Act to mění. Od října 2027 jsou tyto principy pro výrobce velké části softwarových a hardwarových produktů prodávaných v EU zákonnou povinností.

Co je Cyber Resilience Act

Cyber Resilience Act (CRA) je nařízení Evropské unie č. 2024/2847. Stanovuje závazné požadavky na kybernetickou bezpečnost pro produkty s digitálními prvky, které jsou uváděny na trh EU. To zahrnuje jak hardware, tak software.

Zákon vstoupil v platnost 10. října 2024. Vychází z jednoduché premisy: výrobci nesou odpovědnost za bezpečnost svých produktů po celou dobu jejich podporované životnosti, nikoli jen v okamžiku prodeje. A tuto odpovědnost nemohou přenést na zákazníka jednostranným vyloučením v licenčních podmínkách (EULA).

CRA není revolucí bez základů. Velká část toho, co vyžaduje, jsou věci, o kterých si bezpečnostní inženýři říkají v průmyslu léta. Zákon je mění v právo.

Na koho se CRA vztahuje

Tady je věc, která firmy nepříjemně překvapuje: CRA se nevztahuje jen na výrobce routerů, chytrých žárovek nebo průmyslového hardwaru. Vztahuje se na jakýkoli produkt s digitálními prvky, který splňuje dvě podmínky. Za prvé, je uváděn na trh EU za účelem obchodní transakce, ať už jako placený produkt nebo zdarma jako součást jiné nabídky. Za druhé, zahrnuje software nebo firmware schopný komunikovat se sítí nebo jiným zařízením.

V praxi to pokrývá mobilní aplikace distribuované jako součást produktu, desktopový software, firmware IoT zařízení, průmyslové řídicí systémy, síťové prvky (routery, přepínače, firewally), zdravotnické přístroje s konektivitou a chytré domácí systémy — mimo jiné.

Čistě SaaS modely jsou z CRA vyjmuty, protože se jedná o službu, nikoli produkt. Pokud ale vaše SaaS nabídka zahrnuje klientský software instalovaný na zařízení uživatele (agent, desktop app, SDK, plugin), tento klientský software do rozsahu CRA zpravidla spadá.

Open source software v nekomerčním prostředí je z CRA vyňat. Komerční distribuce nebo komerční podpora open source projektu pod CRA pravděpodobně spadá.

CRA rozlišuje produkty podle míry rizika. Výchozí kategorie zahrnuje většinu produktů a umožňuje výrobci provést vlastní posouzení shody. Kategorie důležitých produktů (třída I a II) zahrnuje produkty s vyšším inherentním rizikem: VPN, firewally, správce identit, síťové prvky nebo operační systémy. Pro ně platí přísnější požadavky na posouzení třetí stranou nebo shodu s harmonizovanými normami.

Co CRA konkrétně vyžaduje

Bezpečnost v návrhu a bezpečné výchozí nastavení

Produkty musí být navrženy tak, aby minimalizovaly útočnou plochu a vycházely z principu nejmenšího privilegia. Bezpečnostní funkce musí být zapnuty v základní konfiguraci, ne nabízeny jako volitelná nadstavba. Kryptografické mechanismy musí odpovídat aktuálnímu stavu techniky.

V praxi to znamená, že bezpečnostní otázky musí být zodpovězeny v design fázi, ne při security review těsně před vydáním verze.

Software Bill of Materials (SBOM)

CRA vyžaduje, aby výrobce vedl a mohl zpřístupnit úplný seznam softwarových komponent svého produktu. Software Bill of Materials (SBOM) je strojově čitelný dokument zachycující všechny závislosti, použité knihovny a jejich verze.

SBOM není jen papírový výkaz pro auditory. Umožňuje rychle zjistit, zda váš produkt obsahuje komponentu s nově objevenou zranitelností, a jak rychle ji opravit. Incident jako Log4Shell v roce 2021 postihl bezpočet organizací částečně proto, že jednoduše nevěděly, kde všude tuto knihovnu používají. SBOM tento problém systematicky řeší.

Zákon nevyžaduje SBOM zveřejnit. Vyžaduje, aby existoval, byl aktuální a byl dostupný orgánům dozoru na vyžádání.

Správa zranitelností po celou dobu životnosti

Výrobce musí mít definovaný a funkční proces pro příjem a zpracování nahlášených zranitelností. Bezpečnostní záplaty musí být vydávány bezplatně a bezodkladně po celou dobu, po kterou výrobce produkt podporuje. Výrobce si sám určí dobu podpory, ale musí ji skutečně dodržovat a transparentně sdělit uživatelům.

To v praxi znamená: veřejná vulnerability disclosure policy (VDP), interní triage proces, SLA na vydání záplat a průběžné sledování zranitelností v použitých komponentách.

Hlášení incidentů a zranitelností

Od července 2026 platí přísné lhůty pro hlášení orgánům. Výrobce musí nahlásit aktivně zneužívanou zranitelnost ve svém produktu nebo závažný bezpečnostní incident národnímu CSIRTu (v Česku NÚKIB) a agentuře ENISA.

Tyto lhůty jsou velmi krátké. Bez předem připravených procesů a jasně definované vnitřní komunikace je téměř nemožné je dodržet.

Proč CRA fakticky nařizuje DevSecOps

Výše popsané požadavky nejsou izolované checkboxy. Dohromady tvoří to, co bezpečnostní komunita označuje jako DevSecOps: přístup, při kterém je bezpečnost integrována do celého vývojového cyklu místo toho, aby probíhala jako jednorázový test na konci projektu.

Bezpečné výchozí nastavení a design vyžadují threat modeling v rané fázi návrhu. SBOM vyžaduje průběžnou správu závislostí a automatizaci (Software Composition Analysis). Správa zranitelností vyžaduje funkční CI/CD pipeline s bezpečnostními kontrolami, průběžné testování a fungující VDP. Hlášení v rámci 24 hodin vyžaduje dobře nastavený monitoring, alerting a eskalační procesy.

Firmy, které DevSecOps praktiky zaváděly proto, že to dává smysl, budou mít silný argument vůči vedení: investice se vrátí jako CRA compliance. Firmy, které to dosud ignorovaly, musí začít. Alternativou jsou pokuty a zákaz prodeje na EU trhu.

Termíny, které nesmíte prošvihnout

Říjen 2027 může vypadat vzdáleně. Není. Restrukturalizace vývojových procesů, zavedení SBOM, nastavení VDP a příprava na reporting jsou záležitostí měsíců, ne týdnů.

Sankce za nedodržení

Za porušení CRA hrozí:

• Pokuta až 15 milionů EUR nebo 2,5 % celosvětového ročního obratu (vyšší z obou hodnot) za nejzávažnější porušení, jako je uvádění produktů nesplňujících základní požadavky na trh.

• Pokuta až 10 milionů EUR nebo 2 % obratu za méně závažná porušení.

• Pokuta až 5 milionů EUR nebo 1 % obratu za poskytnutí nepravdivých nebo neúplných informací orgánům.

Vedle finančních pokut může dozorový orgán nařídit stažení nebo zákaz prodeje produktu na EU trhu. Pro firmy orientované na evropský trh jde o existenční hrozbu.

Co dělat teď: praktický rozcestník

Zjistěte, zda se na vás CRA vztahuje. Nestačí se zeptat, jestli prodáváte software. Správná otázka je: uvádíte na trh EU produkt (ne čistě SaaS bez klientské komponenty), který komunikuje se sítí nebo jiným zařízením? Pokud ano, CRA se vás pravděpodobně týká.

Proveďte inventuru závislostí. Začněte budovat nebo formalizovat SBOM pro vaše produkty. Nástroje jako Syft, cdxgen nebo formáty SPDX a CycloneDX jsou průmyslovým standardem a mnohé CI/CD platformy je umí generovat automaticky jako součást pipeline.

Nastavte nebo zkontrolujte vulnerability disclosure proces. Máte místo, kam mohou výzkumníci nebo zákazníci nahlásit zranitelnost? Existuje interní triage proces? Víte, kdo konkrétně zodpovídá za notifikaci NÚKIB do 24 hodin od zjištění incidentu?

Proveďte audit SDLC z pohledu CRA. Kde ve vašem vývojovém procesu probíhají bezpečnostní kontroly? Pokud jen jako jednorázový pentest před vydáním, nestačí to. CRA předpokládá průběžnou bezpečnostní péči v průběhu celého životního cyklu produktu.

Určete kategorii vašeho produktu. Různé kategorie produktů mají různé požadavky na posouzení shody. Produkty jako VPN, firewally, správce identit nebo operační systémy spadají do kategorií s přísnějšími požadavky.

Začněte teď, ne v roce 2027. Říjen 2027 vypadá vzdáleně, ale implementace procesů, školení týmů, audit kódu, nastavení toolingu a případná certifikace trvají. Firmy, které začnou v roce 2025 nebo 2026, zvládnou přechod v klidu. Firmy, které začnou v září 2027, nezvládnou.

CRA a česká legislativa

CRA je nařízení EU a platí v Česku přímo, bez nutnosti přepisu do národního zákona. Vedle CRA platí Zákon o kybernetické bezpečnosti (ZKB) a jeho novela transponující NIS2 direktivu. Tyto regulace cílí na různé skupiny subjektů: CRA na výrobce produktů, ZKB na provozovatele základních a důležitých služeb.

Pokud vaše firma spadá pod obě regulace, platí jedno zjednodušení: investice do bezpečné architektury, SBOM a vulnerability managementu pomáhají splnit požadavky obou. Bezpečnostní procesy se nepočítají dvakrát — a nemusíte je budovat dvakrát.

CRA je zákon, který přiznává, co bezpečnostní komunita věděla léta: bezpečný software se nepíše náhodou. Píše se záměrně, od začátku, s nástroji, procesy a disciplínou. Teď je to právně vymahatelné.

Pokud si nejste jisti, zda se na vás CRA vztahuje, nebo chcete vědět, co konkrétně musíte ve vývoji změnit, rádi vám pomůžeme.

Zahájit konzultaci

Pomáháme firmám s posouzením rozsahu CRA, zavedením bezpečného SDLC, implementací DevSecOps praktik a přípravou procesů pro správu zranitelností. Úvodní konzultace je zdarma. Odpovídáme do 24 hodin.

Naposledy aktualizováno: 18. 6. 2026.

Zdroje: Nařízení EU 2024/2847 (Cyber Resilience Act) · ENISA — Cyber Resilience Act · Evropská komise — Kybernetická odolnost