Cybersikkerhed til producenter af maritim software og udstyr
Skibe kører i dag på software fra snesevis af leverandører, og klasseregler og EU-ret forventer, at hver leverandør ved, hvad der er i dens software, og holder den sikker. CRACI kører dine GitHub Actions-builds og registrerer hver komponent, der går ind i hver release.
Hvilke regler der gælder for hvilke maritime produkter
En maritim leverandør er omfattet af tre regelsæt, der overlapper, men ikke falder sammen: EU's produktlovgivning, klassifikationsregler for nye skibe og IMO's vejledning til skibsoperatører. Find ud af, hvilket der gælder for hvert produkt, før du planlægger dokumentationen.
CRA undtager udstyr under direktivet om skibsudstyr
Artikel 2(4) i Cyber Resilience Act, forordning (EU) 2024/2847, lyder: "Denne forordning finder ikke anvendelse på udstyr, der er omfattet af anvendelsesområdet for direktiv 2014/90/EU." Det direktiv, direktivet om skibsudstyr (MED), omfatter udstyr, der anbringes eller skal anbringes om bord på et EU-skib, og som IMO-konventionerne kræver godkendt af flagstatens administration: udstyret med wheel mark. Eksempler er navigationsudstyr som radar, ECDIS, AIS og rejsedataregistreringsanlæg, radiokommunikationsudstyr, brandsikring og redningsudstyr. Tjek den gældende MED-gennemførelsesliste for dit eget udstyr.
Hvad der stadig er omfattet af CRA
Produkter med digitale elementer, der bringes i omsætning på EU-markedet, og som ikke er MED-udstyr: software til brug om bord og i land, der sælges som et produkt, installeret eller downloadet; systemer til skibsdrift, indkvartering, catering og hoteldrift; servicesystemer til besætning og passagerer; software til flåde- og rejsestyring; IoT-sensorer og gateways om bord; overvågnings- og automationsudstyr, der ikke kræver flagstatens godkendelse. Software as a service i sig selv er uden for CRA, medmindre det er fjerndatabehandling for et produkt, men NIS2 kan stadig gælde for udbyderen.
Nogle tilfælde kræver en juridisk vurdering frem for en regel: udstyr af en type med wheel mark, der sælges til skibe, som ikke fører EU-flag, og produkter, der kombinerer MED-udstyr med softwaremoduler uden for MED.
IACS UR E26 og E27
De ensartede krav fra International Association of Classification Societies gælder gennem klassifikationen, ikke gennem EU-retten. Rev.1 af begge gælder for skibe, der er kontraheret til bygning 1. juli 2024 eller senere. De er obligatoriske for passagerskibe og højhastighedsfartøjer i international fart, lastskibe på 500 GT og derover i international fart, mobile offshoreboreenheder og visse selvdrevne offshoreenheder, og de fungerer som vejledning for andre skibe. Et produkt, der er uden for CRA på grund af MED, kan stadig være omfattet af E26 og E27, og omvendt.
IMO
Resolution MSC.428(98) beder skibsoperatører om at håndtere cyberrisici i deres sikkerhedsledelsessystemer senest ved den første årlige verifikation af selskabets Document of Compliance efter 1. januar 2021. IMO's retningslinjer for håndtering af maritime cyberrisici er ikke-bindende vejledning på overordnet niveau til operatører. Den seneste revision fra maj 2026 siger, at håndteringen af cyberrisici bør tage højde for tredjepartsleverandører, indlejrede systemer og forsyningskæder for software og hardware, og beder operatører om at indføre politikker for sikkerheden i forsyningskæden for software og hardware til kritiske systemer. Derfor sender operatørerne spørgsmålet videre til deres leverandører.
| Produkteksempel | Wheel mark (MED)? | Cyber Resilience Act | IACS UR E26 og E27 | Hvad leverandøren skal vise |
|---|---|---|---|---|
| ECDIS | Ja | Undtaget (artikel 2(4)) | Ja, på nye skibe, der er omfattet | MED-godkendelse; E27-dokumentation og softwareinventar |
| Maskinautomationssystem på et nybygget lastskib | Tjek | Ja, medmindre det er MED-udstyr | Ja: fremdrift er et omfattet system | E27-dokumentation, inventar og sikker udviklingslivscyklus; teknisk dokumentation og SBOM efter CRA |
| Software til hotel- og cateringstyring | Nej | Ja, når den sælges som et produkt | Tjek: E26 dækker dens netværksgrænseflade til omfattede systemer | SBOM og håndtering af sårbarheder efter CRA |
| Netværksudstyr til besætningens velfærd | Nej | Ja | Tjek: E26 dækker dets grænseflade til omfattede systemer | SBOM og håndtering af sårbarheder efter CRA |
| Software til flådestyring som en tjeneste | Nej | Uden for, medmindre den er fjerndatabehandling for et produkt | Nej: den kører i land | Svar på operatørernes leverandørspørgeskemaer; NIS2 kan gælde for udbyderen |
| Sensorer til tilstandsovervågning om bord | Tjek | Ja, medmindre de er MED-udstyr | Tjek: omfattet, når de indgår i et omfattet system | SBOM efter CRA; E27-dokumentation, når de indgår i et omfattet system |
Tommelfingerreglen: Hvis dit produkt kræver et wheel mark, gælder CRA ikke for det; hvis det skal på et skib, der er kontraheret fra juli 2024, gælder E27 sandsynligvis; hvis du sælger software eller forbundne produkter i EU, så gå ud fra, at CRA gælder.
Hvad E26 og E27 kræver af leverandører
E27 er det krav, der rammer udstyrsleverandører direkte. Afsnit 3.1 opregner de dokumenter, en leverandør indsender til klassifikationsselskabet for et computerbaseret system, blandt andet:
- Et aktivinventar (3.1.1): hardwarekomponenterne med navn, version og patchniveau for deres systemsoftware, som operativsystem og firmware, og softwarekomponenterne, hver med den hardware, den er installeret på, producent, model eller type, formål og softwareversion.
- En beskrivelse af sikkerhedsfunktionerne (3.1.3) og deres testprocedure, retningslinjer for sikker konfiguration og planer for vedligeholdelse, hændelsesrespons, gendannelse og ændringsstyring.
- Dokumenter om den sikre udviklingslivscyklus (3.1.6), som også beskriver, hvordan softwareopdateringer og patchning håndteres.
Afsnit 4 fastsætter de krævede sikkerhedsfunktioner ud fra udvalgte systemkrav i IEC 62443-3-3, for eksempel autentificering og beskyttelse mod ondsindet kode. Det er funktioner i produktet.
Afsnit 5 kræver en sikker udviklingslivscyklus, der dækker krav, design, implementering, verifikation, release, vedligeholdelse og udfasning, beskrevet i et dokument, som klassifikationsselskabet gennemgår. Den skal omfatte kontroller fra IEC 62443-4-1: beskyttelse af kodesigneringsnøgler (SM-8), dokumentation af sikkerhedsopdateringer til brugere (SUM-2), dokumentation af sikkerhedsopdateringer til afhængige komponenter eller operativsystemer (SUM-3), autentisk levering af opdateringer (SUM-4) og vejledning om dybdeforsvar og hærdning (SG-1 til SG-3).
E26 lukker cirklen på skibsniveau: Skibets aktivinventar over hardware og software, med felterne fra hver leverandørs E27-inventar, holdes opdateret i hele skibets levetid, og ændringer i software og hardware, der kan introducere nye sårbarheder, registreres i det.
Hvad E27 ikke siger: Det nævner ikke SBOM'er. En SBOM pr. release er den mest præcise måde at fremskaffe softwareversionerne til inventaret og SUM-3-oplysningerne om afhængige komponenter, men den understøtter disse krav frem for at være et af dem.
| Krav i E26 eller E27 | Hvad klassifikationsselskabet eller værftet forventer | Dokumentation fra buildet | Hvad der forbliver hos dig |
|---|---|---|---|
| Aktivinventar i E27 (3.1.1) | Hver softwarekomponent med formål og version og systemsoftwaren i hver hardwarekomponent | En SBOM pr. release med hver komponent og dens version | Hvilken hardware hver komponent er installeret på, oplysninger om producent og model |
| Opdateringsdokumentation efter SUM-2 og SUM-3 | Dokumenterede sikkerhedsopdateringer, også for afhængige komponenter og operativsystemer | Sårbarhedsregistreringer og build-historik for komponenterne i hver release | De opdateringsnoter og advisories, du sender til brugerne |
| SM-8 og SUM-4 | Beskyttede kodesigneringsnøgler og autentisk levering af opdateringer | Ingen: CRACI signerer ikke software | Din signeringsproces og nøglelagring |
| Sikkerhedsfunktioner efter afsnit 4 | Autentificering, beskyttelse mod ondsindet kode og andre produktfunktioner | Ingen: det er produktfunktioner | Produktets design og test |
| Livscyklusdokument efter afsnit 5 | En gennemgået beskrivelse af, hvordan sikkerhed håndteres i hver fase | Registreringer, der viser, at releasefasen er kontrolleret: hvad hvert build indeholdt, og hvad det kunne nå | At skrive dokumentet og drive processen |
| Skibets aktivinventar efter E26 | Skibets inventar, holdt opdateret i hele dets levetid | Dine SBOM-eksporter, overdraget til integratoren | Hvilken version der er installeret på hvilket skib, og overdragelsen til værftet eller integratoren |
Derfor er det svært at holde styr på maritim software
Skibe lever længere end projekter. Et skib er i drift i årtier, og supportbyrden for softwaren om bord varer længere end det projekt, der leverede den, det team, der byggede den, og ofte leverandørens egen produktlinje.
Mange små leverandører og integratorer. Et enkelt skib har software fra snesevis af leverandører, samlet af en integrator, og hver overdragelse er en lejlighed til at miste overblikket over, hvad der er i hver release.
Systemer om bord kan ikke opdateres efter behag. Opdateringer venter på havneanløb, klassegodkendelse eller et vedligeholdelsesvindue, så gamle versioner forbliver i drift længe efter, at en rettelse findes. Du skal vide, hvilke skibe der stadig kører hvilken version.
Fjerntliggende steder, begrænset forbindelse. Skibe på havet og fjerntliggende installationer er svære at nå, så registreringen af, hvad der blev installeret, skal findes i land, fra buildet, ikke fra en scanning af skibet.
Regneark som registreringssystem. Vi hører fra producenter af maritim software, at SBOM'er og tilhørende registreringer ligger i mange regneark, der vedligeholdes i hånden. De bliver forældede for hver release.
Sådan forbereder du dig, trin for trin
Sikkerhedsfunktioner som autentificering hører til produktets design. Trinene nedenfor dækker dokumentationen for den software, der går ind i det.
- Kobl hvert produkt til dets regelsæt. Afgør for hvert produkt, om det er MED-udstyr, et CRA-produkt, omfattet af E26 og E27 eller flere af delene. Planen for dokumentationen følger af den kortlægning.
- Lav en SBOM for hver release. Registrér, hvad der går ind i hver release af hvert produkt, du bygger, inklusive transitive afhængigheder, så softwareinventaret kommer fra buildet og ikke fra hukommelsen.
- Hav et inventar pr. installation. Hold styr på, hvilken version der er installeret på hvilket skib, og hvornår den blev ændret. Det fodrer aktivinventaret i E27 og integratorens aktivinventar for skibet efter E26, som registrerer ændringer i hele skibets levetid.
- Overvåg sårbarheder, og rapportér. Tjek leverede releases igen, når nye sårbarheder offentliggøres. For produkter, der er omfattet af CRA, har rapportering af aktivt udnyttede sårbarheder og alvorlige hændelser gældt siden 11. september 2026.
- Stop kendte sårbare pakker, før de kommer ind i builds. Blokér et build, der ville levere en kendt sårbarhed, så den ikke kommer tilbage via en opdatering af en afhængighed.
- Dokumentér sikkerhedsopdateringer for kunder og integratorer. Fortæl kunder og integratorer, hvad hver sikkerhedsopdatering retter, inklusive rettelser i afhængige komponenter og operativsystemet, som SUM-2 og SUM-3 forventer.
Hvor CRACI passer ind
CRACI kører dine GitHub Actions-builds på sine egne runnere og registrerer, hvad der går ind i hver release. Den registrering er den fælles dokumentation bag CRA, din E27-dokumentation og dine kunders spørgsmål.
Hver release registreret
Dine builds kører på CRACI's GitHub Actions-runnere med runs-on: craci, og kørslerne vises stadig i GitHub. Mens hvert build kører, registrerer CRACI hver pakke, det henter, inklusive npm og PyPI, med de skjulte afhængigheder, som ingen lockfile angiver, og en fuldstændighedsstatus for hvert job. SBOM'er eksporteres som CycloneDX eller SPDX med transitive afhængigheder, erklærede licenser og de sårbarheder, der er fundet i komponenterne: råmaterialet til softwaredelen af et aktivinventar efter E27. Læs mere om SBOM'er fra buildet.
Hold sårbare pakker ude
Policy gates kan blokere et build, der indeholder en bestemt CVE, og licenspolitikregler kan blokere et build på grund af en licens. Et kendt problem fanges i CI, før releasen når et skib.
Vid, hvilke releases der er ramt
CRACI bliver ved med at genvurdere overvågede SBOM'er, efterhånden som nye sårbarheder offentliggøres, og build-historikken viser, hvilke builds der indeholdt den sårbare afhængighed, inden for din plans opbevaringsperiode. Inventaroversigten viser, hvilke softwareversioner der er udrullet til hvilke produkter. Sikkerhedsteams triagerer hvert fund og sender det til det team, der ejer rettelsen. For produkter, der er omfattet af CRA, forbereder CRACI indholdet af CRA-underretningerne, og en person i din virksomhed indsender dem via Single Reporting Platform.
Et build, der ikke kan lække dine secrets
Hvert job kører i sin egen isolerede virtuelle maskine under en egress-politik, som du kan sætte til default deny, og som valideres, før jobbet starter, og blokerer ved fejl (fail closed). Med en default-deny-politik blokeres en forbindelse til en host, som buildet ikke har brug for, og den udløser en alarm.
Når CRACI ikke er svaret
CRACI er til teams, der bygger software. Det passer ikke i disse tilfælde:
- Ikke til skibsoperatører og rederier, der søger netværksovervågning om bord, indtrængningsdetektion, E26-overholdelse på skibsniveau eller dokumentation til deres sikkerhedsledelsessystem. CRACI er til dem, der bygger softwaren, ikke til den flåde, der kører den.
- Ikke et CRA-program for producenter af MED-udstyr: Udstyr med wheel mark er uden for CRA. CRACI kan stadig registrere de software-builds, der ligger bag det, til E27 og til kundeforespørgsler, hvis de kører på GitHub Actions.
- Ikke til leverandører, der ikke bygger på GitHub Actions, som har brug for build-maskiner med Windows eller macOS, eller som har brug for runnere i deres egen cloud-konto. CRACI kører i dag administrerede Linux-runnere på europæisk infrastruktur; andre CI-systemer, Windows- og macOS-runnere og kundehostede runnere er på roadmappen.
- Ikke til styklister for hardware. CRACI registrerer software; det håndterer ikke hardware-BOM'er.
- Ikke sikkerhedsfunktionerne i E27 eller en klassegodkendelse. CRACI implementerer ikke autentificering, malwarebeskyttelse eller andre produktfunktioner, signerer ikke software, skriver ikke dit dokument om sikker udviklingslivscyklus og håndterer ikke kontakten til klassifikationsselskabet for dig.
- Ikke et værktøj til afhjælpningsmålinger: CRACI rapporterer ikke gennemsnitlig tid til afhjælpning eller frister for afhjælpning.
Maritim cybersikkerhed forklaret
Almindelige spørgsmål om CRA, IACS UR E26 og E27 og IMO's retningslinjer for maritime leverandører
Gælder Cyber Resilience Act for skibsudstyr?
Ikke for udstyr, der er omfattet af direktivet om skibsudstyr, 2014/90/EU. Artikel 2(4) i CRA undtager det udtrykkeligt. Det dækker udstyr med wheel mark, der kræver flagstatens godkendelse efter IMO-konventionerne. Andre forbundne produkter og software, der sælges til skibe, som hotelsystemer, besætningsnetværk, sensorer og flådesoftware installeret om bord, kan stadig være omfattet af CRA.
Hvilke maritime produkter er undtaget fra CRA?
Udstyr, der er omfattet af direktivet om skibsudstyr: udstyr om bord på EU-skibe, som IMO-konventionerne kræver godkendt af flagstaten, som radar, ECDIS, AIS, rejsedataregistreringsanlæg, radiokommunikation, brandsikring og redningsudstyr. Tjek den gældende MED-gennemførelsesliste for dit udstyr, og få en juridisk vurdering af blandede produkter eller skibe under andre flag.
Hvad er IACS UR E27, og hvem skal overholde det?
UR E27 er det ensartede krav fra International Association of Classification Societies om cyberrobusthed i systemer og udstyr om bord. Rev.1 gælder for skibe, der er kontraheret til bygning 1. juli 2024 eller senere, og er obligatorisk for passagerskibe, højhastighedsfartøjer og lastskibe på 500 GT og derover i international fart samt visse offshoreenheder. Leverandører af omfattede systemer overholder det via klassifikationsselskabet.
Hvad kræver E26 og E27 af udstyrsleverandører?
E27 kræver dokumentation fra leverandører, herunder et aktivinventar, der viser hver softwarekomponent med version, sikkerhedsfunktioner hentet fra IEC 62443-3-3 og en sikker udviklingslivscyklus med kontroller fra IEC 62443-4-1, som dokumentation af sikkerhedsopdateringer. E26 er kravet på skibsniveau: Skibets aktivinventar bruger de samme felter og holdes opdateret i hele skibets levetid.
Kræver UR E27 en SBOM?
Nej. E27 nævner ikke SBOM'er. Det kræver et aktivinventar, der viser hver softwarekomponent med version, og dokumentation af sikkerhedsopdateringer til afhængige komponenter og operativsystemer. En SBOM pr. release er den mest præcise måde at fremskaffe de oplysninger på, men det er ikke et krav i E27.
Er IMO's retningslinjer for håndtering af cyberrisici obligatoriske?
Nej. IMO's retningslinjer for håndtering af maritime cyberrisici er ikke-bindende vejledning til skibsoperatører, revideret i maj 2026. Det, der forventes af operatører, kommer fra resolution MSC.428(98), som beder dem om at håndtere cyberrisici i deres sikkerhedsledelsessystemer, og retningslinjerne beder nu operatører om at fastsætte politikker for sikkerheden i forsyningskæden for software og hardware.
Gælder CRA for software, der sælges til rederier?
Som regel, hvis den sælges på EU-markedet som et produkt med digitale elementer, installeret eller downloadet, og ikke er MED-udstyr. Software, der udelukkende tilbydes som en tjeneste, er uden for CRA, medmindre det er fjerndatabehandling for et produkt, men NIS2 kan gælde for udbyderen. Tjek klassificeringen af hvert produkt.
Se, hvad der går ind i dine releases
Book en demo, så viser vi hver komponent, dine builds henter, og hvilke af dine releases en ny sårbarhed rammer.
Book en demo