Cyber Resilience Act mění pohled na bezpečnost výrobků. Nestačí znát zranitelnou knihovnu. Výrobce musí vědět, kterých produktů, verzí a konfigurací se skutečně týká.
Moderní výrobky už dávno nejsou jen mechanická sestava, elektro část a technická dokumentace. Stále častěji obsahují firmware, knihovny třetích stran, embedded software, komunikační rozhraní nebo napojení na cloudové služby.
To, co dříve řešilo hlavně IT, se proto stále více přesouvá přímo do vývoje výrobku.
Výrobce už nebude potřebovat vědět jen to, zda má ve svém softwaru zranitelnou komponentu. Bude muset vědět také to, ve kterém výrobku se nachází, v jaké revizi, v jaké zákaznické variantě, v jaké uvolněné konfiguraci a kterých dodaných kusů se může týkat.
Právě tady začíná být SBOM důležitý. A právě tady zároveň přestává stačit.
CRA zkracuje čas na odpověď
Cyber Resilience Act, tedy nařízení EU 2024/2847, se týká výrobků s digitálními prvky uváděných na trh EU. Hlavní povinnosti se začnou uplatňovat od 11. prosince 2027, ale oznamovací povinnosti přicházejí dříve. Od 11. září 2026 budou výrobci povinni hlásit aktivně zneužívané zranitelnosti a závažné incidenty s dopadem na bezpečnost produktu; včasné varování má být podáno do 24 hodin a úplné oznámení do 72 hodin.
To je v praxi velmi krátký čas.
Pokud se výrobce o zranitelnosti dozví v pátek odpoledne, nemůže začít ručně zjišťovat, kde všude se daná knihovna nebo softwarová komponenta použila. Potřebuje rychle určit, zda se problém týká jeho výrobků, kterých verzí, jakých konfigurací a jakých zákazníků.
Bez propojených produktových dat se z bezpečnostního signálu stává časově kritické pátrání.
Bezpečnostní problém je ve skutečnosti produktová otázka
Představme si běžnou situaci. Dodavatel softwarové knihovny oznámí zranitelnost. Technicky je problém známý: existuje konkrétní komponenta, verze, popis rizika a doporučené opatření.
Výrobce ale musí odpovědět na jiné otázky.
Je tato knihovna součástí některého firmware? V jaké hardwarové revizi? U kterého výrobku? V jaké zákaznické variantě? Byla tato verze skutečně uvolněna do výroby, nebo zůstala jen ve vývoji? Které dodané konfigurace mohou být dotčené? A kdo rozhodne, zda výrobek zasažen je, nebo není?
Problém obvykle nebývá v tom, že by společnost neměla žádná data. Problém je v tom, že tato data nejsou propojená. Analýza rizik může být v tabulce, architektura v systémovém modelu, kód v repozitáři, kusovník v PLM a servisní data jinde. Každý záznam může být správný, ale pokud mezi nimi nejsou řízené vazby, nelze z nich v časovém tlaku sestavit spolehlivou odpověď.
A právě v tom je zásadní rozdíl mezi tím, že společnost „někde má data“, a tím, že dokáže nad daty rychle udělat obhajitelné rozhodnutí.
SBOM je základ. Ale ne celá odpověď.
SBOM, tedy Software Bill of Materials, je softwarový kusovník. Poskytuje strukturovaný přehled použitých softwarových komponent a jejich verzí. Je to důležitý základ pro práci se zranitelnostmi, protože pomáhá určit, co je uvnitř softwaru.
Jenže u fyzického výrobku je potřeba jít dál.
SBOM může říct, že určitá knihovna existuje v konkrétním softwarovém sestavení. Neřekne ale sám o sobě, kde přesně toto sestavení žije ve fyzickém výrobku, v jaké revizi, v jaké konfiguraci a s jakou platností.
Jinými slovy: SBOM pomáhá zjistit, co je v softwaru. Výrobce ale musí zjistit, kterých výrobků se to týká.
Praktická sledovatelnost vyžaduje návaznost od komponenty přes softwarovou položku k definici produktu, variantě, revizi, platnosti, uvolněné konfiguraci a podle dostupnosti i k dodanému kusu. Stejně důležité jsou vazby na požadavky, testy, změnové řízení a schvalovací historii.
Bez tohoto propojení hrozí dvě chyby. Příliš široká reakce může vést ke zbytečným servisním zásahům, odstávkám nebo nejistotě u zákazníků. Příliš úzká reakce může naopak přehlédnout část instalované základny.
Obě situace jsou rizikové.
Kde pomáhá 3DEXPERIENCE
Právě v tomto bodě dává smysl platformní přístup k produktovým datům.
3DEXPERIENCE není nástroj, který sám automaticky „vyřeší CRA“. Její hodnota je v něčem jiném: umožňuje propojit softwarová data s produktovou strukturou, požadavky, testy, konfiguracemi, změnami a rozhodnutími.
V praxi to znamená, že software nemusí zůstat oddělený od zbytku výrobku. Softwarová položka může být součástí širší produktové definice a být navázaná na hardwarovou konfiguraci, požadavky, ověřování, změnové řízení i uvolněnou verzi výrobku.
Softwarový tým může dál pracovat ve svých vývojových nástrojích. Bezpečnostní nástroje mohou dál identifikovat zranitelnosti. PLM může dál řídit produktovou strukturu. Hodnota vzniká ve chvíli, kdy se tyto světy propojí a výrobce dokáže odpovědět:
Který software je dotčený?
Ve kterém produktu je použitý?
Jaké konfigurace jsou zasažené?
Jaké požadavky a testy s tím souvisí?
Jaká změna byla schválena?
Která verze byla uvolněna?
Jaké rozhodnutí je k dispozici pro audit?
V prostředí 3DEXPERIENCE lze software řídit v kontextu multidisciplinárního vývoje produktu. Role Connected Software Engineer pracuje s principem správy softwaru v kontextu výrobku a umožňuje přes konektory pracovat s obsahem z externích SCM nástrojů, například Git nebo DesignSync.
3DEXPERIENCE Governance & Lifecycle zároveň zahrnuje oblasti jako change request, impact analysis, change order, change action, investigation request, varianty a produktové konfigurace. Součástí jsou také možnosti software configuration management přes Git, GitHub, GitLab a DesignSync a správa softwarových artefaktů přes Artifactory.
To neznamená, že platforma nahrazuje bezpečnostní nástroje nebo vývojové repozitáře. Znamená to, že pomáhá zasadit softwarový nález do kontextu skutečného výrobku.
Digitální vlákno jako důkazový řetězec
V souvislosti s 3DEXPERIENCE se často mluví o digitálním vláknu. U Cyber Resilience Act ale nejde o módní pojem. Digitální vlákno má velmi praktický význam: slouží jako důkazový řetězec.
Výrobce musí být schopen dohledat, jak souvisí zranitelná komponenta se softwarovým sestavením, jak toto sestavení souvisí s konkrétním výrobkem, jaká změna byla provedena, kdo ji schválil a která konfigurace byla uvolněna.
Všechna data nemusí být v jedné aplikaci. Specializované nástroje mají dál svou roli. Potřebují však stabilní identity objektů, řízené vazby a společná pravidla změn. Digitální vlákno tu má význam důkazního řetězce, nikoli pohodlnějšího úložiště dokumentů.
To je pro výrobce zásadní. Pokud má během 24 nebo 72 hodin reagovat na bezpečnostní problém, nemůže zpětně rekonstruovat historii z e-mailů. Musí ji mít uloženou jako přirozený výsledek každodenní práce.
Připravit, analyzovat, reagovat
Funkční přípravu na Cyber Resilience Act lze zjednodušeně rozdělit do tří schopností: připravit, analyzovat, reagovat.
Připravit znamená, že bezpečnostní rizika a požadavky nevznikají až na konci projektu. Mají být součástí architektury, požadavků, návrhu, testování a změnového řízení.
Analyzovat znamená, že když přijde informace o zranitelnosti, výrobce dokáže rychle určit dotčenou komponentu, softwarové sestavení, produktovou strukturu, revizi, variantu a platnost.
Reagovat znamená, že zjištěný dopad přejde do řízeného procesu: určí se vlastník, vyhodnotí riziko, schválí nápravné opatření, provede změna, ověří se výsledek a uvolní se nová konfigurace.
Proces pro lhůty 24 a 72 hodin je třeba nacvičit dříve, než nastane kritická událost. Improvizace přes e-mail nevytváří spolehlivou odpovědnost ani auditovatelnou historii.
Co si má výrobce ověřit už dnes
Připravenost na CRA není jen otázka bezpečnostní dokumentace. Důležitější je schopnost rychle a doložitelně odpovědět na několik praktických otázek.
Dokážeme propojit zranitelnou softwarovou komponentu s konkrétním softwarovým sestavením? Víme, ve kterých produktových konfiguracích byla použita? Umíme dohledat, jaká verze byla skutečně uvolněna? Vidíme vazbu na požadavky, testy, změny a zákaznické varianty? Máme jasně určené, kdo rozhoduje o dopadu zranitelnosti? Vzniká z rozhodnutí auditovatelná stopa?
Jedna z nejdůležitějších otázek zní: sestavíme podklady pro 24hodinové varování z řízených dat, nebo z tabulek a e-mailů?
Pokud odpověď zní „museli bychom se poptat“, je to riziko.
Role TECHNODAT
TECHNODAT vstupuje do těchto projektů tam, kde se kybernetická odolnost potkává s produktovými daty, PLM, konfiguracemi, změnovým řízením a integrací systémů.
V praxi může jít o analýzu současného stavu produktových dat, návrh digitálního vlákna, nastavení PLM procesů, implementaci a rozvoj 3DEXPERIENCE platformy, práci s ENOVIA, propojení CAD / PLM / ERP nebo konzultaci, jak vytvořit dohledatelnou vazbu mezi softwarovou komponentou, produktovou konfigurací a řízenou změnou.
Cílem není přidat další administrativu. Cílem je nastavit prostředí tak, aby důležité vazby vznikaly přirozeně při běžné práci a byly dostupné ve chvíli, kdy je výrobce skutečně potřebuje.
SBOM je důležitý. Pomáhá pochopit, jaké softwarové komponenty jsou v produktu použité.
Ale sám o sobě nestačí.
Cyber Resilience Act posouvá odpovědnost výrobců dál. Nestačí vědět, že zranitelná komponenta existuje. Výrobce musí vědět, kde se tato komponenta nachází ve skutečném výrobku, jaké konfigurace ovlivňuje, jaké změny jsou nutné a proč je jeho rozhodnutí obhajitelné.
Právě zde může 3DEXPERIENCE sehrát důležitou roli: pomáhá vytvořit řízený produktový kontext, ve kterém jsou propojené softwarové položky, hardware, požadavky, testy, konfigurace, změny a auditovatelná historie rozhodnutí.
V praxi nebude rozhodovat počet dokumentů. Rozhodovat bude schopnost rychle a věcně odpovědět:
Kterých výrobků se problém týká, co jsme s tím udělali a proč je naše rozhodnutí správné?
