Cybersäkerhet för tillverkare av marin programvara och utrustning

Fartyg körs i dag på programvara från dussintals leverantörer, och klassregler och EU-rätt förväntar sig att varje leverantör vet vad som finns i dess programvara och håller den säker. CRACI kör dina GitHub Actions-byggen och registrerar varje komponent som går in i varje release.

Boka en demo

Vilka regler som gäller för vilka marina produkter

En marin leverantör omfattas av tre regelverk som överlappar men inte sammanfaller: EU:s produktlagstiftning, klassningsregler för nya fartyg och IMO:s vägledning för fartygsoperatörer. Ta reda på vilket som gäller för varje produkt innan du planerar underlaget.

CRA undantar utrustning som omfattas av direktivet om marin utrustning

Artikel 2(4) i Cyber Resilience Act, förordning (EU) 2024/2847, lyder: "Denna förordning ska inte tillämpas på utrustning som omfattas av tillämpningsområdet för direktiv 2014/90/EU." Det direktivet, direktivet om marin utrustning (MED), omfattar utrustning som placeras eller ska placeras ombord på ett EU-fartyg och för vilken IMO-konventionerna kräver godkännande av flaggstatens administration: den utrustning som bär wheel mark (rattmärket). Exempel är navigationsutrustning som radar, ECDIS, AIS och färddataregistratorer, radiokommunikationsutrustning, brandskydd och livräddningsutrustning. Kontrollera den gällande genomförandeförteckningen till MED för din egen produkt.

Vad som fortfarande omfattas av CRA

Produkter med digitala element som släpps ut på EU-marknaden och som inte är MED-utrustning: programvara för användning ombord och i land som säljs som produkt, installerad eller nedladdad; system för fartygsdrift, boende, catering och hotellverksamhet; servicesystem för besättning och passagerare; programvara för flott- och resehantering; IoT-sensorer och gateways ombord; övervaknings- och automationsutrustning som inte behöver flaggstatens godkännande. Programvara som tjänst omfattas inte av CRA i sig, om den inte är fjärrdatabehandling för en produkt, men NIS2 kan ändå gälla för leverantören.

Vissa fall kräver en juridisk bedömning snarare än en regel: utrustning av en rattmärkt typ som säljs till fartyg som inte för EU-flagg, och produkter som kombinerar MED-utrustning med programvarumoduler utanför MED.

IACS UR E26 och E27

De enhetliga kraven från International Association of Classification Societies gäller genom klassningen, inte genom EU-rätten. Rev.1 av båda gäller för fartyg med byggkontrakt tecknat den 1 juli 2024 eller senare. De är obligatoriska för passagerarfartyg och höghastighetsfartyg i internationell trafik, lastfartyg på 500 GT och uppåt i internationell trafik, mobila borrenheter till havs och vissa självgående offshoreenheter, och fungerar som vägledning för andra fartyg. En produkt som står utanför CRA på grund av MED kan ändå omfattas av E26 och E27, och tvärtom.

IMO

Resolution MSC.428(98) uppmanar fartygsoperatörer att hantera cyberrisker i sina säkerhetsorganisationssystem senast vid den första årliga verifieringen av företagets Document of Compliance efter den 1 januari 2021. IMO:s riktlinjer för hantering av maritima cyberrisker är icke-bindande vägledning på övergripande nivå för operatörer. Den senaste revideringen, från maj 2026, säger att hanteringen av cyberrisker bör ta hänsyn till tredjepartsleverantörer, inbyggda system och leveranskedjor för programvara och hårdvara, och uppmanar operatörer att införa policyer för säkerheten i leveranskedjan för programvara och hårdvara för kritiska system. Därför för operatörerna frågan vidare till sina leverantörer.

Produktexempel	Rattmärkt (MED)?	Cyber Resilience Act	IACS UR E26 och E27	Vad leverantören måste visa
ECDIS	Ja	Undantagen (artikel 2(4))	Ja, på nya fartyg som omfattas	MED-godkännande; E27-dokumentation och programvaruinventering
Maskinautomationssystem på ett nybyggt lastfartyg	Kontrollera	Ja, om det inte är MED-utrustning	Ja: framdrivning är ett system som omfattas	E27-dokumentation, inventering och säker utvecklingslivscykel; teknisk dokumentation och SBOM enligt CRA
Programvara för hotell- och cateringhantering	Nej	Ja, när den säljs som produkt	Kontrollera: E26 omfattar dess nätverksgränssnitt mot system som omfattas	SBOM och sårbarhetshantering för CRA
Nätverksutrustning för besättningens välfärd	Nej	Ja	Kontrollera: E26 omfattar dess gränssnitt mot system som omfattas	SBOM och sårbarhetshantering för CRA
Programvara för flotthantering som tjänst	Nej	Utanför, om den inte är fjärrdatabehandling för en produkt	Nej: den körs i land	Svar på operatörernas leverantörsenkäter; NIS2 kan gälla för leverantören
Sensorer för tillståndsövervakning ombord	Kontrollera	Ja, om de inte är MED-utrustning	Kontrollera: omfattas när de ingår i ett system som omfattas	SBOM enligt CRA; E27-dokumentation när de ingår i ett system som omfattas

Tumregeln: om din produkt behöver ett wheel mark gäller CRA inte för den; om den ska till ett fartyg med kontrakt från juli 2024 gäller E27 troligen; om du säljer programvara eller uppkopplade produkter i EU, utgå från att CRA gäller.

Vad E26 och E27 kräver av leverantörer

E27 är det krav som når utrustningsleverantörer direkt. Avsnitt 3.1 listar de dokument som en leverantör lämnar in till klassificeringssällskapet för ett datorbaserat system, bland annat:

En tillgångsinventering (3.1.1): hårdvarukomponenterna, med namn, version och patchnivå för deras systemprogramvara, som operativsystem och firmware, och programvarukomponenterna, var och en med den hårdvara den är installerad på, tillverkare, modell eller typ, syfte och programvaruversion.
En beskrivning av säkerhetsfunktionerna (3.1.3) och deras testförfarande, riktlinjer för säker konfiguration samt planer för underhåll, incidenthantering, återställning och ändringshantering.
Dokument om den säkra utvecklingslivscykeln (3.1.6), som också beskriver hur programvaruuppdateringar och patchning hanteras.

Avsnitt 4 anger de säkerhetsfunktioner som krävs, baserade på utvalda systemkrav från IEC 62443-3-3, till exempel autentisering och skydd mot skadlig kod. Det är funktioner i produkten.

Avsnitt 5 kräver en säker utvecklingslivscykel som omfattar krav, design, implementering, verifiering, release, underhåll och livets slut, beskriven i ett dokument som klassificeringssällskapet granskar. Den måste innehålla kontroller från IEC 62443-4-1: skydd av kodsigneringsnycklar (SM-8), dokumentation av säkerhetsuppdateringar för användare (SUM-2), dokumentation av säkerhetsuppdateringar för beroende komponenter eller operativsystem (SUM-3), autentisk leverans av uppdateringar (SUM-4) samt vägledning om djupförsvar och härdning (SG-1 till SG-3).

E26 sluter cirkeln på fartygsnivå: fartygets tillgångsinventering av hårdvara och programvara, med fälten från varje leverantörs E27-inventering, hålls uppdaterad under fartygets hela livslängd, och ändringar i programvara och hårdvara som kan medföra nya sårbarheter registreras i den.

Vad E27 inte säger: den nämner inte SBOM:er. En SBOM per release är det mest exakta sättet att ta fram programvaruversionerna till inventeringen och SUM-3-informationen om beroende komponenter, men den stöder de kraven snarare än att vara ett av dem.

Krav i E26 eller E27	Vad klassificeringssällskapet eller varvet förväntar sig	Underlag från bygget	Vad som ligger kvar hos dig
Tillgångsinventering i E27 (3.1.1)	Varje programvarukomponent med syfte och version, och systemprogramvaran i varje hårdvarukomponent	En SBOM per release, med varje komponent och dess version	Vilken hårdvara varje komponent är installerad på, uppgifter om tillverkare och modell
Uppdateringsdokumentation enligt SUM-2 och SUM-3	Dokumenterade säkerhetsuppdateringar, även för beroende komponenter och operativsystem	Sårbarhetsregistreringar och bygghistorik för komponenterna i varje release	Uppdateringsanteckningarna och säkerhetsmeddelandena du skickar till användare
SM-8 och SUM-4	Skyddade kodsigneringsnycklar och autentisk leverans av uppdateringar	Inget: CRACI signerar inte programvara	Din signeringsprocess och nyckellagring
Säkerhetsfunktioner enligt avsnitt 4	Autentisering, skydd mot skadlig kod och andra produktfunktioner	Inget: det här är produktfunktioner	Produktens design och testning
Livscykeldokument enligt avsnitt 5	En granskad beskrivning av hur säkerheten hanteras i varje fas	Registreringar som visar att releasefasen är kontrollerad: vad varje bygge innehöll och vad det kunde nå	Att skriva dokumentet och driva processen
Fartygets tillgångsinventering enligt E26	Fartygets inventering, uppdaterad under hela dess livslängd	Dina SBOM-exporter, överlämnade till integratören	Vilken version som är installerad på vilket fartyg, och överlämningen till varvet eller integratören

Varför det är svårt att hålla koll på marin programvara

Fartyg lever längre än projekt. Ett fartyg är i drift i årtionden, och supportbördan för programvaran ombord varar längre än projektet som levererade den, teamet som byggde den och ofta leverantörens egen produktlinje.

Många små leverantörer och integratörer. Ett enda fartyg bär programvara från dussintals leverantörer, sammansatt av en integratör, och varje överlämning är ett tillfälle att tappa bort vad som finns i varje release.

System ombord kan inte uppdateras när som helst. Uppdateringar får vänta på hamnanlöp, klassgodkännande eller ett underhållsfönster, så gamla versioner är kvar i drift långt efter att en åtgärd finns. Du behöver veta vilka fartyg som fortfarande kör vilken version.

Avlägsna platser, begränsad uppkoppling. Fartyg till sjöss och avlägsna installationer är svåra att nå, så registreringen av vad som installerades måste finnas i land, från bygget, inte från en skanning av fartyget.

Kalkylblad som registersystem. Vi hör från tillverkare av marin programvara att SBOM:er och tillhörande registreringar finns i många kalkylblad som sköts för hand. De blir inaktuella vid varje release.

Så förbereder du dig, steg för steg

Säkerhetsfunktioner som autentisering hör till produktens design. Stegen nedan gäller underlaget om programvaran som går in i den.

Koppla varje produkt till sitt regelverk. Avgör för varje produkt om den är MED-utrustning, en CRA-produkt, omfattas av E26 och E27, eller flera av dessa. Planen för underlaget följer av den kartläggningen.
Ta fram en SBOM för varje release. Registrera vad som går in i varje release av varje produkt du bygger, inklusive transitiva beroenden, så att programvaruinventeringen kommer från bygget och inte från minnet.
Ha en inventering per installation. Håll reda på vilken version som är installerad på vilket fartyg och när den ändrades. Det matar tillgångsinventeringen i E27 och integratörens tillgångsinventering för fartyget enligt E26, som registrerar ändringar under fartygets hela livslängd.
Bevaka sårbarheter och rapportera. Kontrollera levererade releaser på nytt när nya sårbarheter publiceras. För produkter som omfattas av CRA gäller rapportering av aktivt utnyttjade sårbarheter och allvarliga incidenter sedan den 11 september 2026.
Stoppa kända sårbara paket från att komma in i byggen. Blockera ett bygge som skulle leverera en känd sårbarhet, så att den inte kommer tillbaka genom en beroendeuppdatering.
Dokumentera säkerhetsuppdateringar för kunder och integratörer. Berätta för kunder och integratörer vad varje säkerhetsuppdatering åtgärdar, inklusive åtgärder i beroende komponenter och operativsystemet, som SUM-2 och SUM-3 förväntar sig.

Där CRACI passar in

CRACI kör dina GitHub Actions-byggen på egna runners och registrerar vad som går in i varje release. Den registreringen är det gemensamma underlaget bakom CRA, din E27-dokumentation och dina kunders frågor.

Varje release registrerad

Dina byggen körs på CRACI:s GitHub Actions-runners med runs-on: craci, och körningarna syns fortfarande i GitHub. Medan varje bygge körs registrerar CRACI varje paket det hämtar, npm och PyPI inräknade, med de dolda beroenden som ingen lockfile listar och en fullständighetsstatus för varje jobb. SBOM:er exporteras som CycloneDX eller SPDX med transitiva beroenden, deklarerade licenser och sårbarheterna som hittats i komponenterna: råmaterialet för programvarudelen av en tillgångsinventering enligt E27. Läs mer om SBOM:er från bygget.

Håll sårbara paket ute

Policykontroller kan blockera ett bygge som innehåller en specifik CVE, och licenspolicyregler kan blockera ett bygge på grund av en licens. Ett känt problem fångas i CI, innan releasen når ett fartyg.

Vet vilka releaser som påverkas

CRACI fortsätter att omvärdera bevakade SBOM:er när nya sårbarheter publiceras, och bygghistoriken visar vilka byggen som innehöll det sårbara beroendet, inom din plans lagringstid. Inventeringsvyn visar vilka programvaruversioner som är driftsatta i vilka produkter. Säkerhetsteam triagerar varje fynd och skickar det till teamet som äger åtgärden. För produkter som omfattas av CRA förbereder CRACI innehållet i CRA-anmälningarna, och en person i ditt företag lämnar in dem via Single Reporting Platform.

Ett bygge som inte kan läcka dina hemligheter

Varje jobb körs i sin egen isolerade virtuella maskin under en egress-policy som du kan ställa in på att neka som standard, som valideras innan jobbet startar och blockerar vid fel. Med en policy som nekar som standard blockeras en anslutning till en värd som bygget inte behöver, och den utlöser en varning.

När CRACI inte är svaret

CRACI är till för team som bygger programvara. Det passar inte i de här fallen:

Inte för fartygsoperatörer och redare som söker nätverksövervakning ombord, intrångsdetektering, E26-efterlevnad på fartygsnivå eller dokumentation för sitt säkerhetsorganisationssystem. CRACI är till för dem som bygger programvaran, inte för flottan som kör den.
Inte ett CRA-program för tillverkare av MED-utrustning: rattmärkt utrustning står utanför CRA. CRACI kan ändå registrera programvarubyggena bakom den för E27 och för kundförfrågningar, om de körs på GitHub Actions.
Inte för leverantörer som inte bygger på GitHub Actions, som behöver byggmaskiner med Windows eller macOS, eller som behöver runners i sitt eget molnkonto. CRACI kör i dag hanterade Linux-runners på europeisk infrastruktur; andra CI-system, Windows- och macOS-runners och kundhostade runners finns på roadmapen.
Inte för materialförteckningar för hårdvara. CRACI registrerar programvara; det hanterar inte hårdvaru-BOM:er.
Inte säkerhetsfunktionerna i E27 eller ett klassgodkännande. CRACI implementerar inte autentisering, skydd mot skadlig kod eller andra produktfunktioner, signerar inte programvara, skriver inte ditt dokument om säker utvecklingslivscykel och hanterar inte kontakterna med klassificeringssällskapet åt dig.
Inte ett verktyg för åtgärdsmått: CRACI rapporterar inte genomsnittlig tid till åtgärd eller tidsfrister för åtgärder.

Maritim cybersäkerhet, förklarat

Vanliga frågor om CRA, IACS UR E26 och E27 och IMO:s riktlinjer för marina leverantörer

Gäller Cyber Resilience Act för marin utrustning?

Inte för utrustning som omfattas av direktivet om marin utrustning, 2014/90/EU. Artikel 2(4) i CRA undantar den uttryckligen. Det gäller rattmärkt utrustning som behöver flaggstatens godkännande enligt IMO-konventionerna. Andra uppkopplade produkter och programvara som säljs för fartyg, som hotellsystem, besättningsnätverk, sensorer och flottprogramvara installerad ombord, kan fortfarande omfattas av CRA.

Vilka marina produkter är undantagna från CRA?

Utrustning som omfattas av direktivet om marin utrustning: utrustning ombord på EU-fartyg för vilken IMO-konventionerna kräver flaggstatens godkännande, som radar, ECDIS, AIS, färddataregistratorer, radiokommunikation, brandskydd och livräddningsutrustning. Kontrollera den gällande genomförandeförteckningen till MED för din produkt, och be om en juridisk bedömning för blandade produkter eller fartyg under andra flaggor.

Vad är IACS UR E27, och vem måste uppfylla det?

UR E27 är det enhetliga kravet från International Association of Classification Societies om cyberresiliens i system och utrustning ombord. Rev.1 gäller för fartyg med byggkontrakt tecknat den 1 juli 2024 eller senare och är obligatoriskt för passagerarfartyg, höghastighetsfartyg och lastfartyg på 500 GT och uppåt i internationell trafik samt vissa offshoreenheter. Leverantörer av system som omfattas uppfyller det via klassificeringssällskapet.

Vad kräver E26 och E27 av utrustningsleverantörer?

E27 kräver dokumentation från leverantörer, bland annat en tillgångsinventering som listar varje programvarukomponent med version, säkerhetsfunktioner hämtade från IEC 62443-3-3 och en säker utvecklingslivscykel med kontroller från IEC 62443-4-1, som dokumentation av säkerhetsuppdateringar. E26 är kravet på fartygsnivå: fartygets tillgångsinventering använder samma fält och hålls uppdaterad under fartygets hela livslängd.

Kräver UR E27 en SBOM?

Nej. E27 nämner inte SBOM:er. Det kräver en tillgångsinventering som listar varje programvarukomponent med version, och dokumentation av säkerhetsuppdateringar för beroende komponenter och operativsystem. En SBOM per release är det mest exakta sättet att ta fram den informationen, men det är inget krav i E27.

Är IMO:s riktlinjer för hantering av cyberrisker obligatoriska?

Nej. IMO:s riktlinjer för hantering av maritima cyberrisker är icke-bindande vägledning för fartygsoperatörer, reviderad i maj 2026. Vad som förväntas av operatörer kommer från resolution MSC.428(98), som uppmanar dem att hantera cyberrisker i sina säkerhetsorganisationssystem, och riktlinjerna uppmanar nu operatörer att införa policyer för säkerheten i leveranskedjan för programvara och hårdvara.

Gäller CRA för programvara som säljs till rederier?

Oftast, om den säljs på EU-marknaden som en produkt med digitala element, installerad eller nedladdad, och inte är MED-utrustning. Programvara som enbart erbjuds som tjänst omfattas inte av CRA, om den inte är fjärrdatabehandling för en produkt, men NIS2 kan gälla för leverantören. Kontrollera klassificeringen av varje produkt.

Se vad som går in i dina releaser

Boka en demo så visar vi varje komponent som dina byggen hämtar, och vilka av dina releaser som en ny sårbarhet påverkar.

Boka en demo