Zranitelnost v cizí knihovně: povinnost dle čl. 13 CRA

Vaše vývojářka narazí při rutinní kontrole na hlášenou zranitelnost v knihovně, kterou váš produkt s digitálními prvky používá pro zpracování obrazu nebo síťovou komunikaci. Knihovna je open-source, udržuje ji cizí komunita na GitHubu, vy jste ji jen zabudovali do svého firmwaru. Co přesně vám v tu chvíli Cyber Resilience Act (nařízení EU 2024/2847) ukládá – a co ne?

Tento článek se drží jedné konkrétní otázky: povinnosti podle čl. 13 odst. 6, která nastupuje ve chvíli, kdy chybu v cizí komponentě objevíte vy jako výrobce. Nejde o hlášení ENISA ani o žádnou hodinovou lhůtu – to je jiná povinnost, které se věnuje samostatný text. Tady jde o to, koho musíte informovat, co musíte udělat a co s vaším případným opravným kódem.

Jde o obecnou informaci, ne o individuální právní radu pro váš konkrétní produkt.

Povinnost podle čl. 13 odst. 6: tři kroky, které musíte udělat

Nařízení v čl. 13 odst. 6 stanovuje, že po zjištění zranitelnosti v komponentě začleněné do produktu – včetně komponenty s otevřeným zdrojovým kódem – musí výrobce udělat tři věci:

1. Oznámit zranitelnost tomu, kdo komponentu vyrábí nebo udržuje (výrobci komponenty, nebo u open-source projektu jeho správci či maintainerovi).
2. Zranitelnost řešit – nespokojit se s tím, že ji jen nahlásíte, ale zajistit její odstranění ve vlastním produktu.
3. Pokud v rámci řešení vyvinete opravu, předat ji tomu, kdo komponentu vyrábí nebo udržuje, a to jako kód nebo jako dokumentaci.

Formulace je nepodmíněná – nestojí tam „v příslušných případech“ ani „na základě posouzení rizika“, jak je tomu u některých jiných povinností nařízení. Pokud zranitelnost v cizí komponentě zjistíte, všechny tři kroky platí bez výjimky, jakmile na váš produkt CRA dopadá.

Příklad z praxe

Prodáváte chytrou kameru pro domácí monitoring – zboží, které prováděcí nařízení (EU) 2025/2392 řadí mezi produkty s digitálními prvky s bezpečnostní funkcí. Firmware kamery obsahuje open-source knihovnu pro zpracování videa. Vaše bezpečnostní studie odhalí, že knihovna obsahuje zranitelnost umožňující neoprávněný přístup k datovému proudu. Postup podle čl. 13 odst. 6: napíšete správci knihovny (typicky přes jeho bezpečnostní kontakt na GitHubu), zároveň zranitelnost opravíte ve vlastním produktu – ať už úpravou konfigurace, nebo záplatou – a pokud jste záplatu vyvinuli sami, poskytnete ji správci knihovny jako kód nebo jako popis řešení.

Kdo je „výrobce“ a co je „komponenta“ v tomto vztahu

Povinnost z čl. 13 odst. 6 dopadá na výrobce produktu s digitálními prvky, ne na každého v obchodním řetězci. Komponentou je zde jakákoli součást – softwarová knihovna, modul, firmware třetí strany – kterou jste do svého produktu začlenili. Nezáleží na tom, zda jste ji koupili licenčně, nebo použili zdarma jako open-source.

Klíčové je, že povinnost neznamená pouze technickou opravu u sebe. Nařízení výslovně požaduje komunikaci směrem k tvůrci komponenty – tedy zpětnou vazbu do řetězce, ne jen záplatu ve vašem produktu. To je rozdíl, který si řada výrobců plete: oprava „u sebe“ bez oznámení autorovi komponenty povinnost nesplňuje.

Otevřený zdrojový kód: knihovna zdarma, povinnost ne

Samotný nezpeněžený open-source software stojí mimo působnost CRA – jeho tvůrce ani „správce open-source softwaru“ (typicky nadace nebo komunitní organizace) nemusí řešit CE ani se obávat pokut podle čl. 64 odst. 10. Tento lehký režim se ale vztahuje na toho, kdo komponentu jako open-source udržuje, ne na vás jako výrobce, který ji zabudoval do komerčního produktu s digitálními prvky.

Jinými slovy: skutečnost, že knihovna je zdarma, nemění nic na tom, že vy jako výrobce hotového produktu nesete plnou povinnost podle čl. 13 – včetně odstavce 6. Čl. 13 odst. 6 to potvrzuje přímo tím, že komponentu s otevřeným zdrojovým kódem uvádí na stejnou úroveň jako komerční komponentu.

Kam se obrátit, když maintainer neodpovídá

Nařízení neukládá výsledek (že komunita zranitelnost skutečně opraví), ale postup na vaší straně – oznámit, řešit u sebe, předat případnou opravu. Pokud správce komponenty na oznámení nereaguje, vaše povinnost vůči vlastnímu produktu (bod 2 – zranitelnost řešit) tím není dotčena: musíte ji vyřešit i bez součinnosti autora, byť třeba dočasným opatřením na vaší straně, než dorazí oficiální oprava.

Jak zranitelnost v cizí knihovně vůbec zjistíte: role SBOM

Abyste vůbec věděli, že určitá knihovna je součástí vašeho produktu, potřebujete přehled o tom, co všechno je v produktu zabudováno. K tomu slouží strojově čitelný SBOM (softwarový kusovník), který příloha I část II ukládá jako součást správy zranitelností spolu s politikou koordinovaného zveřejňování (CVD) a kontaktním místem pro hlášení. SBOM sám o sobě zjištění chyby nezaručí, ale bez něj nevíte, které komponenty a v jaké verzi váš produkt obsahuje – a tedy ani koho v případě zranitelnosti kontaktovat.

Zveřejnění SBOM směrem k uživatelům produktu není povinné automaticky – teprve pokud se výrobce rozhodne SBOM uživatelům zpřístupnit, musí v pokynech uvést, kde k němu lze získat přístup. Detailům SBOM a CVD se věnuje samostatný text; zde je důležité jen to, že bez interního přehledu komponent nemáte šanci povinnost podle čl. 13 odst. 6 vůbec splnit.

Dovozce a distributor: jiná povinnost, jiný adresát

Pokud produkt s digitálními prvky pouze dovážíte nebo distribuujete, aniž byste jej vyráběli, čl. 13 odst. 6 na vás nedopadá přímo. Pro vás platí jiné ustanovení: dovozce podle čl. 19 odst. 5 a distributor podle čl. 20 odst. 4 musí po zjištění zranitelnosti produktu bez zbytečného odkladu informovat výrobce, a pokud produkt představuje významné kybernetické bezpečnostní riziko, navíc neprodleně informovat orgány dozoru nad trhem v zemích, kam produkt dodali.

To je zásadní rozdíl v adresátovi povinnosti: výrobce řeší vztah s tvůrcem komponenty, dovozce a distributor řeší vztah s výrobcem produktu a případně s dozorovým orgánem – nikoli s autorem knihovny, o jehož existenci ani nemusí vědět.

Kdy se z distributora stává výrobce

Pozor na dvě situace, kdy se role posouvá. Pokud dovozce nebo distributor uvede produkt na trh pod svým jménem nebo ochrannou známkou (private label), je podle čl. 21 považován za výrobce a vztahují se na něj i povinnosti čl. 13 a 14 – tedy i čl. 13 odst. 6. Totéž platí i pro jakoukoli jinou osobu mimo výrobce, dovozce či distributora, která produkt podstatně změní a dodá na trh (čl. 22) – tam ale povinnost dopadá jen na tu část produktu, kterou změna zasáhla, případně na celý produkt, pokud změna ovlivnila jeho kybernetickou bezpečnost jako celek.

Co platí najisto od kdy

Čl. 13 odst. 6 patří mezi hlavní povinnosti CRA. Podle čl. 71 odst. 2 se nařízení jako celek (mimo samostatných výjimek pro čl. 14 a kapitolu IV) použije od 11. prosince 2027. To je datum, od kterého tato konkrétní povinnost nastupuje pro produkty nově uváděné na trh.

Pro produkty, které byly na trh uvedeny před 11. prosincem 2027, platí zvláštní pravidlo: požadavky CRA – včetně čl. 13 odst. 6 – se na ně vztahují jen tehdy, pokud po tomto datu projdou podstatnou změnou (čl. 69 odst. 2). Podstatnou změnou se rozumí změna produktu po jeho uvedení na trh, která ovlivňuje soulad se základními požadavky přílohy I části I, nebo která vede ke změně zamýšleného účelu, pro nějž bylo provedeno posouzení (čl. 3 bod 30). Pouhá aktualizace software bez zásahu do těchto oblastí není automaticky podstatnou změnou.

Povinnost dovozce a distributora informovat výrobce, resp. orgány dozoru (čl. 19 odst. 5, čl. 20 odst. 4), spadá do stejného rámce hlavních povinností a použije se od stejného data – pokud pro ni nařízení nestanoví jinou výjimku, jako je tomu u čl. 14 nebo kapitoly IV.

Co teprve upřesní prováděcí akty (výhled)

Český adaptační zákon, který stanoví, který orgán bude v ČR příslušný pro dozor a komu budete v praxi hlásit informace pro orgány dozoru nad trhem, byl k 10. srpnu 2026 ve stavu návrhu procházejícího mezirezortním připomínkovým řízením. Návrh počítá s dozorem České obchodní inspekce nad naprostou většinou trhu a s Národním úřadem pro kybernetickou a informační bezpečnost jako oznamujícím orgánem, ale finální znění se ještě může změnit – před tím, než budete muset orgán skutečně kontaktovat, si aktuální stav ověřte u zdroje.

Sankce za nesplnění povinnosti

Porušení povinnosti podle čl. 13 – kam spadá i odstavec 6 – a čl. 14 spadá do nejpřísnějšího sankčního pásma, jaké CRA zná: podle čl. 64 odst. 2 hrozí pokuta až do výše 15 000 000 EUR, nebo – je-li to pro postih výhodnější – odpovídající procentní podíl z celosvětového ročního obratu, podle toho, která hodnota je vyšší; přesnou sazbu v procentech najdete přímo v čl. 64 odst. 2. Toto pásmo je přísnější než pásmo pro ostatní role a přestupky.

Mikropodniky a malé podniky mají výjimku jen z pokut za zmeškání 24hodinových lhůt hlášení podle čl. 14 – tato výjimka se netýká povinnosti oznámit a řešit zranitelnost komponenty podle čl. 13 odst. 6, protože tam žádná hodinová lhůta neexistuje a výjimka na ni tedy nedopadá.

Pokud tuto povinnost poruší dovozce nebo distributor (čl. 19 odst. 5, čl. 20 odst. 4), spadá jejich prohřešek do nižšího pásma podle čl. 64 odst. 3 – do 10 000 000 EUR nebo 2 % z celosvětového obratu – nikoli do pásma pro výrobce.

Akční plán 30/60/90 dní

1. Do 30 dní: Zmapujte, které vaše produkty s digitálními prvky obsahují cizí komponenty, včetně open-source knihoven. Pokud ještě nemáte strojově čitelný SBOM, začněte jej sestavovat alespoň pro produkty, které plánujete uvádět na trh po 11. prosinci 2027 nebo u kterých očekáváte podstatnou změnu po tomto datu.
2. Do 60 dní: Vytvořte interní postup pro situaci „zjistili jsme zranitelnost v cizí komponentě“: kdo kontaktuje výrobce nebo správce komponenty, jak se dokumentuje řešení u vás a jak se předává případný vyvinutý fix jako kód nebo dokumentace. Ujistěte se, že máte funkční kontaktní místo, na které mohou reagovat i externí hlasatelé zranitelnosti.
3. Do 90 dní: Ujasněte si smluvně i organizačně, kdo ve vašem odbytovém řetězci je dovozce a kdo distributor, a nastavte, aby v případě zjištění zranitelnosti bez zbytečného odkladu informovali vás jako výrobce. Zvlášť ošetřete situace private label a podstatných změn produktu třetí stranou, kde se role výrobce může přesunout. Průběžně sledujte stav českého adaptačního zákona, který určí příslušný orgán dozoru.

Pokud si nejste jistí, kam vaše role a produkt v této skládačce zapadají, nechte si to ověřit formou rychlé prověrky – ukáže vám, které povinnosti se vás reálně týkají a od kdy.

Časté omyly

„Zjistil jsem chybu v knihovně, tak to musím do 24 hodin nahlásit ENISA.“ Není to tak. Hodinové lhůty podle čl. 14 se vážou na aktivně zneužívanou zranitelnost nebo závažný incident, ne na každou objevenou chybu. Prosté zjištění zranitelnosti v komponentě zakládá jinou povinnost – oznámit ji tvůrci komponenty, vyřešit ji u sebe a případný fix předat dál.

„Knihovna je open-source a zadarmo, CRA se mě netýká.“ Netýká se to tvůrce nezpeněženého open-source projektu – ten má lehký režim bez CE a bez pokut. Vás jako výrobce produktu s digitálními prvky, který tuto knihovnu komerčně využívá, se to týká plně, včetně povinnosti oznámit zranitelnost jejímu správci.

„Stačí, že to opravím u sebe, dál to neřeším.“ Nařízení požaduje i zpětnou komunikaci: oznámení tvůrci nebo správci komponenty a předání případné vyvinuté opravy jako kódu nebo dokumentace. Oprava jen ve vašem produktu bez tohoto kroku povinnost nenaplňuje.

Zdroje

• Nařízení (EU) 2024/2847 (Cyber Resilience Act), konsolidované znění, čl. 3 body 30 a 42, čl. 13 odst. 6, čl. 19 odst. 5, čl. 20 odst. 4, čl. 21, čl. 22, čl. 64, čl. 69 odst. 2, čl. 71 odst. 2 – CELEX 02024R2847-20241120: https://publications.europa.eu/resource/celex/02024R2847-20241120
• Nařízení (EU) 2024/2847, čl. 24, čl. 64 odst. 10, přílohy I a III – CELEX 32024R2847: https://publications.europa.eu/resource/celex/32024R2847
• Návrh zákona o požadavcích na kybernetickou bezpečnost výrobků s digitálními prvky, MPO, mezirezortní připomínkové řízení (VeKLEP): https://mpo.gov.cz/cz/ochrana-spotrebitele/aktualni-informace/navrh-zakona-o-pozadavcich-na-kybernetickou-bezpecnost-vyrobku-s-digitalnimi-prvky--293815/

Shrnutí

Zjistíte-li jako výrobce zranitelnost v komponentě zabudované do svého produktu s digitálními prvky – ať je komerční, nebo open-source – čl. 13 odst. 6 CRA vám ukládá tři konkrétní kroky: oznámit ji tomu, kdo komponentu vyrábí nebo udržuje, zranitelnost u sebe vyřešit a případnou vyvinutou opravu předat dál jako kód nebo dokumentaci. Tato povinnost je součástí hlavních povinností CRA s použitelností od 11. prosince 2027, u starších produktů nastupuje jen při jejich podstatné změně po tomto datu. Nejde o hlášení ENISA podle čl. 14 – to se řeší jen u aktivně zneužívaných zranitelností. Pokud jste jen dovozce nebo distributor, vaší povinností je informovat výrobce a v případě významného rizika i orgány dozoru; plná povinnost výrobce vás postihne jen při prodeji pod vlastní značkou nebo při podstatné změně produktu. Porušení povinnosti podle čl. 13 odst. 6 spadá do nejpřísnějšího sankčního pásma CRA, bez výjimky pro malé podniky.