Akt o kybernetické odolnosti: začleňte povinnosti do vývoje produktů

Akt o kybernetické odolnosti (Cyber Resilience Act, CRA) vnáší povinnosti v oblasti kybernetické bezpečnosti do životního cyklu dotčených produktů s digitálními prvky. Pro CTO je praktickým úkolem propojit to, co inženýři vyvíjejí, dodávají a udržují, s důkazy potřebnými k prokázání plnění těchto povinností.

Toto propojení musí fungovat na úrovni produktu a verze. Celofiremní bezpečnostní politika nevysvětluje, zda konkrétní vydání má bezpečné výchozí nastavení, jaké závislosti obsahuje nebo jak zákazníci obdrží bezpečnostní aktualizaci. Tiket se zranitelností označený jako „opraveno“ neurčuje, které podporované verze zůstávají zranitelné.

Užitečným výchozím bodem je proto model životního cyklu produktu: rozsah, bezpečnostní požadavky, důkazy o vydání, zvládání zranitelností, závazky podpory a odpovědná rozhodnutí. Tento model zabudujte do vývoje, místo abyste ho skládali odděleně před posouzením.

Před přiřazením opatření vymezte hranici produktu

CRA se týká produktů s digitálními prvky spadajících do jeho působnosti, včetně dotčeného hardwaru a softwaru. Není to univerzální pravidlo pro každou službu SaaS. Hostovaná služba a software distribuovaný zákazníkům mohou vyžadovat odlišné analýzy a prověřit je třeba i vzdálené zpracování, které je nedílnou součástí produktu.

Jako výchozí referenci použijte pokyny Evropské komise k CRA a poté vyřešte právní otázky specifické pro produkt. Závěr zaznamenejte, místo abyste spoléhali na neformální předpoklad týmu.

U každého zvažovaného produktu určete:

• Co zákazníci dostávají: hardware, instalovaný software, stahovatelné komponenty nebo jejich kombinaci.
• Které funkce vzdáleného zpracování jsou nezbytné k tomu, aby produkt plnil své funkce.
• Jak se produkt dodává na trh EU a který subjekt ho dodává.
• Vaši roli hospodářského subjektu: výrobce, dovozce, distributor nebo jiná relevantní role.
• Použitelné výjimky, předpisy specifické pro produkt a aspekty open source.
• Kategorii produktu a z ní vyplývající požadavky na posuzování shody.

Open source vyžaduje zvláštní péči. Zacházení se softwarem dodávaným mimo obchodní činnost neznamená, že obchodní výrobce může ignorovat open-source komponenty zabudované do svého produktu. Rozlišujte postavení přispěvatele v upstreamu od své odpovědnosti za produkt, který dodáváte.

Inženýrským výstupem by měl být stručný záznam o rozsahu s diagramem architektury, identifikátory produktu, relevantními obchodními subjekty, předpoklady a schváleným závěrem. Uveďte osobu odpovědnou za opětovné otevření tohoto závěru, když se změní funkce nebo distribuce.

Například stahovatelná aplikace pro správu a její hostovaná analytická služba by neměly automaticky dostat jedno nerozlišené rozhodnutí o rozsahu. Určete, které funkce běží lokálně, které závisejí na službě a zda toto vzdálené zpracování patří do hranice produktu. Toto rozlišení ovlivňuje posouzení rizik, záznamy o závislostech a vlastnictví incidentů.

Vycházejte z aktuálních termínů použitelnosti

Komise uvádí 11. září 2026 pro povinnosti hlášení a 11. prosince 2027 pro hlavní požadavky CRA. K 7. říjnu 2026 již termín pro hlášení uplynul. Připravenost na hlášení považujte za aktuální provozní požadavek, ne za úkol odložený až na přípravu na posouzení shody.

Udržujte viditelné dvě pracovní linie:

Produkty dodané před hlavním datem použitelnosti vyžadují pozornost k přechodným ustanovením a podstatným změnám. Nepředpokládejte, že starší produkt není pro hlášení relevantní jen proto, že jeho původní vydání předcházelo prosinci 2027.

Udržujte datovaný registr právních požadavků. U prahových hodnot událostí, postupných lhůt pro hlášení, příjemců a postupů podání ověřujte aktuální právní text a oficiální pokyny k provádění. Nenahrazujte proces specifický pro CRA obecnou šablonou reakce na incidenty.

Převeďte bezpečnostní požadavky na kritéria návrhu a vydání

Základní požadavky CRA pokrývají bezpečnostní vlastnosti produktu a zvládání zranitelností. Jejich implementace by měla vycházet z posouzení kybernetických rizik produktu, nikoli z univerzálního kontrolního seznamu použitého bez architektonického kontextu.

Začněte tím, jak může produkt způsobit škodu. Popište uživatele, prostředí nasazení, exponovaná rozhraní, privilegované operace, citlivá data a předvídatelné zneužití. Zahrňte provozní předpoklady zákazníka: zařízení nasazené v průmyslové síti má jinou expozici a jiná omezení obnovy než desktopový nástroj.

Tuto práci může podpořit praktické cvičení modelování hrozeb; pokyny OWASP k modelování hrozeb nabízejí zavedený přístup. Výstup by měl propojit hrozby s konkrétními požadavky, rozhodnutími o implementaci a testy.

Podívejte se, jak se známé požadavky stávají testovatelnými:

Jde o praktické příklady implementace, nikoli o náhradu příslušných požadavků. Relevanci a dostatečnost určete prostřednictvím posouzení rizik.

Přidejte bezpečnostní kritéria přijetí do práce na funkcích. Nové administrativní API by mělo přicházet s rozhodnutími o autentizaci, autorizaci, zpracování vstupů a logování – ne se slibem, že ho bezpečnost prověří později. Model hrozeb přehodnoťte při přidání vzdáleného rozhraní, privilegované komponenty nebo nové hranice důvěry.

Schválení vydání by mělo identifikovat nevyřešené zranitelnosti, jejich zneužitelnost, dotčené konfigurace a ošetření. Uplatněte požadavek CRA, aby byly produkty dodávány na trh bez známých zneužitelných zranitelností, s přihlédnutím k posouzení rizik a příslušným základním požadavkům; zaznamenání nebo akceptace rizika sama o sobě tento požadavek nesplňuje. Samotný výsledek skeneru toto rozhodnutí učinit nemůže: záleží na dosažitelnosti, předpokladech a chování produktu. Naopak nízké číselné skóre závažnosti není dostatečným důvodem k přehlížení zranitelnosti, která má ve vašem modelu nasazení závažné důsledky.

Záznam o vydání by měl propojit schválenou revizi zdrojového kódu, artefakt sestavení, inventář závislostí, výsledky testů a bezpečnostní rozhodnutí. Díky tomu je posouzení reprodukovatelné, když se zákazník nebo orgán později zeptá na konkrétní verzi.

Učiňte náležitou péči o komponenty součástí procesu sestavení

Komponenty třetích stran vytvářejí povinnosti, které nelze splnit přeposláním bezpečnostního upozornění z upstreamu. Musíte rozumět tomu, co jste dodali, zda je to dotčeno a jak to můžete napravit.

CRA zahrnuje mezi požadavky na zvládání zranitelností požadavek na softwarový kusovník (SBOM): v běžně používaném strojově čitelném formátu, který pokrývá alespoň závislosti nejvyšší úrovně. Praktické doporučení: zachycujte hlubší informace o závislostech všude, kde vaše nástroje pro sestavení dokážou poskytnout spolehlivé výsledky. Expozici často určují tranzitivní závislosti.

SBOM je užitečný jen tehdy, když odpovídá skutečnému artefaktu produktu. Přiřaďte ho k identifikátoru vydání a sestavení a rozlišujte dodávané komponenty od nástrojů používaných pouze při vývoji. Kde je to relevantní, zahrňte firmware, balíčky operačního systému, přibalené knihovny a komerční komponenty; export ze správce balíčků může několik z nich minout.

Přezkum komponent stavějte na otázkách, které mění inženýrská rozhodnutí:

• Je komponenta udržovaná a je její podporovaná životnost slučitelná s naší?
• Dokážeme rychle získat informace o zranitelnostech a bezpečnostní aktualizace?
• Máme přístup ke zdrojovému kódu, cestu k opravám od dodavatele nebo strategii náhrady?
• Přináší komponenta privilegované spouštění nebo nové externí spojení?
• Lze produkt nadále udržovat, pokud dodavatel přestane komponentu podporovat?

U komerčních komponent by měl nákup zajistit bezpečnostní kontakty, ujednání o oznamování a přístup k opravám. Načasování dodavatele musí ponechat prostor pro vaše vlastní posouzení a povinnosti hlášení. Výrobce produktu přesto potřebuje interní eskalační cestu pro případ, že odpověď dodavatele je neúplná.

U open-source závislostí uchovávejte informace o původu a realistický plán údržby. Veřejná dostupnost repozitáře není důkazem, že někdo během vaší doby podpory vytvoří kompatibilní opravu.

Navrhněte dobu podpory a mechanismus aktualizací společně

Podpora je inženýrský závazek s obchodními důsledky. CRA obecně vyžaduje dobu podpory nejméně pět let, pokud není očekávaná doba používání produktu kratší. Příslušnou dobu určete podle kritérií nařízení, místo abyste volili libovolné datum tak, aby odpovídalo roadmapě.

Zaznamenejte zdůvodnění, sdělte zákazníkům požadované informace o podpoře a propojte je s udržovanými verzemi produktu. Závazek podpory musí zohledňovat schopnost dodávat bezpečnostní aktualizace, ne jen zachovat adresu helpdesku.

Než schválíte plán podpory produktu, zeptejte se, zda dokážete:

• Znovu sestavit starší podporované větve s udržovanými nástroji.
• Bezpečně vytvářet, autentizovat a distribuovat bezpečnostní aktualizace.
• Testovat opravy napříč podporovaným hardwarem a konfiguracemi nasazení.
• Spravovat podpisové klíče a bezpečně se zotavit z jejich kompromitace.
• Udržovat dostupné aktualizace a bezpečnostní informace pro zákazníky.
• Řešit závislosti, jejichž podpora v upstreamu končí dříve než vaše.

Bezpečnostní aktualizace se během doby podpory zpravidla poskytují bezplatně, s výhradou ustanovení nařízení. Každá bezpečnostní aktualizace vydaná během této doby musí zůstat dostupná nejméně deset let od vydání nebo po zbytek doby podpory, podle toho, co je delší. Bezpečnostní opravy plánujte odděleně od vývoje funkcí, aby zákazníci nebyli zbytečně nuceni přijímat nesouvisející funkční změny.

Testujte víc než jen bezproblémový průběh. Přerušená instalace, nedostatek úložného prostoru, prošlé přihlašovací údaje a neúspěšné ověření mohou z platné opravy udělat problém dostupnosti. Rozhodněte, jaké mechanismy obnovy profil rizik produktu vyžaduje.

Na konci podpory by se komunikace se zákazníky a interní záznamy měly shodovat. Nenechávejte stránku ke stažení naznačovat pokračující bezpečnostní údržbu, když registr produktů uvádí, že závazek skončil.

Vytvořte runbook pro hlášení, který obstojí i v nejistotě

Běžné zjištění zranitelnosti, aktivně zneužívaná zranitelnost a závažný bezpečnostní incident nejsou zaměnitelné. Proces hlášení podle CRA potřebuje zdokumentované posouzení příslušného spouštěče – ne automatické hlášení každého upozornění skeneru a ne automatické odmítnutí čehokoli bez dokončeného forenzního vyšetřování.

Runbook by měl začínat příjmem. Výzkumníci, zákaznická podpora, dodavatelé a inženýrské týmy potřebují známou cestu k funkci bezpečnosti produktů. Uchovejte původní hlášení a zaznamenejte, kdy se relevantní informace staly známými; neresetujte časová razítka zjištění, když tiket přejde k jinému týmu.

U potenciálně hlášených událostí shromážděte:

• Identifikátory produktu a dotčené podporované verze.
• Důkazy o zneužití nebo dopadu incidentu, s mírou jistoty a nejistotami.
• Známé podmínky útoku, dotčené funkce a předpoklady nasazení.
• Dostupná zmírňující opatření a stav nápravných opatření.
• Posouzení spouštěče, vlastníka hlášení a výpočty příslušných lhůt.
• Podaná oznámení, potvrzení o přijetí, následné aktualizace a komunikaci se zákazníky.

Postupné lhůty pro oznámení, požadavky na závěrečnou zprávu, příjemce a aktuální postup hlášení ověřujte v oficiálních zdrojích. Aktivně zneužívané zranitelnosti a závažné incidenty mají odlišné náležitosti hlášení; jedno zkopírované pole s lhůtou nestačí.

Určete primárního vlastníka hlášení a zástupce s pravomocí koordinovat inženýrskou, právní a zákaznickou komunikaci. Přístup k příslušnému mechanismu hlášení si zajistěte předem. Právní přezkum by měl být k dispozici v rámci lhůty pro hlášení, místo aby se stal neomezenou frontou na schválení.

Proces procvičujte s neúplnými informacemi. Užitečný nácvik začíná věrohodným hlášením o zneužití, nejistým seznamem dotčených verzí a nedostupným dodavatelem komponenty. Tým by měl být schopen učinit včasné, zdokumentované rozhodnutí o hlášení, zatímco vyšetřování pokračuje.

Hlášení podle CRA nenahrazuje jiné platné povinnosti. Událost týkající se produktu může vyžadovat i posouzení podle práva na ochranu osobních údajů nebo podle smlouvy se zákazníkem. Tato posouzení koordinujte, ale zachovejte jejich samostatné spouštěče, příjemce a záznamy o rozhodnutí.

Před volbou plánu posouzení potvrďte klasifikaci

Klasifikace produktu ovlivňuje dostupný postup posuzování shody. Nepředpokládejte, že každý připojený produkt potřebuje stejné externí posouzení nebo že se každý výrobce může spolehnout na interní posouzení.

Příslušnou kategorii určete podle funkcí produktu a definic a příloh nařízení. Poté potvrďte přípustný postup, včetně případných podmínek týkajících se harmonizovaných norem, uznaných specifikací, certifikačních schémat nebo posouzení třetí stranou.

Plánování norem potřebuje výslovný registr závislostí: které reference jsou použitelné, jaký je jejich aktuální stav a co se změní, pokud očekávaný postup nebude k dispozici. Nezakládejte plán vydání na nepotvrzeném předpokladu o normách nebo kapacitě pro posuzování.

Klasifikaci přehodnoťte, když se změní funkce. Přidání schopností pro správu bezpečnosti nebo řízení sítě může analýzu ovlivnit, ale samotný název funkce kategorii neurčuje. Posuďte skutečnou funkci a závěr zdokumentujte.

Udržujte klasifikaci, zvolený postup a výstupy posouzení shody propojené s technickou dokumentací. Označení CE a EU prohlášení o shodě se musí řídit příslušným postupem; nejsou náhradou za implementaci podkladových požadavků.

Udržujte balíček důkazů, který dokáže vysvětlit vydání

Technická dokumentace by měla popisovat produkt i úvahy, na nichž stojí jeho bezpečnostní rozhodnutí. Při změnách produktu uchovávejte posouzení rizik a dokumentaci a na příslušné záznamy uplatňujte zákonné požadavky na uchovávání.

Užitečný balíček důkazů o produktu zahrnuje rozhodnutí o rozsahu, architekturu, posouzení rizik, bezpečnostní požadavky, informace o komponentách, výsledky ověření, postupy zvládání zranitelností, zdůvodnění podpory a záznamy o shodě. Každá položka potřebuje vlastníka a identifikovatelnou verzi.

K propojení těchto záznamů používejte stabilní identifikátory. Záznam o zranitelnosti by měl vysvětlit dotčené verze, expozici, ošetření, vydání a požadovanou komunikaci. „Opraveno“ bez kontextu verze ponechává důkazy o produktu neúplné.

Stávající procesy ISMS mohou poskytnout užitečné důkazy v oblasti řízení, dodavatelů a bezpečného vývoje. ISO 27001 se však týká systému řízení bezpečnosti informací s vymezeným rozsahem; certifikace neprokazuje shodu jednotlivého produktu s CRA. Relevantní důkazy využijte znovu, aniž byste mapování rámců považovali za právní rovnocennost.

Modelový příklad: chyba v závislosti podporovaného zařízení

Uvažujme ilustrativního výrobce, který v EU dodává síťově připojené zařízení. Předpokládejme, že jeho rozsah a klasifikace byly přezkoumány, dvě větve vydání zůstávají podporované a o přibalené knihovně se uvádí, že je jinde aktivně zneužívána.

Prvním úkolem není uzavřít upozornění z upstreamu. Inženýři zjistí, která sestavení zařízení obsahují zranitelnou knihovnu a zda je dotčená funkce dosažitelná. SBOM naznačuje, že ji obsahují obě větve, ale analýza konfigurace ukazuje odlišnou expozici. Toto rozlišení se zaznamená spolu s podpůrnými důkazy.

Vlastník bezpečnosti produktu poté vyhodnotí, zda dostupná fakta splňují příslušný spouštěč hlášení podle CRA. Nejistota ohledně jedné konfigurace nasazení se zaznamená; neospravedlňuje ponechání vlastníka rozhodnutí nejmenovaného. Runbook pro hlášení poskytuje aktuální fáze oznamování a postup.

Inženýři vyvinou dočasné zmírňující opatření a opravené sestavení pro každou dotčenou větev. Testy pokrývají zranitelnou cestu, běžný provoz a instalaci autentizované aktualizace. Pokud jedna větev nemůže použít opravu z upstreamu, tým zaznamená její alternativní ošetření a zbytkové riziko, místo aby celý produkt označil za opravený.

Komunikace se zákazníky identifikuje dotčené verze, okamžitá ochranná opatření a způsob získání aktualizace. Načasování zveřejnění se koordinuje s příslušnými požadavky na zvládání zranitelností a případnými odůvodněnými bezpečnostními hledisky.

Dokončený záznam propojuje upozornění, analýzu dotčených sestavení, rozhodnutí o hlášení, podání tam, kde jsou vyžadována, commity s opravou, výsledky testů, artefakty vydání a komunikaci. Posuzovatel nyní dokáže zrekonstruovat inženýrskou reakci i rozhodnutí v oblasti compliance.

Začněte jedním produktem a jedním úplným řetězcem důkazů

Vyberte reprezentativní podporovaný produkt a sledujte jedno nedávné vydání a jednu zranitelnost napříč životním cyklem. Chybějící vazby na verze, nejasné závazky podpory a nedostupné postupy hlášení se rychle ukážou. Každou mezeru proměňte v úkol s vlastníkem a poté model rozšiřte na celé portfolio.

Secani může tento pracovní postup s důkazy podpořit propojením požadavků, důkazů, vlastníků, úkolů a rozhodnutí z přezkumů. Inženýrské nástroje zůstávají provozními zdroji pro sestavení, vydání a zranitelnosti; pracovní prostor compliance tyto záznamy vztahuje k příslušné povinnosti. U mapování a závěrů ponechte lidské schválení výslovné a při používání konceptů s podporou AI zachovejte dohledatelnost zdrojů.

Bezprostředním dalším krokem je otestovat runbook pro hlášení. Souběžně vyžadujte, aby příští vydání produktu neslo propojené rozhodnutí o rozsahu, aktuální posouzení rizik, inventář komponent a bezpečnostní schválení. Tím vznikne opakovatelná inženýrská praxe, zatímco příprava na posouzení shody pokračuje.