V roce 2026 o 131% více nahlášených CVE denně než loni.

Kybernetická bezpečnost pro výrobce telekomunikačních a síťových zařízení

Routery, switche, přístupové body a rádiová zařízení dodávají firmware sestavený z distribuce embedded Linuxu, SDK výrobců čipů a stovek open source balíčků. Regulátoři i operátoři se dnes ptají, co je v každém vydání. CRACI spouští vaše buildy firmwaru a zaznamenává každou komponentu, která do nich vstupuje.

Rezervujte si demo

Tři režimy, jedna otázka

Routery, switche, přístupové body a rádiová zařízení se dnes řídí unijním právem o rádiových zařízeních, od prosince 2027 pravidly Cyber Resilience Act pro důležité produkty a k tomu požadavky telekomunikačních operátorů, kteří musí podle NIS2 prověřovat své dodavatele. Všechny tři se sbíhají ke stejné otázce: co je v každém vydání firmwaru?

  1. Požadavky směrnice o rádiových zařízeních na kybernetickou bezpečnost se začínají vztahovat na rádiová zařízení připojená k internetu.
  2. Začíná platit povinnost oznamovat podle Cyber Resilience Act aktivně zneužívané zranitelnosti a závažné incidenty.
  3. Cyber Resilience Act se použije v plném rozsahu a pravidla kybernetické bezpečnosti pro rádiová zařízení se zrušují.

Směrnice o rádiových zařízeních: nařízení v přenesené pravomoci (EU) 2022/30

Nařízení v přenesené pravomoci uvádí v použitelnost základní požadavky čl. 3 odst. 3 písm. d), e) a f) směrnice o rádiových zařízeních: žádné poškozování sítě, ochrana osobních údajů a soukromí a ochrana před podvody. Vztahuje se na rádiová zařízení připojená k internetu a na některé další kategorie, například zařízení péče o děti, hračky a nositelná zařízení. Použije se od 1. srpna 2025, o rok později, než se původně plánovalo. Wi-Fi routery a přístupové body jsou typická rádiová zařízení připojená k internetu; switch jen s kabelovým připojením rádiovým zařízením není. Klasifikaci vlastního produktu si ověřte.

EN 18031-1, -2 a -3

EN 18031-1, -2 a -3:2024 jsou harmonizované normy pro písmena d), e) a f). Odkazy na ně byly zveřejněny v Úředním věstníku v lednu 2025 s omezeními:

  • Oddíly „rationale“ a „guidance“ nezakládají předpoklad shody.
  • Předpoklad shody nevzniká, pokud produkt uživateli umožňuje rozhodnout se heslo nenastavit nebo nepoužívat (články 6.2.5.1 a 6.2.5.2).
  • U EN 18031-2 nevzniká předpoklad shody pro zařízení péče o děti a hračky bez rodičovské kontroly přístupu nebo kontroly přístupu zákonného zástupce.
  • U EN 18031-3 nevzniká předpoklad shody z kritérií hodnocení bezpečné aktualizace v článku 6.3.2.4.

V praxi tak produkt, který některou z těchto možností využívá, potřebuje pro dotčený požadavek posouzení třetí stranou.

Přechod na CRA

Nařízení v přenesené pravomoci (EU) 2026/339 zrušuje nařízení 2022/30 s účinkem od 11. prosince 2027, tedy ode dne, kdy se CRA použije v plném rozsahu, protože základní požadavky CRA zahrnují vše z čl. 3 odst. 3 písm. d), e) a f) RED. Dozor nad trhem podle směrnice o rádiových zařízeních pokračuje u rádiových zařízení uvedených na trh mezi 1. srpnem 2025 a 10. prosincem 2027. CRA požaduje, aby se při tvorbě jeho vlastních norem zohlednila práce na EN 18031; EN 18031 se sama o sobě normou pro CRA nestává. Rádiová zařízení uvedená na trh do 10. prosince 2027 se tedy posuzují podle nařízení v přenesené pravomoci; od 11. prosince 2027 platí CRA.

Třídy CRA pro síťová zařízení

Příloha III CRA uvádí důležité produkty. Třída I zahrnuje routery, modemy určené k připojení k internetu a switche; systémy správy sítí; produkty VPN; fyzická a virtuální síťová rozhraní; a operační systémy. Třída II zahrnuje firewally a systémy detekce a prevence průniků. Příloha IV, kritické produkty, routery ani switche neuvádí.

Produkt třídy I lze posoudit vlastními silami jen tehdy, pokud se v plném rozsahu uplatní harmonizované normy, společné specifikace nebo evropský systém certifikace kybernetické bezpečnosti na úrovni záruky „pokročilá“; jinak se zapojí oznámený subjekt (EU přezkoušení typu a shoda s typem, nebo plné zabezpečení kvality). Produkty třídy II vždy potřebují jeden z těchto postupů nebo certifikační systém. Dokud nebudou zveřejněny harmonizované normy CRA pro tyto třídy, měli by výrobci produktů třídy I počítat s posouzením třetí stranou.

Oznamování podle CRA

Od 11. září 2026 výrobci oznamují aktivně zneužívané zranitelnosti a závažné incidenty: včasné varování do 24 hodin, oznámení do 72 hodin a závěrečnou zprávu 14 dní poté, co je k dispozici oprava zranitelnosti, nebo jeden měsíc po oznámení u závažného incidentu.

NIS2 pro vaše zákazníky

Podle NIS2, směrnice (EU) 2022/2555, spadají do působnosti poskytovatelé veřejných sítí a služeb elektronických komunikací bez ohledu na svou velikost. Článek 21 jim ukládá řídit bezpečnost dodavatelského řetězce a řešení zranitelností a zohledňovat zranitelnosti každého přímého dodavatele, celkovou kvalitu jeho produktů a jeho postupy bezpečného vývoje. Proto operátoři posílají výrobcům zařízení bezpečnostní dotazníky a žádosti o SBOM. Povinnosti podle NIS2 nese operátor, ne výrobce zařízení.

ProduktNařízení v přenesené pravomoci 2022/30 do 10. prosince 2027Třída CRA od 11. prosince 2027Co se zákazníci obvykle ptají
Wi-Fi routerAno: rádiové zařízení připojené k internetuDůležitý, třída I (routery)SBOM pro každé vydání firmwaru; „týká se nás to?“ u každého CVE
Podnikový switch, jen kabelovýNe: není rádiové zařízeníDůležitý, třída I (switche)SBOM, bezpečnostní dotazníky od operátorů
Firewall applianceOvěřte: jen pokud má rádioDůležitý, třída II (firewally)Proces řešení zranitelností, SBOM, politika aktualizací
Software pro správu sítěNe: není rádiové zařízeníDůležitý, třída I (systémy správy sítí)SBOM, důkazy o bezpečném vývoji
Jednotka rádiového přístupuOvěřte: závisí na produktuOvěřte: závisí na jejích funkcíchSBOM, řešení zranitelností, dotazníky pro dodavatele
Modem CPEAno, pokud má Wi-FiDůležitý, třída I (modemy pro připojení k internetu)SBOM pro každé vydání firmwaru, doba podpory aktualizací

Jde o obecné informace, nikoli o právní poradenství. Klasifikaci vlastního produktu si ověřte.

Proč je těžké mít přehled o síťových zařízeních

Firmware je většinou kód někoho jiného. Distribuce embedded Linuxu, SDK a záplaty jádra od dodavatele SoC, síťový stack, stovky open source balíčků a na novějších platformách služby v Rustu a Go. Každá z těchto částí přináší vlastní závislosti.

Jedna kódová báze, mnoho platforem, mnoho vydání. Stejný firmware se sestavuje pro mnoho hardwarových platforem a v provozu je současně mnoho vydání. Každé vydání je jiná sada komponent.

Skenování hotové image je odhad. Sken image firmwaru odvozuje její obsah a přehlédne to, co bylo zakompilováno dovnitř. Vlastní SBOM Yocta je u receptů důkladná, ale v buildu, který jsme porovnávali, neuvedla u crates pro Rust žádnou package URL, takže je nebylo možné porovnat s bezpečnostními upozorněními. Více o buildech Yocto na CRACI. Viz také proč skenery SBOM přehlížejí, co je v buildech Yocto.

Dotazy zákazníků přibývají s každým medializovaným CVE. Jak slýcháme od týmů produktové bezpečnosti, každý dotaz začíná otázkou „týká se nás to?“ a každý vyžaduje odpověď pro každý produkt a každou verzi.

Ilustrativní případ „týká se nás to?“

V rozšířené kompresní knihovně je zveřejněna zranitelnost (smyšlená, pro ilustraci). Dva týmy produktové bezpečnosti dostanou od svých zákazníků z řad operátorů stejnou otázku.

KrokSe SBOM z každého buildu a historií buildůSe skeny hotových image
Najít komponentuVyhledat knihovnu a její verze v zaznamenaných SBOMZnovu naskenovat image, které jsou stále v provozu, pokud se dají najít
Najít vydáníHistorie buildů uvádí buildy, které ji obsahovaly, přímo nebo tranzitivněRučně sladit výsledky skenů s poznámkami k vydání
Najít obdobíPrvní a poslední build se zranitelnou verzí udávají okno expoziceOdhadnout ho podle toho, kdy byly image sestaveny
Odpovědět zákazníkoviSeznam dotčených produktů a verzí a těch, kterých se to netýkáNejlepší odhad s výhradami

Více o tom, jak odpovědět na otázku „týká se nás to?“.

Jak se připravit, krok za krokem

Bezpečnostní funkce produktu, jako je práce s hesly a bezpečná aktualizace, jsou součástí zařízení. Následující kroky pokrývají to, co vstupuje do jeho firmwaru.

  1. Klasifikujte každý produkt. U každého produktu rozhodněte, zda je do prosince 2027 rádiovým zařízením podle nařízení v přenesené pravomoci a která třída CRA se na něj vztahuje od té doby. Třída určuje postup posouzení shody.
  2. Vytvářejte SBOM z každého buildu vydání. Zaznamenejte jádro, SDK, stažené zdroje a každý balíček v každém buildu firmwaru, nejen balíčky, které image instaluje. Jak nastavit jednu politiku SBOM pro všechny týmy a pipeline, se dočtete v článku generování SBOM napříč vývojovými týmy.
  3. Veďte záznam o tom, která vydání co obsahovala a kdy. Každé vydání, jeho komponenty a datum dodání. Díky tomuto záznamu se z otázky „týká se nás to?“ stane vyhledávání.
  4. Přidejte SBOM od dodavatelů a výrobců čipů. SDK výrobců čipů a licencované stacky jsou součástí vašeho firmwaru. Vyžádejte si jejich SBOM a monitorujte je spolu se svými.
  5. Monitorujte průběžně a zaznamenávejte rozhodnutí o nedotčenosti. Kontrolujte každé vydání znovu, jakmile se zveřejní nové zranitelnosti, a pomocí VEX zaznamenejte, proč zranitelná komponenta produkt neovlivňuje.
  6. Nastavte proces oznamování podle CRA. Povinnost oznamovat aktivně zneužívané zranitelnosti a závažné incidenty platí od 11. září 2026. Rozhodněte, kdo provádí triáž, kdo rozhoduje o oznámení a kdo odpovídá zákazníkům; viz jak funguje PSIRT.
  7. Zabezpečte build. Sestavujte v izolovaném prostředí s egress policy s výchozím zákazem a blokujte známé škodlivé verze, aby se nevrátily s aktualizací.

Kam zapadá CRACI

CRACI spouští vaše buildy firmwaru v GitHub Actions na vlastních runnerech a zaznamenává, co vstupuje do každého vydání, takže odpověď pro regulátora nebo operátora pochází z buildu.

Buildy firmwaru, které zaznamenají, co do nich vstoupilo

Spouštějte své buildy Yocto a dalších embedded Linuxů na runnerech CRACI pro GitHub Actions, až s 32 vCPU, na x86-64 nebo nativně na ARM64. Během buildu CRACI zaznamenává každý balíček a soubor, který stáhne, včetně balíčků hostitele, zdrojů z Gitu, GitHub Actions a stažených souborů, které neuvádí žádný recept ani lockfile. V buildu core-image-sato obsahovala SBOM od CRACI každou komponentu z vlastní SBOM Yocta a k tomu 88, které Yocto vynechalo, s package URL u každé ze 653 verzí crates pro Rust. Více o buildech Yocto na CRACI.

Embedded builds on CRACI runners Yocto and BitBake builds such as core-image-sato run on CRACI runners at size 32. Like every CRACI job, the build runs under an egress policy, records what it fetched and its provenance data. Embedded build bitbake core-image-sato Yocto and BitBake; pi-gen for Raspberry Pi OS CRACI runner, size 32 32 vCPU in an isolated virtual machine Egress policy Fetches recorded Provenance Firmware image SBOM recorded during the build

Odpovězte na otázku „týká se nás to?“ ze záznamu

CRACI průběžně znovu vyhodnocuje monitorované SBOM, jakmile se zveřejní nové zranitelnosti. Historie buildů ukazuje, které buildy obsahovaly zranitelnou závislost, a tedy období, kdy jste byli zasaženi, v rámci doby uchovávání vašeho plánu. U každého balíčku vidíte balíčky, které ho vyžadují, a inventář ukazuje, které verze softwaru jsou nasazeny ve kterých produktech.

Vulnerabilities across everything you have deployed When a new vulnerability is published, CRACI re-evaluates the monitored SBOMs of your releases and vendor SBOMs, finds the affected version, and the inventory view shows which products that version is deployed to. The finding is triaged and routed to the team that owns the fix. New advisory published Long after the release shipped Monitored SBOMs re-evaluated Your release builds and your vendors' SBOMs Affected: Gateway firmware v1.8.4 Inventory: where v1.8.4 is deployed Product Deployed version Gateway Pro v1.8.4 Gateway Mini v1.8.4 Route the fix

Kód dodavatelů vedle vašeho vlastního

Přidejte SBOM od výrobců čipů a dalších dodavatelů a nakoupené komponenty se budou monitorovat spolu s firmwarem, který sestavujete. Až se objeví další zranitelnost v SDK, bude kód dodavatele ve stejném záznamu jako ten váš.

Vendor SBOMs tracked next to your own SBOMs from your own builds and SBOMs added from your vendors are monitored in the same place, so bought-in components are re-evaluated against new vulnerabilities alongside your own dependencies. Your builds api-service SBOM web-app SBOM firmware SBOM Your vendors Payment SDK SBOM Camera module SBOM RTOS SBOM Monitored in one place Every SBOM re-evaluated as new vulnerabilities are published Third-party code tracked like your own dependencies Findings triaged and routed to the team that owns the fix

Triáž, VEX a policy gates

Bezpečnostní týmy provedou triáž každého nálezu a předají ho týmu, který odpovídá za opravu. CRACI podporuje VEX pro záznam toho, jak zranitelnost ovlivňuje váš produkt, a policy gate dokáže udržet konkrétní CVE mimo všechny další buildy.

Triage and routing to the owning team A security team triages a discovered vulnerability and sends it to the team that owns the fix. CRACI supports VEX for recording how a vulnerability affects your product. New finding Vulnerable component in shipped builds 3 builds 2 repositories Security team Triages the finding VEX supported Owning team Receives the finding and ships the fix Each finding reaches the people who can act on it Policy gates can block a build on findings, so a known issue does not ship again

Build, který se dostane jen tam, kam potřebuje

Každý job běží ve vlastním izolovaném virtuálním stroji pod egress policy, kterou můžete nastavit na výchozí zákaz, ověřenou před spuštěním jobu a při selhání vše blokující. S politikou výchozího zákazu se spojení s hostitelem, kterého build nepotřebuje, zablokuje a vyvolá upozornění.

An egress policy on the build network A build job connects to hosts in its egress policy, such as package registries and Git, and a connection to a host outside the policy is blocked. The policy is validated before the job starts and fails closed, and a violation sends an alert. Egress policy Default deny Validated before the job starts Fails closed · 24 source presets Build job on a CRACI runner npm registry allowed PyPI allowed Git over HTTPS allowed Unapproved host blocked Alert on policy violation Connections are recorded in the job's network trace

Kdy CRACI není řešením

CRACI se hodí pro firmware a software, který sestavujete. Nehodí se pro tyto případy:

  • Není pro telekomunikační operátory, kteří zabezpečují vlastní sítě nebo plní NIS2 pro vlastní provoz. CRACI je pro výrobce zařízení a softwaru a operátorům pomáhá jen tím, že jejich dodavatelé mají lepší důkazy.
  • Není pro firmware sestavovaný mimo GitHub Actions, na Windows nebo macOS ani na build farmách, které musí zůstat ve vašich prostorách. GitLab CI a Jenkins, runnery pro Windows a macOS a runnery hostované zákazníkem jsou v plánu vývoje.
  • Není pro image, které jste nesestavili. CRACI neskenuje binárky ani firmware třetích stran; pro ně potřebujete SBOM od dodavatele nebo nástroj pro analýzu binárek (viz CRACI vs ONEKEY a srovnání nástrojů pro bezpečnost embedded systémů).
  • Není to úplný systém PSIRT pro správu případů ani pro publikování bezpečnostních upozornění. CRACI nepřijímá externí hlášení zranitelností jako případy, nepublikuje bezpečnostní upozornění a neprovádí analýzu dosažitelnosti. Viz srovnání nástrojů PSIRT.
  • Neřeší posouzení shody, testování podle EN 18031 ani bezpečnostní funkce produktu, jako je práce s hesly, bezpečná aktualizace a řízení přístupu. CRACI firmware nepodepisuje.

Bezpečnost síťových zařízení vysvětlená

Časté dotazy výrobců zařízení k RED, EN 18031, CRA a NIS2

Která síťová zařízení jsou podle CRA důležitými produkty a jaké třídy?

Třída I v příloze III zahrnuje routery, modemy určené k připojení k internetu a switche, systémy správy sítí, produkty VPN, fyzická a virtuální síťová rozhraní a operační systémy. Třída II zahrnuje firewally a systémy detekce a prevence průniků. Routery a switche nejsou kritickými produkty podle přílohy IV.

Odkdy platí požadavky RED na kybernetickou bezpečnost a na která rádiová zařízení?

Od 1. srpna 2025. Nařízení v přenesené pravomoci (EU) 2022/30 uvádí čl. 3 odst. 3 písm. d), e) a f) směrnice o rádiových zařízeních v použitelnost pro rádiová zařízení připojená k internetu a pro některé další kategorie, jako jsou zařízení péče o děti, hračky a nositelná zařízení. Datum bylo posunuto z 1. srpna 2024 pozdějším nařízením v přenesené pravomoci.

Zakládají EN 18031-1, -2 a -3 předpoklad shody?

Ano, s omezeními. Jejich oddíly rationale a guidance žádný nezakládají; žádný nevzniká, pokud si uživatel může zvolit, že heslo nenastaví nebo nepoužije; u EN 18031-2 žádný pro zařízení péče o děti a hračky bez rodičovské kontroly přístupu nebo kontroly přístupu zákonného zástupce; a u EN 18031-3 žádný z kritérií bezpečné aktualizace v článku 6.3.2.4. Tyto případy vyžadují posouzení třetí stranou.

Co se stane s aktem v přenesené pravomoci k RED a s EN 18031, až se začne CRA uplatňovat?

Nařízení v přenesené pravomoci (EU) 2026/339 zrušuje nařízení 2022/30 s účinkem od 11. prosince 2027, kdy se CRA použije v plném rozsahu. Rádiová zařízení uvedená na trh do 10. prosince 2027 zůstávají pod dozorem nad trhem podle RED. EN 18031 se má zohlednit ve vlastních normách CRA, sama o sobě se ale normou pro CRA nestává.

Jak NIS2 ovlivňuje dodavatele telekomunikačních operátorů?

Nepřímo. NIS2 ukládá povinnosti operátorům, kteří musí řídit bezpečnost dodavatelského řetězce a zohledňovat zranitelnosti každého přímého dodavatele, kvalitu jeho produktů a jeho postupy bezpečného vývoje. Předávají to dál v podobě bezpečnostních dotazníků, žádostí o SBOM a smluvních podmínek. Vlastní zákonné povinnosti výrobce zařízení vyplývají z RED a CRA.

Může výrobce routerů nebo switchů provést posouzení podle CRA vlastními silami?

Jen pokud v plném rozsahu uplatní harmonizované normy, společné specifikace nebo evropský systém certifikace kybernetické bezpečnosti na úrovni záruky pokročilá, protože routery a switche jsou důležité produkty třídy I. Jinak se zapojí oznámený subjekt. Dokud nebudou pro tyto produkty zveřejněny harmonizované normy CRA, počítejte s posouzením třetí stranou.

Funguje CRACI s Yoctem?

Ano. Buildy Yocto a BitBake běží na runnerech CRACI a CRACI zaznamenává SBOM jobu během buildu. Vlastní výstup SPDX z Yocta ale stále nese metadata receptů, která CRACI nezaznamenává, například použité záplaty a CVE, které recept označuje jako opravené, takže pokud na ně spoléháte, nechte create-spdx zapnuté.

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, jako GitLab CI a Jenkins, jsou v plánu vývoje, stejně jako runnery pro Windows a macOS.

Podívejte se, co vstupuje do vašeho firmwaru

Rezervujte si demo a my vám ukážeme každou komponentu, kterou vaše buildy firmwaru stahují, a kterých vydání se týká nové CVE

Rezervujte si demo