Kybernetická bezpečnost pro výrobce strojů
Stroje se dnes dodávají s řídicími jednotkami, displeji, telematickými jednotkami a doprovodnými aplikacemi, které většinou vyvíjejí dodavatelé. Od roku 2027 od vás nařízení o strojních zařízeních i Cyber Resilience Act očekávají, že budete vědět, jaký software je na každém stroji, a že ho budete léta udržovat bezpečný. CRACI zaznamenává, co vstupuje do každého buildu softwaru.
Dvě nařízení, jedna otázka: jaký software je na stroji?
Od roku 2027 podléhá stroj s řídicí jednotkou, displejem pro obsluhu nebo datovým připojením dvěma nařízením EU. Obě vycházejí ze stejné otázky: jaký software je na tomto stroji, verzi po verzi, a co obsahuje.
- Začíná platit povinnost podle Cyber Resilience Act oznamovat aktivně zneužívané zranitelnosti a závažné incidenty.
- Začíná se používat nařízení o strojních zařízeních, (EU) 2023/1230, které nahrazuje směrnici o strojních zařízeních.
- Cyber Resilience Act, (EU) 2024/2847, se začíná používat v plném rozsahu.
Nařízení o strojních zařízeních
Kybernetické bezpečnosti se týkají dva základní požadavky na ochranu zdraví a bezpečnost z přílohy III:
- 1.1.9, ochrana před poškozením. Připojení jiného zařízení ke stroji, přímo nebo na dálku, nesmí vést k nebezpečné situaci. Software a data, která jsou kritická pro soulad stroje se základními požadavky na ochranu zdraví a bezpečnost, musí být identifikována a chráněna před náhodným nebo úmyslným poškozením. Stroj musí identifikovat software v něm nainstalovaný, který potřebuje k bezpečnému provozu, a tuto informaci musí poskytovat kdykoli. Musí také shromažďovat důkazy o oprávněných i neoprávněných zásazích do tohoto softwaru nebo jeho konfigurace.
- 1.2.1, bezpečnost a spolehlivost ovládacích systémů. Ovládací systémy musí odolat rozumně předvídatelným úmyslným pokusům třetích stran, které vedou k nebezpečné situaci. Podle bodu 1.2.1 písm. f) musí vést záznamy o zásazích a o verzích bezpečnostního softwaru nahraných po uvedení stroje na trh, a to po dobu pěti let od nahrání.
Cyber Resilience Act
Stroj s datovým připojením nebo jeho samostatně prodávaná část je produkt s digitálními prvky. Výrobce musí vynaložit náležitou péči u komponent třetích stran, které integruje, vypracovat SBOM pokrývající přinejmenším nejdůležitější závislosti produktu, řešit zranitelnosti po dobu podpory, která činí nejméně pět let, pokud se nepředpokládá, že se produkt bude používat kratší dobu, a uchovávat technickou dokumentaci nejméně deset let nebo po dobu podpory, podle toho, co je delší.
| Požadavek | Nařízení o strojních zařízeních | Cyber Resilience Act | Co to vyžaduje na straně softwaru |
|---|---|---|---|
| Znát nainstalovaný software | 1.1.9: stroj kdykoli identifikuje software, který potřebuje k bezpečnému provozu | SBOM pokrývající přinejmenším nejdůležitější závislosti produktu | Záznam každé komponenty v každé verzi softwaru |
| Chránit ho před poškozením | 1.1.9 a 1.2.1: chránit bezpečnostní software a odolat úmyslným pokusům | Základní požadavky na kybernetickou bezpečnost produktu | Známé komponenty a buildy, do kterých otrávená závislost nedosáhne |
| Zaznamenávat změny a verze | 1.2.1 písm. f): záznamy o verzích bezpečnostního softwaru nahraných po uvedení na trh | Technická dokumentace k produktu uvedenému na trh | Historie verzí pro každý build a každé vydání |
| Řešit zranitelnosti | Výslovně neuvedeno | Řešení zranitelností po dobu podpory; oznamování od 11. září 2026 | Monitorování dodaných komponent proti novým bezpečnostním upozorněním |
| Uchovávat záznamy | Záznamy o zásazích: pět let po každém nahrání | Technická dokumentace: nejméně deset let nebo doba podpory | SBOM exportované do technické dokumentace |
Pokrývá soulad s CRA i nařízení o strojních zařízeních?
Ne automaticky. Cyber Resilience Act nezakládá předpoklad shody s nařízením o strojních zařízeních. Jeho bod odůvodnění 53 uvádí, že splnění základních požadavků CRA by mohlo usnadnit splnění požadavků nařízení o strojních zařízeních na ochranu před poškozením a na bezpečnost a spolehlivost ovládacích systémů. Uvádí také, že to musí výrobce prokázat, například uplatněním harmonizovaných norem po posouzení rizik, a že postupy posuzování shody podle obou nařízení se nadále uplatňují.
Harmonizovaná norma připravovaná pro bod 1.1.9 je EN 50742, Safety of machinery: Protection against corruption. V listopadu 2026 šlo o konečný návrh FprEN 50742, který pokrývá bod 1.1.9 a související body 1.2.1, a dokud nebude konečná verze citována v Úředním věstníku, nezakládá předpoklad shody. Spojuje posouzení rizik podle EN ISO 12100 s bezpečnostními koncepty z IEC 62443 a jako rovnocenný způsob splnění svých ochranných cílů uznává důsledné uplatňování IEC 62443-4-1, IEC 62443-3-3 a IEC 62443-4-2. IEC 62443-4-2 stanoví technické bezpečnostní požadavky na komponenty řídicích systémů, odstupňované podle úrovně bezpečnostní schopnosti. V Německu převádějí zkušební zásady GS-IFA-M25 z července 2026 ochranu před poškozením do 66 zkušebních kritérií s využitím pojmů z prEN 50742. Jedno z nich, T46, požaduje, aby produkt na vyžádání dokázal poskytnout verzi a konfiguraci nainstalovaného softwaru. Odpovědět na to u každé konfigurace vyžaduje záznam toho, co každá verze softwaru obsahuje.
Nařízení o strojních zařízeních má vlastní předpoklad shody, ale ten vede jinou cestou: přes evropské programy certifikace kybernetické bezpečnosti přijaté podle aktu o kybernetické bezpečnosti, nařízení (EU) 2019/881. Certifikát nebo prohlášení o shodě v rámci takového programu zakládá předpoklad shody s body 1.1.9 a 1.2.1 v rozsahu, v jakém tyto požadavky pokrývá.
Jedno posouzení rizik a jeden soubor důkazů tedy mohou posloužit pro obě nařízení, ale shodu prokazujete s každým zvlášť. Pokud má váš stroj datové připojení, počítejte s oběma. Softwarové důkazy, tedy SBOM, záznamy o zranitelnostech a historie aktualizací, jsou částí, kterou mají společnou.
V lednu 2026 požádala průmyslová sdružení výrobců strojů o odklad bodů 1.1.9 a 1.2.1 písm. f) a v březnu 2026 o to, aby se uplatňovaly od data CRA, 11. prosince 2027. Jde o žádost, ne o právo: v listopadu 2026 nebyl žádný odklad přijat. Data na této stránce jsou data uvedená v nařízeních.
Které stroje a jaký software spadají do působnosti
- Stavební, manipulační, důlní a průmyslové stroje spadají pod nařízení o strojních zařízeních, a pokud mají stroj nebo jeho části datové připojení, také pod CRA.
- Zemědělské a lesnické traktory, na které se vztahuje nařízení (EU) č. 167/2013, jsou z nařízení o strojních zařízeních vyloučeny, s výjimkou strojních zařízení na nich namontovaných. Seznam výjimek v CRA toto nařízení neuvádí, takže připojený traktor může do působnosti CRA spadat.
- Silniční vozidla schválená podle nařízení (EU) 2019/2144 jsou z CRA vyloučena.
- Samostatně prodávané komponenty. CRA se vztahuje i na softwarové a hardwarové komponenty uváděné na trh samostatně. Dodavatel, který samostatně prodává ECU nebo telematickou jednotku, je podle CRA sám výrobcem. Pokud je jednotka pouze zabudována do stroje, nese povinnost za celý stroj výrobce stroje a musí vynaložit náležitou péči u komponenty od dodavatele.
Jde o obecné informace, ne o právní radu. Klasifikaci svého produktu si ověřte.
V jednom stroji pochází software z různých míst a spolehlivě říct, co v něm je, dokáže jen tým, který daný software sestavuje. Jak slyšíme od výrobců strojů, bare-metal ECU obsahují málo open source, zatímco software pro Linux, Android a Windows ho obsahuje hodně.
| Software | Typický původ | Podíl open source | Kdo dokáže vytvořit spolehlivou SBOM | Kde se uplatní CRACI |
|---|---|---|---|---|
| Aplikace řídicí jednotky stroje | Vlastní vývoj nebo dodavatel | Různý | Tým, který ji sestavuje | Když se sestavuje v GitHub Actions na Linuxu |
| Firmware ECU (hydraulika, řízení, pohon) | Dodavatel | Obvykle nízký: proprietární a z modelů generovaný kód | Dodavatel | Ne přímo: přes SBOM dodavatele přidanou do CRACI |
| Linuxový image displeje nebo HMI | Vlastní vývoj nebo dodavatel | Vysoký | Tým, který image sestavuje | Ano: Yocto a další buildy embedded Linuxu |
| Telematická brána | Vlastní vývoj nebo dodavatel | Vysoký | Tým, který ji sestavuje | Ano, když se sestavuje v GitHub Actions |
| Diagnostické a doprovodné aplikace | Vlastní vývoj | Vysoký | Tým aplikace | Buildy npm, PyPI, Go a Cargo ano; Android s Gradlem, iOS a aplikace pro Windows dnes ne |
| Cloudový back end | Vlastní vývoj | Vysoký | Tým služby | Ano, pro buildy v GitHub Actions |
Proč je to u strojů těžší než u spotřební elektroniky
Malé objemy, velká rozmanitost. Výrobce strojů může mít na trhu stovky platforem, z každé prodat ročně jen pár kusů a mnoho strojů konfigurovat na zakázku. Každá konfigurace je jiná sada softwaru, takže SBOM pro každý build je důležitější než SBOM pro každou produktovou řadu.
Dlouhá životnost. Stroje zůstávají v provozu deset let i déle, zatímco dodavatelé se mění nebo zanikají. Záznam o tom, co vstoupilo do verze softwaru, musí vzniknout při jejím buildu, protože po letech ho už zrekonstruovat nelze.
Převládá software dodavatelů a jejich SBOM jsou často slabé. Slýcháme o SBOM od dodavatelů s chybějícími komponentami, bez package URL nebo CPE, bez licencí a bez hashů, některých psaných ručně a neprocházejících validací schématu. Binární analýza nahraného ECU je nouzové řešení: obsah odhaduje, místo aby ho zaznamenala.
Riziko leží v připojených vrstvách. Velká část logiky ECU je generována z modelů a obsahuje málo open source. Open source i vystavení síti se soustřeďují ve vrstvách Linuxu, konektivity a aplikací, takže úsilí věnujte nejprve jim.
Ilustrativní příklad: softwarový stack fiktivní platformy kolového nakladače, od cloudu po ECU.
- Cloudový back end a doprovodná aplikaceVlastní vývoj. Převážně open source a přístupné ze sítě. Cyber Resilience Act.
- Telematická bránaEmbedded Linux, převážně open source, připojená k mobilní síti. Cyber Resilience Act a bod 1.1.9 kvůli vzdálenému připojení.
- Displej pro obsluhuImage embedded Linuxu s UI frameworkem, převážně open source, připojený ke sběrnici stroje a k servisním nástrojům. Cyber Resilience Act a bod 1.1.9.
- Řídicí jednotka strojeVlastní aplikace na platformě dodavatele, relevantní pro bezpečnost. Body 1.1.9 a 1.2.1 a Cyber Resilience Act tam, kde je dosažitelná přes připojení.
- ECU hydrauliky, řízení a motoruFirmware dodavatele, proprietární a generovaný z modelů, málo open source, relevantní pro bezpečnost. Body 1.1.9 a 1.2.1; Cyber Resilience Act prostřednictvím stroje.
Open source i vystavení síti se nacházejí v horních třech vrstvách, kde obvykle běží i vaše vlastní build pipeline. Začněte tam.
Jak se připravit, krok za krokem
Funkce stroje, jako je identifikace softwaru na stroji a záznamy o zásazích, jsou součástí konstrukce stroje. Následující kroky se týkají softwaru, který do něj vstupuje.
- Proveďte inventuru softwaru na každé platformě stroje. Sepište veškerý software na každé platformě a v každé konfiguraci a označte, co je relevantní pro bezpečnost. To je výchozí bod pro bod 1.1.9, který od stroje požaduje, aby identifikoval software potřebný k bezpečnému provozu.
- Oddělte to, co sestavujete, od toho, co integrujete. Software, který sestavují vaše týmy, a software, který přichází od dodavatelů, vyžaduje různé cesty k důkazům. U prvního si záznam vytváříte sami; u druhého stanovujete požadavky a kontrolujete, co dostáváte.
- Zaznamenejte každý release build vlastního softwaru. Z každého release buildu vytvořte SBOM, uchovávejte ji pro každou verzi a po celou dobu podpory ji monitorujte kvůli novým zranitelnostem.
- Stanovte minimální standard pro SBOM od dodavatelů. Dohodněte formát a pole, která potřebujete, například package URL nebo CPE, licence a hashe, každou dodávku validujte a vraťte ji, když nevyhoví. Podívejte se, jak dodavatelé odpovídají na požadavky zákazníků na SBOM.
- Naplánujte uchovávání na celou životnost stroje. Technickou dokumentaci podle CRA uchovávejte nejméně deset let nebo po dobu podpory, podle toho, co je delší, a záznamy o bezpečnostním softwaru podle bodu 1.2.1 písm. f) pět let po každém nahrání. Plánujte to na životnost stroje, ne na délku projektu.
- Zaveďte řešení a oznamování zranitelností. Povinnost podle CRA oznamovat aktivně zneužívané zranitelnosti a závažné incidenty platí od 11. září 2026. Rozhodněte, kdo provádí triáž nálezů, kdo odpovídá za každou opravu a kdo podává oznámení.
- Zabezpečte samotný build. Každý build spouštějte v izolovaném prostředí, které dosáhne jen na zdroje, jež potřebuje, aby se kompromitovaná závislost nedostala k vašemu zdrojovému kódu, tajným klíčům ani vydání.
Kde se uplatní CRACI
CRACI spouští vaše buildy v GitHub Actions na vlastních runnerech a zaznamenává, co do každého z nich vstupuje. U výrobce strojů to pokrývá software, který sestavují vaše týmy, i SBOM, které shromažďujete od dodavatelů.
Záznamy buildů softwaru pro stroje, který sestavujete
Spouštějte služby řídicích jednotek a linuxové image displejů a telematiky, včetně buildů Yocto a dalšího embedded Linuxu, na runnerech GitHub Actions od CRACI, s až 32 vCPU, na x86-64 nebo nativně na ARM64. Během buildu CRACI zaznamenává každý balíček a soubor, který build stáhne, včetně skrytých závislostí, které žádný recept ani lockfile neuvádí, a SBOM každého jobu označí stavem úplnosti. V buildu core-image-sato obsahovala SBOM od CRACI každou komponentu z vlastní SBOM Yocta a navíc 88, které Yocto vynechalo, s package URL pro každou ze 653 verzí crate v Rustu. Více o buildech Yocto na CRACI.
SBOM od dodavatelů vedle vašich vlastních
Přidejte SBOM od dodavatelů ECU, displejů a telematiky a nakupované komponenty budou monitorovány spolu se softwarem, který sestavujete. Když se v linuxovém stacku dodavatele objeví nová zranitelnost, ukáže se ve stejném záznamu jako ty vaše.
Kterých strojů se to týká a odkdy
CRACI průběžně znovu vyhodnocuje monitorované SBOM, jakmile jsou zveřejněny nové zranitelnosti. Historie buildů ukazuje, které buildy obsahovaly zranitelnou závislost, přímou i tranzitivní, v rámci doby uchovávání vašeho plánu, a inventář ukazuje, které verze softwaru jsou nasazeny ve kterých produktech. Bezpečnostní týmy provedou triáž každého nálezu a předají ho týmu, který za opravu odpovídá, a kontrolní brána politik (policy gate) může konkrétní CVE udržet mimo všechny další buildy.
Důkazy pro technickou dokumentaci
CRACI dodává důkazy o softwarovém dodavatelském řetězci, které vaše technická dokumentace potřebuje: SBOM z doby buildu exportované ve formátu CycloneDX nebo SPDX, s tranzitivními závislostmi, deklarovanými licencemi a zranitelnostmi nalezenými v jejich komponentách, a k tomu záznamy o zranitelnostech a historii buildů. U strojů v působnosti CRA připravuje CRACI obsah oznámení podle CRA a osoba ve vaší firmě je podává prostřednictvím Single Reporting Platform (jednotné platformy pro podávání zpráv). Posouzení shody, EU prohlášení o shodě a označení CE zůstávají na vás jako na výrobci.
Build, který dosáhne jen na to, co potřebuje
Každý job běží ve vlastním izolovaném virtuálním stroji pod politikou odchozího provozu, která se ověřuje před spuštěním jobu a je fail-closed. S politikou výchozího zákazu dosáhne build na vaše zdroje balíčků a na nic jiného; připojení k jakémukoli jinému hostiteli je zablokováno a vyvolá upozornění.
Pro dodavatele ECU, displejů a telematických jednotek
Výrobci strojů dnes stanovují požadavky na SBOM k softwaru, který nakupují, například package URL nebo CPE, licence, hashe a formát, který projde validací, a soubory, které nevyhoví, vracejí. Pokud sestavujete v GitHub Actions, CRACI vytváří SBOM přímo z buildu, takže uvádí, co skutečně vstoupilo do vydání, včetně komponent, které žádný lockfile neuvádí, s package URL a deklarovanou licencí u každé komponenty. Export porovnejte s úplným seznamem polí, která váš zákazník požaduje. Více o odpovídání na požadavky zákazníků na SBOM.
Kdy CRACI není řešením
CRACI se hodí pro software, který sestavujete. Na tyto případy se nehodí:
- Není pro výrobce strojů, který jen integruje ECU od dodavatelů a sám žádný software nesestavuje. CRACI zaznamenává buildy; nedokáže vytvořit SBOM pro binární soubor, který sestavil někdo jiný. Pokud téměř veškerý váš software přichází nahraný na hardwaru dodavatelů, vašimi nástroji jsou požadavky na SBOM od dodavatelů, validace SBOM a jako nouzové řešení binární analýza, kterou CRACI nedělá (viz binární analýza ve srovnání se záznamem buildu). CRACI vám pomůže přes buildy vašich dodavatelů a monitorováním SBOM, které vám dodají.
- Není pro bare-metal nebo RTOS firmware sestavovaný mimo GitHub Actions nebo na Windows či macOS. CRACI dnes spouští joby GitHub Actions na linuxových runnerech. Další systémy CI, například GitLab CI a Jenkins, a runnery Windows a macOS jsou v plánu vývoje.
- Není pro doprovodné aplikace pro Android sestavované Gradlem ani pro služby v Javě. Maven a Java jsou v plánu vývoje, dnes podporovány nejsou. Aplikace pro iOS potřebují runnery macOS, které jsou rovněž v plánu vývoje.
- Není pro stroje, které už jsou v provozu a jejichž software byl sestaven před lety. CRACI zaznamenává buildy během jejich běhu.
- Není ovládacím prvkem na stroji. Identifikace nainstalovaného softwaru na stroji, shromažďování důkazů o zásazích a vedení záznamů jsou funkce stroje podle bodů 1.1.9 a 1.2.1. CRACI je neposkytuje, nepodepisuje firmware a neprovádí posouzení shody.
- Samo o sobě neslouží k dlouhodobé archivaci. Záznamy buildů se uchovávají po dobu uchovávání podle vašeho plánu. Pro desetiletý horizont exportujte SBOM do své technické dokumentace.
Kybernetická bezpečnost strojních zařízení v kostce
Časté dotazy k nařízení o strojních zařízeních, CRA a softwaru na stroji
Odkdy se používá nařízení EU o strojních zařízeních?
Od 20. ledna 2027. Nařízení (EU) 2023/1230 k tomuto datu nahrazuje směrnici o strojních zařízeních. Původně zveřejněný text uváděl 14. ledna 2027; oprava datum změnila na 20. ledna 2027. Strojní zařízení uváděná od té doby na trh EU musí splňovat jeho základní požadavky na ochranu zdraví a bezpečnost, včetně těch souvisejících s kybernetickou bezpečností v příloze III, body 1.1.9 a 1.2.1.
Jaké požadavky na kybernetickou bezpečnost obsahuje nařízení o strojních zařízeních?
Příloha III bod 1.1.9, ochrana před poškozením: připojení jiného zařízení nesmí vytvořit nebezpečí, software a data kritická pro bezpečnost musí být chráněna, stroj musí kdykoli identifikovat svůj software relevantní pro bezpečnost a shromažďovat důkazy o zásazích. Příloha III bod 1.2.1: ovládací systémy musí odolat rozumně předvídatelným úmyslným pokusům a vést záznamy o verzích bezpečnostního softwaru nahraných po uvedení stroje na trh.
Vztahuje se Cyber Resilience Act na strojní zařízení?
Ano, pokud je stroj nebo jeho část produktem s digitálními prvky, což v praxi znamená, že má datové připojení. CRA strojní zařízení nevylučuje. Jeho oznamovací povinnosti platí od 11. září 2026 a v plném rozsahu se používá od 11. prosince 2027, jedenáct měsíců po nařízení o strojních zařízeních.
Pokud stroj splňuje CRA, splňuje také nařízení o strojních zařízeních?
Ne automaticky. Mezi oběma předpisy neexistuje předpoklad shody. CRA uvádí, že splnění jeho požadavků by mohlo usnadnit splnění bodů 1.1.9 a 1.2.1, ale výrobce to musí prokázat a uplatňují se oba postupy posuzování shody. Vlastní předpoklad shody nařízení o strojních zařízeních vede přes evropské programy certifikace kybernetické bezpečnosti. Jeden soubor důkazů může sloužit pro obě.
Potřebuje výrobce strojů SBOM?
U stroje v působnosti CRA ano: CRA požaduje, aby výrobce vypracoval SBOM pokrývající přinejmenším nejdůležitější závislosti produktu. Nařízení o strojních zařízeních SBOM nezmiňuje, ale bod 1.1.9 od stroje požaduje, aby identifikoval software potřebný k bezpečnému provozu, což se napříč mnoha konfiguracemi bez záznamu každé verze softwaru jen těžko udržuje přesné.
Kdo odpovídá za software v ECU od dodavatele?
Oba, v různých rolích. Dodavatel, který ECU uvádí na trh samostatně, je za tuto komponentu výrobcem podle CRA. Výrobce stroje odpovídá za celý stroj a musí vynaložit náležitou péči u komponent, které integruje, a proto dnes výrobci strojů žádají od dodavatelů SBOM splňující stanovený standard.
Spadají traktory pod nařízení o strojních zařízeních, nebo pod CRA?
Zemědělské a lesnické traktory, na které se vztahuje nařízení (EU) č. 167/2013, jsou z nařízení o strojních zařízeních vyloučeny, s výjimkou strojních zařízení na nich namontovaných. Výjimky v CRA toto nařízení neuvádějí, takže připojený traktor může do působnosti CRA spadat. Klasifikaci svého produktu si ověřte; jde o obecné informace, ne o právní radu.
Které systémy CI a stroje pro buildy CRACI podporuje?
CRACI spouští joby GitHub Actions na linuxových runnerech, x86-64 a ARM64, s 1 až 32 vCPU. Další systémy CI, například GitLab CI a Jenkins, jsou v plánu vývoje, stejně jako runnery Windows a macOS.
Podívejte se, co vstupuje do buildů softwaru vašich strojů
Rezervujte si demo a ukážeme vám každou komponentu, kterou stáhnou buildy vaší řídicí jednotky, displeje a telematiky, a které z nich jsou zranitelné
Rezervujte si demo