Cyber Resilience Act v aplikační praxi: Konec jedné éry?

JUDr. Ing. Jindřich Kalíšek, Ph.D. CIPPE CIPM FIP, CEO regfor

Kybernetická bezpečnost produktů přestává být volitelnou položkou a stává se tvrdým požadavkem legislativy.
Vývojáři, výrobci i integrátoři digitálních produktů se dosud pohybovali v prostředí, kde rychlost uvedení na trh (time-to-market) často vítězila nad bezpečností. Evropská unie na tuto situaci reaguje nařízením o kybernetické odolnosti (Cyber Resilience Act – CRA), které má plošně definovat bezpečnostní standardy pro prakticky veškerý hardware a software a škálovat odpovědnost napříč celým dodavatelským řetězcem.

Právě široká působnost CRA a „ponor do hlubin“ dodavatelského řetězce a závislostí v něm činí
z tohoto předpisu normu s mimořádným dopadem na celý IT průmysl. Současně však platí, že čím hlouběji nařízení zasahuje do životního cyklu vývoje softwaru (SDLC), tím vyšší nároky vznikají na automatizaci, compliance a bezpečnostní ošetření.

Cíle a obsah CRA

V praktické rovině CRA zásadně proměňuje přístup k životnímu cyklu digitálních produktů. Před přijetím CRA řešily předpisy Unie rizika související s touto širokou kategorií výrobků
a souvisejících služeb jen částečně, často v rámci oborových regulací, čímž vznikala nepřehledná legislativní mozaika. Zásadním problémem ale byla nízká úroveň kybernetické bezpečnosti – produkty byly běžně uváděny na trh s rozsáhlými zranitelnostmi a nekonzistentním poskytováním bezpečnostních aktualizací.

CRA tento přístup mění. Evropský zákonodárce otevřeně hovoří o tom, že hlavním motivem jeho regulačních snah je stále složitější bezpečnostní a geopolickou situace a zamezení stále častějším situacím, kdy se i triviální chytré zařízení stává vektorem útoku na kritickou infrastrukturu a základní funkce státních organizací i soukromých podniků. Jeho cílem je zajistit, aby produkty s digitálním prvkem (hardware i software) byly vyvíjeny jako „secure by design“ (produkt musí být navrhován a od počátku vyvíjen s cílem dosahovat jeho bezpečnosti) a „secure by default“ (produkt musí být standardně dodáván jako bezpečný a dostatečně zabezpečený).

Nejde pouze o ochranu samotných produktů (a jejich prostřednictvím spotřebitele), ale o naplňování principů bezpečného návrhu a výroby produktů v rámci celého dodavatelského řetězce. Svým dopadem proto CRA dalece přesáhne obecnou regulaci kybernetické bezpečnosti (na evropské úrovni realizovanou především směrnicemi NIS2 a CER), tak oborovou anebo produktovou regulaci (kterou reprezentují například nařízení o digitální provozní odolnosti finančních subjektů – DORA aneb nařízení o umělé inteligenci – AIA).

Na koho CRA dopadá a kdo by měl zpozornět

Nařízení přímo dopadá na výrobce, dovozce a distributory produktů s digitálním prvkem, jejichž zamýšlené nebo rozumně předvídatelné použití zahrnuje přímé či nepřímé logické nebo fyzické datové připojení k zařízení nebo síti. Jinak řečeno, CRA dopadá téměř „připojené“ –
od chytrých hodinek a senzorů, přes routery a firewally, až po operační systémy, mobilní aplikace a firemní software.

Z působnosti je naopak vyjmut software poskytovaný čistě jako služba (SaaS), pokud ovšem není řešením pro zpracování dat na dálku (remote data processing), které je nezbytné pro fungování konkrétního produktu. CRA se také nevztahuje na nekomerční svobodný software s otevřeným zdrojovým kódem (open-source), pokud není monetizován. Pro komerční open-source projekty
a nadace (tzv. open-source software stewards) zavádí CRA specifický, poněkud mírnější režim.

Dopad je nicméně obrovský. Nejen vývojáři, ale i IT management, techničtí a produktoví manažeři (CTO / CPO) a bezpečnostní manažeři (CISO) musí zbystřit, protože odpovědnost za kybernetickou bezpečnost nyní leží primárně na výrobci a propisuje se celým dodavatelským řetězcem.

Co se od vás očekává

Organizace se budou muset vypořádat se dvěma sadami základních požadavků zakotvených
v příloze I nařízení CRA:

1. Požadavky na kybernetickou bezpečnost produktů (13 požadavků)

Produkty musí být navrženy tak, aby zohledňovaly rizika, a na trh musí být uváděny bez známých zneužitelných zranitelností.

Musí mít bezpečnou výchozí konfiguraci („secure by default“), chránit důvěrnost
a integritu dat (včetně šifrování), minimalizovat sbíraná data a omezovat prostor pro útok (attack surface) minimalizací externích rozhraní.

2. Požadavky na procesy řešení zranitelností (8 požadavků)

Výrobci musí identifikovat a dokumentovat zranitelnosti a komponenty, a to i formou softwarového kusovníku (SBOM).

Musí bezodkladně poskytovat bezpečnostní aktualizace, které by měly být technicky oddělené od aktualizací funkčních.

CRA dále vyžaduje provádění „účinných a pravidelných testů a přezkumů bezpečnosti produktu“, zavedení politiky koordinovaného zveřejňování zranitelností (CVD)
a mechanismy pro bezpečnou distribuci aktualizací.

Doba podpory, po kterou musí výrobce tyto aktualizace poskytovat, se určuje na základě očekávané doby používání produktu, nesmí však být kratší než 5 let (pokud není životnost produktu přirozeně kratší). Zásadní novinkou je, že bezpečnostní aktualizace musí zůstat dostupné minimálně po dobu 10 let.

Nejbližší lhůty

CRA byl v Úředním věstníku EU publikován v listopadu 2024 a vstoupil v platnost 10. prosince 2024.

11. září 2026 (21 měsíců po vstupu v platnost): Začnou platit přísné povinnosti ohledně hlášení incidentů. Výrobci budou muset hlásit aktivně zneužívané zranitelnosti a závažné incidenty agentuře ENISA a národním CSIRT týmům. Časové okno je přitom neúprosné: včasné varování do 24 hodin, plné oznámení do 72 hodin.

11. prosince 2027 (36 měsíců po vstupu v platnost): Nařízení začne platit v plném rozsahu. Od tohoto data musí všechny nové produkty i významné aktualizace stávajících produktů plně odpovídat požadavkům CRA a nést označení CE.

Hlavní implementační problémy pro výrobce a integrátory

Vedle nesporných přínosů v oblasti produktové a podnikové bezpečnosti přináší nasazení požadavků CRA v IT praxi celou řadu zásadních výzev – procesních i technologických.

Z věcného a technického pohledu je jedním z nejzávažnějších problémů řízení dodavatelského řetězce a integrace komponent třetích stran. Výrobci mají povinnost jednat s „náležitou péčí“ (due diligence), pokud do svých systémů integrují cizí kód (včetně open-source).
Pokud integrovaná komponenta obsahuje zranitelnost, odpovědnost padá na výrobce finálního produktu. To pro integrátory znamená masivní zátěž při prověřování cizího kódu a nutnost spoléhat se na SBOM.

Dalším úskalím jsou bezpečnostní aktualizace. Požadavek na oddělení bezpečnostních
a funkčních aktualizací vyžaduje od vývojářů změnu architektury verzování (versioning). Specifický problém nastává v průmyslových (OT/IIoT) a offline prostředích. Zatímco CRA preferuje automatické aktualizace, u systémů s vysokou dostupností (např. řízení výrobních linek, SCADA systémy) by vynucený restart mohl ohrozit provoz nebo bezpečnost osob. Výrobci tedy musí balancovat mezi regulací a reálnou potřebou zákazníka vyhnout se neplánovaným výpadkům.

Z pohledu compliance je kritickou výzvou klasifikace produktů a posuzování shody. Produkty se dělí do tříd (výchozí, důležité třídy I a II, a kritické). Zatímco u „výchozí“ kategorie si výrobce vystačí se sebehodnocením, pro „důležité“ (např. firewally, operační systémy, správci hesel)
a „kritické“ produkty bude nutné zapojit nezávislý audit (prostřednictvím tzv. notified body).
S ohledem na omezené kapacity evropských auditorů hrozí před rokem 2027 obrovský převis poptávky.

Jak se připravit už nyní a role automatizace

AI a automatizace představují zásadní příležitost, jak tuto regulatorní tsunami zvládnout. Efektivita CRA compliance je totiž přímo závislá na digitalizaci procesů.

Organizace by měly začít inventarizací (mapováním) svého portfolia a klasifikací produktů podle kritérií CRA. Prvním krokem k technické shodě je zavedení automatizovaného generování SBOM a integrace nástrojů pro analýzu složení softwaru (SCA) přímo do CI/CD pipeliny. Tím se manuální správa závislostí mění na kontinuální monitoring.

Nezbytností se stane automatizace testování bezpečnosti. Tradiční, jednorázové penetrační testy před vydáním produktu již nebudou stačit. CRA výslovně vyžaduje „účinné a pravidelné testování“ v průběhu celého životního cyklu. Zde se otevírá prostor pro digitalizaci prostřednictvím služeb jako je Pentest as a Service (PtaaS), které umožňují agilní a kontinuální testování odpovídající rychlosti moderního vývoje softwaru. Do procesů je vhodné zapojit také programy typu Bug Bounty pro nepřetržitý crowdsourcovaný test bezpečnosti.

V neposlední řadě automatizace pomůže s řízením životního cyklu hlášení. Nařízení vyžaduje zavedení procesů pro Koordinované zveřejňování zranitelností (CVD) a vytvoření jednotného kontaktního místa (např. v podobě PSIRT týmu nebo VDP programu). Vzhledem k neúprosné 24hodinové lhůtě pro prvotní hlášení závažných incidentů budou systémy pro automatickou detekci, triáž zranitelností a reporting představovat klíčovou konkurenční výhodu.

Konečně, digitalizace a automatizace mohou pomoci i s naplňováním ostatních regulatorních a compliance požadavků. Od robustní dokumentace řádné analýzy rizik a jejich pravidelné aktualizace, přes automatizovaný monitoring bezpečnostní expozice klíčových dodavatelů a jejich produktového portfolia přes přípravu organizace, jejích procesů a evidencí na audit (produktový anebo procesní či bezpečnostní). Silnou doménou dobře navržené a implementované compliance přitom bude integrace požadavků CRA s povinnostmi vyplývajícími z dalších právních a technických regulací, které na výrobce budou dopadat – od kybernetické bezpečnosti a odolnosti organizací, přes ochranu osobních údajů a citlivých dat až po zavádění umělé inteligence. 

Na závěr jednoduché pravidlo

Na rozdíl od předchozích oborových regulací prozatím nezískalo nařízení CRA negativní punc „další zbytečné regulace, která zabíjí evropský průmysl“. Je to patrně proto, že zájem o tuto regulaci teprve začíná a pozornost jí věnují především oborová média a komunitní kanály. Je však zjevné, že výrobci „připojených“ zařízení si sami uvědomují potřebnost aspoň minimálních bezpečnostních standardů, které nadto narovnávají tržní podmínky ve stále náročnějším odvětví.

Co však bude pro výrobce a integrátory nejdůležitější, je nalezení udržitelné rovnováhy mezi inovační rychlostí a produktové compliance. Pokud totiž podnik říká A jako agilita vývoje, musí v éře CRA současně říci i B jako bezpečnost produktu („by design“ i „by default“), C jako compliance procesy, D jako due diligence v dodavatelském řetězci a E jako evidence (např. skrze softwarový kusovník). To (a efektivní automatizace) bude určovat, zda se CRA stane pro podnik tržní brzdou, nebo naopak silným prodejním argumentem v podobě objektivně prokazatelné kybernetické odolnosti. (18.9.2026)