Kybernetická bezpečnost pro výrobce námořního softwaru a výstroje
Lodě dnes běží na softwaru od desítek dodavatelů a klasifikační pravidla i unijní právo očekávají, že každý dodavatel ví, co je v jeho softwaru, a udržuje ho bezpečný. CRACI spouští vaše buildy GitHub Actions a zaznamenává každou komponentu, která vstupuje do každého vydání.
Která pravidla se vztahují na které námořní produkty
Dodavatel pro námořní odvětví se zodpovídá třem režimům, které se překrývají, ale nekryjí: unijnímu právu o produktech, klasifikačním pravidlům pro nové lodě a pokynům IMO pro provozovatele lodí. Než začnete plánovat důkazy, zjistěte, co se vztahuje na který produkt.
CRA vylučuje výstroj podle směrnice o lodní výstroji
Článek 2 odst. 4 Cyber Resilience Act, nařízení (EU) 2024/2847, zní: „Toto nařízení se nevztahuje na výstroj spadající do oblasti působnosti směrnice 2014/90/EU.“ Tato směrnice, směrnice o lodní výstroji (Marine Equipment Directive, MED), se vztahuje na výstroj umístěnou nebo určenou k umístění na palubu lodi EU, pro kterou úmluvy IMO vyžadují schválení správou státu vlajky: tedy na výstroj s označením wheel mark (kormidelním kolem). Příkladem je navigační výstroj, jako je radar, ECDIS, AIS a záznamníky údajů o plavbě, radiokomunikační výstroj, protipožární ochrana a záchranné prostředky. Pro svou konkrétní položku zkontrolujte aktuální prováděcí seznam MED.
Co zůstává v působnosti CRA
Produkty s digitálními prvky uváděné na trh EU, které nejsou výstrojí podle MED: palubní a pobřežní software prodávaný jako produkt, instalovaný nebo stahovaný; systémy pro provoz lodi, ubytování, catering a hotelový provoz; systémy služeb pro posádku a cestující; software pro správu flotily a plavby; palubní senzory a brány IoT; monitorovací a automatizační zařízení, které nepotřebuje schválení státu vlajky. Samotný software jako služba je mimo CRA, pokud nejde o zpracování dat na dálku pro produkt, i když na jeho poskytovatele se může stále vztahovat NIS2.
Některé případy vyžadují spíše právní posouzení než pravidlo: výstroj typu s označením wheel mark prodávaná pro lodě, které neplují pod vlajkou EU, a produkty, které kombinují výstroj MED se softwarovými moduly mimo MED.
IACS UR E26 a E27
Jednotné požadavky Mezinárodního sdružení klasifikačních společností platí prostřednictvím klasifikace, nikoli unijního práva. Rev.1 obou požadavků platí pro lodě, jejichž stavba byla smluvně zadána 1. července 2024 nebo později. Jsou povinné pro osobní lodě a vysokorychlostní plavidla na mezinárodních plavbách, nákladní lodě od 500 GT na mezinárodních plavbách, pojízdné vrtné jednotky na moři a některé samohybné offshore jednotky a pro ostatní lodě slouží jako vodítko. Produkt, který je kvůli MED mimo CRA, může být stále v působnosti E26 a E27, a naopak.
IMO
Rezoluce MSC.428(98) žádá provozovatele lodí, aby kybernetická rizika řešili ve svých systémech řízení bezpečnosti nejpozději při prvním ročním ověření dokladu o shodě (Document of Compliance) společnosti po 1. lednu 2021. Pokyny IMO k řízení kybernetických rizik v námořní dopravě jsou nezávazným vodítkem na vysoké úrovni pro provozovatele. Jejich poslední revize z května 2026 uvádí, že řízení kybernetických rizik by mělo zohledňovat externí dodavatele, vestavěné systémy a dodavatelské řetězce softwaru a hardwaru, a žádá provozovatele, aby pro kritické systémy stanovili politiky bezpečnosti dodavatelského řetězce softwaru a hardwaru. Proto provozovatelé tuto otázku předávají svým dodavatelům.
| Příklad produktu | S označením wheel mark (MED)? | Cyber Resilience Act | IACS UR E26 a E27 | Co musí dodavatel doložit |
|---|---|---|---|---|
| ECDIS | Ano | Vyloučeno (článek 2 odst. 4) | Ano, na nových lodích v působnosti | Schválení MED; dokumentace E27 a inventář softwaru |
| Systém automatizace motoru na nově stavěné nákladní lodi | Ověřte | Ano, pokud nejde o výstroj MED | Ano: pohon je pokrytý systém | Dokumentace E27, inventář a bezpečný životní cyklus vývoje; technická dokumentace a SBOM podle CRA |
| Software pro správu hotelového provozu a cateringu | Ne | Ano, pokud se prodává jako produkt | Ověřte: E26 pokrývá jeho síťové rozhraní k pokrytým systémům | SBOM a řešení zranitelností podle CRA |
| Síťová zařízení pro volný čas posádky | Ne | Ano | Ověřte: E26 pokrývá jejich rozhraní k pokrytým systémům | SBOM a řešení zranitelností podle CRA |
| Software pro správu flotily jako služba | Ne | Mimo, pokud nejde o zpracování dat na dálku pro produkt | Ne: běží na pevnině | Odpovědi na dotazníky provozovatelů pro dodavatele; na poskytovatele se může vztahovat NIS2 |
| Palubní senzory pro monitorování stavu | Ověřte | Ano, pokud nejde o výstroj MED | Ověřte: v působnosti, pokud jsou součástí pokrytého systému | SBOM podle CRA; dokumentace E27, pokud jsou součástí pokrytého systému |
Orientační pravidlo: pokud váš produkt potřebuje označení wheel mark, CRA se na něj nevztahuje; pokud jde na loď smluvně zadanou od července 2024, nejspíš se na něj vztahuje E27; pokud prodáváte software nebo připojené produkty v EU, počítejte s tím, že se na vás vztahuje CRA.
Co E26 a E27 požadují od dodavatelů
E27 je požadavek, který dopadá přímo na dodavatele výstroje. Oddíl 3.1 uvádí dokumenty, které dodavatel předkládá klasifikační společnosti pro počítačový systém, mimo jiné:
- Inventář aktiv (3.1.1): hardwarové komponenty s názvem, verzí a úrovní záplat jejich systémového softwaru, jako je operační systém a firmware, a softwarové komponenty, každá s hardwarem, na kterém je nainstalována, výrobcem, modelem nebo typem, účelem a verzí softwaru.
- Popis bezpečnostních funkcí (3.1.3) a postup jejich testování, pokyny pro bezpečnou konfiguraci a plány údržby, reakce na incidenty, obnovy a řízení změn.
- Dokumenty bezpečného životního cyklu vývoje (3.1.6), které popisují i to, jak se řeší aktualizace a záplatování softwaru.
Oddíl 4 stanoví požadované bezpečnostní funkce na základě vybraných systémových požadavků z IEC 62443-3-3, jako je autentizace a ochrana proti škodlivému kódu. Jde o funkce produktu.
Oddíl 5 vyžaduje bezpečný životní cyklus vývoje, který pokrývá požadavky, návrh, implementaci, ověření, vydání, údržbu a konec životnosti a je zaznamenán v dokumentu, který klasifikační společnost posuzuje. Musí zahrnovat opatření převzatá z IEC 62443-4-1: ochranu klíčů pro podepisování kódu (SM-8), dokumentaci bezpečnostních aktualizací pro uživatele (SUM-2), dokumentaci bezpečnostních aktualizací závislých komponent nebo operačního systému (SUM-3), autentické doručování aktualizací (SUM-4) a pokyny pro ochranu do hloubky a zpevnění (SG-1 až SG-3).
E26 uzavírá smyčku na úrovni lodi: inventář aktiv plavidla, tedy hardwaru a softwaru, s poli z inventáře E27 každého dodavatele se udržuje aktuální po celou dobu životnosti lodi a zaznamenávají se do něj změny softwaru a hardwaru, které mohou přinést nové zranitelnosti.
Co E27 neříká: SBOM nezmiňuje. SBOM pro každé vydání je nejpřesnější způsob, jak získat verze softwaru pro inventář a informace podle SUM-3 o závislých komponentách, ale tyto požadavky podporuje, sama jedním z nich není.
| Požadavek E26 nebo E27 | Co očekává klasifikační společnost nebo loděnice | Důkazy z buildu | Co zůstává na vás |
|---|---|---|---|
| Inventář aktiv E27 (3.1.1) | Každá softwarová komponenta s účelem a verzí a systémový software každé hardwarové komponenty | SBOM pro každé vydání se všemi komponentami a jejich verzemi | Na kterém hardwaru je která komponenta nainstalována, údaje o výrobci a modelu |
| Dokumentace aktualizací SUM-2 a SUM-3 | Zdokumentované bezpečnostní aktualizace, i pro závislé komponenty a operační systémy | Záznamy o zranitelnostech a historie buildů pro komponenty v každém vydání | Poznámky k aktualizacím a bezpečnostní upozornění, která posíláte uživatelům |
| SM-8 a SUM-4 | Chráněné klíče pro podepisování kódu a autentické doručování aktualizací | Žádné: CRACI software nepodepisuje | Váš proces podepisování a úložiště klíčů |
| Bezpečnostní funkce podle oddílu 4 | Autentizace, ochrana proti škodlivému kódu a další funkce produktu | Žádné: jde o funkce produktu | Návrh produktu a jeho testování |
| Dokument životního cyklu podle oddílu 5 | Posouzený popis toho, jak se v každé fázi řeší bezpečnost | Záznamy o tom, že fáze vydání je pod kontrolou: co každý build obsahoval a kam se mohl dostat | Sepsání dokumentu a provoz procesu |
| Inventář aktiv plavidla E26 | Inventář lodi, udržovaný aktuální po celou dobu její životnosti | Vaše exporty SBOM předané integrátorovi | Která verze je nainstalována na které lodi a předání loděnici nebo integrátorovi |
Proč je těžké udržet přehled o námořním softwaru
Lodě přežijí projekty. Plavidlo zůstává v provozu desítky let a péče o software na palubě trvá déle než projekt, který ho dodal, tým, který ho postavil, a často i vlastní produktová řada dodavatele.
Mnoho malých dodavatelů a integrátorů. Jediná loď nese software od desítek dodavatelů, sestavený integrátorem, a každé předání je příležitostí ztratit přehled o tom, co je v kterém vydání.
Palubní systémy nelze aktualizovat kdykoli. Aktualizace čekají na zastávku v přístavu, schválení klasifikační společností nebo okno údržby, takže staré verze zůstávají v provozu dlouho poté, co existuje oprava. Musíte vědět, které lodě stále používají kterou verzi.
Vzdálená místa, omezené připojení. Lodě na moři a vzdálené instalace jsou těžko dosažitelné, takže záznam o tom, co bylo nainstalováno, musí existovat na pevnině, z buildu, ne ze skenování lodi.
Tabulky jako hlavní evidence. Od výrobců námořního softwaru slýcháme, že SBOM a související záznamy žijí v mnoha ručně vedených tabulkách. S každým vydáním zastarávají.
Jak se připravit krok za krokem
Bezpečnostní funkce, jako je autentizace, patří do návrhu produktu. Níže uvedené kroky pokrývají důkazy o softwaru, který do něj vstupuje.
- Přiřaďte každý produkt k jeho režimu. U každého produktu rozhodněte, zda jde o výstroj MED, produkt podle CRA, produkt v působnosti E26 a E27, nebo o několik z toho. Plán důkazů z tohoto přiřazení vychází.
- Vytvářejte SBOM pro každé vydání. Zaznamenávejte, co vstupuje do každého vydání každého produktu, který sestavujete, včetně tranzitivních závislostí, aby inventář softwaru pocházel z buildu, a ne z paměti.
- Veďte inventář pro každou instalaci. Sledujte, která verze je nainstalována na které lodi a kdy se změnila. To je podklad pro inventář aktiv E27 a pro inventář aktiv plavidla E26 vedený integrátorem, který zaznamenává změny po celou dobu životnosti lodi.
- Monitorujte zranitelnosti a oznamujte je. Znovu kontrolujte dodaná vydání, jakmile se zveřejní nové zranitelnosti. U produktů v působnosti CRA platí od 11. září 2026 povinnost oznamovat aktivně zneužívané zranitelnosti a závažné incidenty.
- Nepouštějte do buildů balíčky se známými zranitelnostmi. Zablokujte build, který by dodal známou zranitelnost, aby se nevrátila s aktualizací závislosti.
- Dokumentujte bezpečnostní aktualizace pro zákazníky a integrátory. Sdělte zákazníkům a integrátorům, co každá bezpečnostní aktualizace opravuje, včetně oprav v závislých komponentách a operačním systému, jak očekávají SUM-2 a SUM-3.
Kam zapadá CRACI
CRACI spouští vaše buildy GitHub Actions na vlastních runnerech a zaznamenává, co vstupuje do každého vydání. Tento záznam je společným důkazem pro CRA, vaši dokumentaci E27 i otázky vašich zákazníků.
Každé vydání zaznamenané
Vaše buildy běží na runnerech GitHub Actions od CRACI s runs-on: craci a běhy se dál zobrazují v GitHubu. Během každého buildu CRACI zaznamenává každý balíček, který build stáhne, včetně npm a PyPI, se skrytými závislostmi, které neuvádí žádný lockfile, a se stavem úplnosti pro každý job. SBOM se exportují ve formátu CycloneDX nebo SPDX s tranzitivními závislostmi, deklarovanými licencemi a zranitelnostmi nalezenými v jejich komponentách: surovina pro softwarovou část inventáře aktiv E27. Více o SBOM z doby buildu.
Zranitelné balíčky zůstanou venku
Policy gate může zablokovat build, který obsahuje konkrétní CVE, a pravidla licenční politiky mohou zablokovat build kvůli licenci. Známý problém se zachytí v CI dřív, než se vydání dostane na loď.
Vězte, kterých vydání se to týká
CRACI průběžně znovu vyhodnocuje monitorované SBOM, jakmile se zveřejní nové zranitelnosti, historie buildů ukazuje, které buildy obsahovaly zranitelnou závislost, v rámci doby uchování vašeho plánu, a pohled inventáře ukazuje, které verze softwaru jsou nasazeny ve kterých produktech. Bezpečnostní týmy každý nález vytřídí a předají týmu, který odpovídá za opravu. U produktů v působnosti CRA připraví CRACI obsah oznámení podle CRA a podá je osoba ve vaší firmě přes Single Reporting Platform.
Build, který nemůže vyzradit vaše tajné klíče
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 fail-closed. S politikou výchozího zákazu je připojení k hostu, který build nepotřebuje, zablokováno a spustí výstrahu.
Kdy CRACI není řešením
CRACI je pro týmy, které vyvíjejí software. V těchto případech se nehodí:
- Není pro provozovatele a vlastníky lodí, kteří hledají monitorování palubní sítě, detekci narušení, soulad s E26 na úrovni plavidla nebo dokumentaci pro svůj systém řízení bezpečnosti. CRACI je pro ty, kdo software vyvíjejí, ne pro flotilu, která ho provozuje.
- Není programem CRA pro výrobce výstroje MED: výstroj s označením wheel mark je mimo CRA. CRACI přesto může zaznamenávat buildy softwaru, který za ní stojí, pro E27 a pro požadavky zákazníků, pokud běží v GitHub Actions.
- Není pro dodavatele, kteří nesestavují v GitHub Actions, kteří potřebují stroje pro buildy s Windows nebo macOS nebo runnery ve vlastním cloudovém účtu. CRACI dnes provozuje spravované linuxové runnery na evropské infrastruktuře; další systémy CI, runnery Windows a macOS a runnery hostované zákazníkem jsou v plánu vývoje.
- Není pro hardwarové kusovníky. CRACI zaznamenává software; hardwarové BOM nespravuje.
- Neposkytuje bezpečnostní funkce podle E27 ani schválení klasifikační společností. CRACI neimplementuje autentizaci, ochranu proti malwaru ani jiné funkce produktu, nepodepisuje software, nepíše váš dokument bezpečného životního cyklu vývoje a nejedná za vás s klasifikační společností.
- Není nástrojem pro metriky nápravy: CRACI nevykazuje průměrnou dobu nápravy ani termíny nápravy.
Námořní kybernetická bezpečnost vysvětlená
Časté otázky námořních dodavatelů k CRA, IACS UR E26 a E27 a pokynům IMO
Vztahuje se Cyber Resilience Act na lodní výstroj?
Ne na výstroj v působnosti směrnice o lodní výstroji 2014/90/EU. Článek 2 odst. 4 CRA ji výslovně vylučuje. Jde o výstroj s označením wheel mark, která potřebuje schválení státu vlajky podle úmluv IMO. Jiné připojené produkty a software prodávané pro lodě, například hotelové systémy, sítě pro posádku, senzory a software pro správu flotily instalovaný na palubě, mohou pod CRA stále spadat.
Které námořní produkty jsou z CRA vyloučeny?
Výstroj v působnosti směrnice o lodní výstroji: výstroj umístěná na palubě lodí EU, pro kterou úmluvy IMO vyžadují schválení státu vlajky, například radar, ECDIS, AIS, záznamníky údajů o plavbě, radiokomunikace, protipožární ochrana a záchranné prostředky. Pro svou položku zkontrolujte aktuální prováděcí seznam MED a u smíšených produktů nebo lodí pod jinou vlajkou si nechte udělat právní posouzení.
Co je IACS UR E27 a kdo ho musí splňovat?
UR E27 je jednotný požadavek Mezinárodního sdružení klasifikačních společností na kybernetickou odolnost palubních systémů a výstroje. Rev.1 platí pro lodě, jejichž stavba byla smluvně zadána 1. července 2024 nebo později, a je povinný pro osobní lodě, vysokorychlostní plavidla a nákladní lodě od 500 GT na mezinárodních plavbách a pro některé offshore jednotky. Dodavatelé pokrytých systémů ho splňují prostřednictvím klasifikační společnosti.
Co E26 a E27 vyžadují od dodavatelů výstroje?
E27 požaduje od dodavatelů dokumentaci, mimo jiné inventář aktiv, který uvádí každou softwarovou komponentu s její verzí, bezpečnostní funkce vycházející z IEC 62443-3-3 a bezpečný životní cyklus vývoje s opatřeními z IEC 62443-4-1, například dokumentací bezpečnostních aktualizací. E26 je požadavek na úrovni lodi: inventář aktiv plavidla používá stejná pole a udržuje se aktuální po celou dobu životnosti lodi.
Vyžaduje UR E27 SBOM?
Ne. E27 SBOM nezmiňuje. Požaduje inventář aktiv, který uvádí každou softwarovou komponentu s její verzí, a dokumentaci bezpečnostních aktualizací závislých komponent a operačního systému. SBOM pro každé vydání je nejpřesnější způsob, jak tyto informace získat, ale požadavkem E27 není.
Jsou pokyny IMO k řízení kybernetických rizik povinné?
Ne. Pokyny IMO k řízení kybernetických rizik v námořní dopravě jsou nezávazným vodítkem pro provozovatele lodí, revidovaným v květnu 2026. To, co se od provozovatelů očekává, vychází z rezoluce MSC.428(98), která je žádá, aby kybernetická rizika řešili ve svých systémech řízení bezpečnosti, a pokyny nyní žádají provozovatele, aby stanovili politiky bezpečnosti dodavatelského řetězce softwaru a hardwaru.
Vztahuje se CRA na software prodávaný lodním společnostem?
Obvykle ano, pokud se prodává na trhu EU jako produkt s digitálními prvky, instalovaný nebo stahovaný, a nejde o výstroj MED. Software nabízený čistě jako služba je mimo CRA, pokud nejde o zpracování dat na dálku pro produkt, i když na jeho poskytovatele se může vztahovat NIS2. Ověřte klasifikaci každého produktu.
Podívejte se, co vstupuje do vašich vydání
Rezervujte si demo a ukážeme vám každou komponentu, kterou vaše buildy stahují, a kterých vašich vydání se nová zranitelnost týká.
Rezervujte si demo