Cybersikkerhet for produsenter av maritim programvare og utstyr
Skip går nå på programvare fra dusinvis av leverandører, og klasseregler og EU-lovgivning forventer at hver leverandør vet hva som er i programvaren sin og holder den sikker. CRACI kjører GitHub Actions-byggene dine og registrerer hver komponent som går inn i hver utgivelse.
Hvilke regler som gjelder for hvilke maritime produkter
En maritim leverandør må forholde seg til tre regelverk som overlapper uten å falle sammen: EUs produktlovgivning, klassifikasjonsregler for nye skip og IMOs veiledning for rederier. Finn ut hva som gjelder for hvert produkt før du planlegger bevisene.
CRA unntar utstyr under direktivet om skipsutstyr
Artikkel 2(4) i Cyber Resilience Act, forordning (EU) 2024/2847, sier: «Denne forordningen gjelder ikke for utstyr som omfattes av direktiv 2014/90/EU.» Det direktivet, direktivet om skipsutstyr (Marine Equipment Directive, MED), omfatter utstyr som er plassert eller skal plasseres om bord på et EU-skip, og som IMO-konvensjonene krever at flaggstatens administrasjon godkjenner: utstyret med wheel mark (rattmerket). Eksempler er navigasjonsutstyr som radar, ECDIS, AIS og ferdsskrivere (VDR), radiokommunikasjonsutstyr, brannvern og livredningsutstyr. Sjekk den gjeldende gjennomføringslisten under MED for ditt eget utstyr.
Hva som fortsatt er innenfor CRAs virkeområde
Produkter med digitale elementer som bringes i omsetning på EU-markedet og ikke er MED-utstyr: programvare om bord og på land som selges som et produkt, installert eller nedlastet; systemer for skipsdrift, innkvartering, forpleining og hotelldrift; tjenestesystemer for mannskap og passasjerer; programvare for flåte- og reisestyring; IoT-sensorer og gatewayer om bord; overvåkings- og automasjonsutstyr som ikke trenger flaggstatens godkjenning. Programvare som en tjeneste (SaaS) alene er utenfor CRA med mindre den er fjernbehandling av data for et produkt, men NIS2 kan likevel gjelde for leverandøren av den.
Noen tilfeller krever en juridisk vurdering snarere enn en regel: utstyr av en type med wheel mark som selges til skip som ikke fører EU-flagg, og produkter som kombinerer MED-utstyr med programvaremoduler utenfor MED.
IACS UR E26 og E27
De felles kravene (unified requirements) fra International Association of Classification Societies gjelder gjennom klassifikasjon, ikke gjennom EU-lovgivning. Rev.1 av begge gjelder for skip med byggekontrakt inngått 1. juli 2024 eller senere. De er obligatoriske for passasjerskip og hurtiggående fartøy i internasjonal fart, lasteskip på 500 GT og over i internasjonal fart, flyttbare boreinnretninger og visse selvdrevne offshoreenheter, og fungerer som veiledning for andre skip. Et produkt som er utenfor CRA på grunn av MED, kan likevel være innenfor virkeområdet til E26 og E27, og omvendt.
IMO
Resolusjon MSC.428(98) ber rederier om å håndtere cyberrisiko i sikkerhetsstyringssystemene sine senest ved den første årlige verifikasjonen av selskapets Document of Compliance etter 1. januar 2021. IMOs retningslinjer for håndtering av maritim cyberrisiko er ikke-bindende veiledning på overordnet nivå for rederier. Den siste revisjonen, fra mai 2026, sier at håndteringen av cyberrisiko bør ta hensyn til tredjepartsleverandører, innebygde systemer og leverandørkjedene for programvare og maskinvare, og ber rederiene fastsette retningslinjer for sikkerheten i leverandørkjedene for programvare og maskinvare til kritiske systemer. Derfor sender rederiene spørsmålet videre til leverandørene sine.
| Produkteksempel | Wheel mark (MED)? | Cyber Resilience Act | IACS UR E26 og E27 | Hva leverandøren må vise |
|---|---|---|---|---|
| ECDIS | Ja | Unntatt (artikkel 2(4)) | Ja, på nye skip innenfor virkeområdet | MED-godkjenning; E27-dokumentasjon og programvareinventar |
| Motorautomasjonssystem på et nybygget lasteskip | Sjekk | Ja, med mindre det er MED-utstyr | Ja: fremdrift er et omfattet system | E27-dokumentasjon, inventar og sikker utviklingslivssyklus; teknisk dokumentasjon og SBOM for CRA |
| Programvare for hotell- og forpleiningsdrift | Nei | Ja, når den selges som et produkt | Sjekk: E26 omfatter nettverksgrensesnittet mot omfattede systemer | SBOM og sårbarhetshåndtering for CRA |
| Nettverksutstyr for mannskapets velferd | Nei | Ja | Sjekk: E26 omfatter grensesnittet mot omfattede systemer | SBOM og sårbarhetshåndtering for CRA |
| Flåtestyringsprogramvare som tjeneste | Nei | Utenfor, med mindre den er fjernbehandling av data for et produkt | Nei: den kjører på land | Svar på rederienes leverandørspørreskjemaer; NIS2 kan gjelde for leverandøren |
| Sensorer for tilstandsovervåking om bord | Sjekk | Ja, med mindre de er MED-utstyr | Sjekk: innenfor virkeområdet når de er del av et omfattet system | SBOM for CRA; E27-dokumentasjon når de er del av et omfattet system |
Tommelfingerregelen: Trenger produktet ditt wheel mark, gjelder ikke CRA for det; skal det på et skip med kontrakt fra juli 2024, gjelder E27 sannsynligvis; selger du programvare eller tilkoblede produkter i EU, bør du gå ut fra at CRA gjelder.
Hva E26 og E27 krever av leverandører
E27 er kravet som når utstyrsleverandørene direkte. Avsnitt 3.1 lister opp dokumentene en leverandør sender inn til klasseselskapet for et datamaskinbasert system, blant dem:
- Et inventar over eiendeler (3.1.1): maskinvarekomponentene, med navn, versjon og patchnivå for systemprogramvaren deres, som operativsystemet og firmwaren, og programvarekomponentene, hver med maskinvaren den er installert på, produsenten, modell eller type, formål og programvareversjon.
- En beskrivelse av sikkerhetsfunksjonene (3.1.3) og testprosedyren for dem, retningslinjer for sikkerhetskonfigurasjon og planer for vedlikehold, hendelseshåndtering, gjenoppretting og endringsstyring.
- Dokumenter for sikker utviklingslivssyklus (3.1.6), som også beskriver hvordan programvareoppdateringer og patching håndteres.
Avsnitt 4 fastsetter de påkrevde sikkerhetsfunksjonene, basert på utvalgte systemkrav fra IEC 62443-3-3, som autentisering og beskyttelse mot ondsinnet kode. Dette er funksjoner i produktet.
Avsnitt 5 krever en sikker utviklingslivssyklus som dekker krav, design, implementering, verifikasjon, utgivelse, vedlikehold og levetidens slutt, nedfelt i et dokument som klasseselskapet gjennomgår. Den må inneholde kontroller hentet fra IEC 62443-4-1: beskyttelse av kodesigneringsnøkler (SM-8), dokumentasjon av sikkerhetsoppdateringer for brukere (SUM-2), dokumentasjon av sikkerhetsoppdateringer for avhengige komponenter eller operativsystemet (SUM-3), autentisk levering av oppdateringer (SUM-4) og veiledning om dybdeforsvar og herding (SG-1 til SG-3).
E26 lukker sløyfen på skipsnivå: skipets inventar over maskinvare og programvare, med feltene fra hver leverandørs E27-inventar, holdes oppdatert gjennom hele skipets levetid, og endringer i programvare og maskinvare som kan introdusere nye sårbarheter, registreres i det.
Hva E27 ikke sier: det nevner ikke SBOM-er. En SBOM per utgivelse er den mest presise måten å fremskaffe programvareversjonene til inventaret og SUM-3-informasjonen om avhengige komponenter på, men den støtter disse kravene i stedet for å være ett av dem.
| Krav i E26 eller E27 | Hva klasseselskapet eller verftet forventer | Bevis fra bygget | Hva som forblir hos deg |
|---|---|---|---|
| E27-inventar over eiendeler (3.1.1) | Hver programvarekomponent med formål og versjon, og systemprogramvaren til hver maskinvarekomponent | En SBOM per utgivelse, med hver komponent og versjonen av den | Hvilken maskinvare hver komponent er installert på, og opplysninger om produsent og modell |
| Oppdateringsdokumentasjon etter SUM-2 og SUM-3 | Dokumenterte sikkerhetsoppdateringer, også for avhengige komponenter og operativsystemer | Sårbarhetsoppføringer og byggehistorikk for komponentene i hver utgivelse | Oppdateringsnotatene og varslene du sender til brukere |
| SM-8 og SUM-4 | Beskyttede kodesigneringsnøkler og autentisk levering av oppdateringer | Ingen: CRACI signerer ikke programvare | Signeringsprosessen og nøkkellagringen din |
| Sikkerhetsfunksjoner i avsnitt 4 | Autentisering, beskyttelse mot ondsinnet kode og andre produktfunksjoner | Ingen: dette er produktfunksjoner | Produktdesignet og testingen av det |
| Livssyklusdokument i avsnitt 5 | En gjennomgått beskrivelse av hvordan sikkerhet håndteres i hver fase | Dokumentasjon på at utgivelsesfasen er kontrollert: hva hvert bygg inneholdt og hva det kunne nå | Å skrive dokumentet og drive prosessen |
| E26-inventar for skipet | Skipets inventar, holdt oppdatert gjennom hele levetiden | SBOM-eksportene dine, overlevert til integratoren | Hvilken versjon som er installert på hvilket skip, og overleveringen til verftet eller integratoren |
Hvorfor det er vanskelig å holde oversikt over maritim programvare
Skip lever lenger enn prosjekter. Et fartøy er i drift i flere tiår, og støttebyrden for programvaren om bord varer lenger enn prosjektet som leverte den, teamet som bygget den og ofte leverandørens egen produktlinje.
Mange små leverandører og integratorer. Et enkelt skip har programvare fra dusinvis av leverandører, satt sammen av en integrator, og hver overlevering er en mulighet til å miste oversikten over hva som er i hver utgivelse.
Systemer om bord kan ikke oppdateres når som helst. Oppdateringer venter på havneanløp, klassegodkjenning eller et vedlikeholdsvindu, så gamle versjoner blir værende i drift lenge etter at en retting finnes. Du må vite hvilke skip som fortsatt kjører hvilken versjon.
Avsidesliggende steder, begrenset tilkobling. Skip til sjøs og avsidesliggende installasjoner er vanskelige å nå, så oversikten over hva som ble installert, må finnes på land, fra bygget, ikke fra en skanning av skipet.
Regneark som autoritativ kilde. Vi hører fra produsenter av maritim programvare at SBOM-er og tilhørende dokumentasjon ligger i mange regneark som oppdateres for hånd. De blir utdaterte for hver utgivelse.
Slik forbereder du deg, steg for steg
Sikkerhetsfunksjoner som autentisering hører til produktets design. Stegene nedenfor dekker bevisene om programvaren som går inn i det.
- Knytt hvert produkt til sitt regelverk. Avgjør for hvert produkt om det er MED-utstyr, et CRA-produkt, innenfor virkeområdet til E26 og E27, eller flere av disse. Planen for bevis følger av den oversikten.
- Lag en SBOM for hver utgivelse. Registrer hva som går inn i hver utgivelse av hvert produkt du bygger, inkludert transitive avhengigheter, så programvareinventaret kommer fra bygget og ikke fra hukommelsen.
- Før et inventar per installasjon. Hold oversikt over hvilken versjon som er installert på hvilket skip, og når den ble endret. Dette mater E27-inventaret og integratorens E26-inventar for skipet, som registrerer endringer gjennom hele skipets levetid.
- Overvåk sårbarheter og rapporter. Sjekk leverte utgivelser på nytt når nye sårbarheter publiseres. For produkter innenfor CRAs virkeområde har rapportering av aktivt utnyttede sårbarheter og alvorlige hendelser gjeldt siden 11. september 2026.
- Hold kjente sårbare pakker ute av byggene. Blokker et bygg som ville levert en kjent sårbarhet, så den ikke kommer tilbake gjennom en avhengighetsoppdatering.
- Dokumenter sikkerhetsoppdateringer for kunder og integratorer. Fortell kunder og integratorer hva hver sikkerhetsoppdatering retter, inkludert rettinger i avhengige komponenter og operativsystemet, slik SUM-2 og SUM-3 forventer.
Hvor CRACI passer inn
CRACI kjører GitHub Actions-byggene dine på egne runnere og registrerer hva som går inn i hver utgivelse. Den registreringen er det felles beviset bak CRA, E27-dokumentasjonen din og spørsmålene fra kundene dine.
Hver utgivelse registrert
Byggene dine kjører på CRACIs GitHub Actions-runnere med runs-on: craci, og kjøringene vises fortsatt i GitHub. Mens hvert bygg kjører, registrerer CRACI hver pakke det henter inn, også fra npm og PyPI, med de skjulte avhengighetene ingen lockfile viser og en fullstendighetsstatus for hver jobb. SBOM-er eksporteres som CycloneDX eller SPDX med transitive avhengigheter, deklarerte lisenser og sårbarhetene som er funnet i komponentene: råmaterialet til programvaredelen av et E27-inventar. Mer om SBOM-er fra bygget.
Hold sårbare pakker ute
Policy gates kan blokkere et bygg som inneholder en bestemt CVE, og lisensregler kan blokkere et bygg på grunn av en lisens. Et kjent problem fanges opp i CI, før utgivelsen når et skip.
Vit hvilke utgivelser som er berørt
CRACI fortsetter å vurdere overvåkede SBOM-er på nytt etter hvert som nye sårbarheter publiseres, og byggehistorikken viser hvilke bygg som inneholdt den sårbare avhengigheten, innenfor oppbevaringstiden i planen din. Inventarvisningen viser hvilke programvareversjoner som er rullet ut til hvilke produkter. Sikkerhetsteam prioriterer hvert funn og ruter det til teamet som eier rettingen. For produkter som omfattes av CRA, forbereder CRACI innholdet i CRA-varslene, og en person i bedriften din sender dem inn via Single Reporting Platform.
Et bygg som ikke kan lekke hemmelighetene dine
Hver jobb kjører i sin egen isolerte virtuelle maskin under en egress-policy du kan sette til default deny, som valideres før jobben starter og blokkerer ved feil (fail closed). Med en default deny-policy blir en tilkobling til en vert bygget ikke trenger, blokkert og utløser et varsel.
Når CRACI ikke er svaret
CRACI er for team som bygger programvare. Det passer ikke i disse tilfellene:
- Ikke for rederier og skipseiere som ser etter nettverksovervåking om bord, inntrengingsdeteksjon, E26-samsvar på skipsnivå eller dokumentasjon til sikkerhetsstyringssystemet sitt. CRACI er for dem som bygger programvaren, ikke for flåten som kjører den.
- Ikke et CRA-program for produsenter av MED-utstyr: utstyr med wheel mark er utenfor CRA. CRACI kan likevel registrere programvarebyggene bak det for E27 og for kundeforespørsler, hvis de kjører på GitHub Actions.
- Ikke for leverandører som ikke bygger på GitHub Actions, som trenger byggemaskiner med Windows eller macOS, eller som trenger runnere i sin egen skykonto. CRACI kjører administrerte Linux-runnere på europeisk infrastruktur i dag; andre CI-systemer, Windows- og macOS-runnere og kundehostede runnere står på veikartet.
- Ikke for materiallister for maskinvare. CRACI registrerer programvare; det håndterer ikke maskinvare-BOM-er.
- Ikke sikkerhetsfunksjonene i E27 eller en klassegodkjenning. CRACI implementerer ikke autentisering, beskyttelse mot skadevare eller andre produktfunksjoner, signerer ikke programvare, skriver ikke dokumentet for den sikre utviklingslivssyklusen din og har ikke kontakt med klasseselskapet på dine vegne.
- Ikke et verktøy for utbedringsmålinger: CRACI rapporterer ikke gjennomsnittlig tid til utbedring eller tidsfrister for utbedring.
Maritim cybersikkerhet, forklart
Vanlige spørsmål om CRA, IACS UR E26 og E27 og IMOs retningslinjer for maritime leverandører
Gjelder Cyber Resilience Act for skipsutstyr?
Ikke for utstyr som omfattes av direktivet om skipsutstyr, 2014/90/EU. Artikkel 2(4) i CRA unntar det uttrykkelig. Det omfatter utstyr med wheel mark som trenger flaggstatens godkjenning under IMO-konvensjonene. Andre tilkoblede produkter og programvare som selges til skip, som hotellsystemer, mannskapsnett, sensorer og flåteprogramvare installert om bord, kan likevel omfattes av CRA.
Hvilke maritime produkter er unntatt fra CRA?
Utstyr som omfattes av direktivet om skipsutstyr: utstyr plassert om bord på EU-skip som IMO-konvensjonene krever flaggstatens godkjenning for, som radar, ECDIS, AIS, ferdsskrivere, radiokommunikasjon, brannvern og livredningsutstyr. Sjekk den gjeldende gjennomføringslisten under MED for ditt utstyr, og få en juridisk vurdering for blandede produkter eller skip under andre flagg.
Hva er IACS UR E27, og hvem må oppfylle det?
UR E27 er det felles kravet fra International Association of Classification Societies om cyberrobusthet i systemer og utstyr om bord. Rev.1 gjelder for skip med byggekontrakt inngått 1. juli 2024 eller senere, og er obligatorisk for passasjerskip, hurtiggående fartøy og lasteskip på 500 GT og over i internasjonal fart, og for visse offshoreenheter. Leverandører av omfattede systemer oppfyller det gjennom klasseselskapet.
Hva krever E26 og E27 av utstyrsleverandører?
E27 krever dokumentasjon fra leverandører, blant annet et inventar som lister opp hver programvarekomponent med versjon, sikkerhetsfunksjoner hentet fra IEC 62443-3-3 og en sikker utviklingslivssyklus med kontroller fra IEC 62443-4-1, som dokumentasjon av sikkerhetsoppdateringer. E26 er kravet på skipsnivå: skipets inventar bruker de samme feltene og holdes oppdatert gjennom hele skipets levetid.
Krever UR E27 en SBOM?
Nei. E27 nevner ikke SBOM-er. Det krever et inventar som lister opp hver programvarekomponent med versjon, og dokumentasjon av sikkerhetsoppdateringer for avhengige komponenter og operativsystemet. En SBOM per utgivelse er den mest presise måten å fremskaffe den informasjonen på, men den er ikke et krav i E27.
Er IMOs retningslinjer for håndtering av cyberrisiko bindende?
Nei. IMOs retningslinjer for håndtering av maritim cyberrisiko er ikke-bindende veiledning for rederier, revidert i mai 2026. Det som forventes av rederiene, kommer fra resolusjon MSC.428(98), som ber dem håndtere cyberrisiko i sikkerhetsstyringssystemene sine, og retningslinjene ber nå rederiene fastsette retningslinjer for sikkerheten i leverandørkjedene for programvare og maskinvare.
Gjelder CRA for programvare som selges til rederier?
Vanligvis, hvis den selges på EU-markedet som et produkt med digitale elementer, installert eller nedlastet, og ikke er MED-utstyr. Programvare som bare tilbys som en tjeneste, er utenfor CRA med mindre den er fjernbehandling av data for et produkt, men NIS2 kan gjelde for leverandøren. Sjekk klassifiseringen av hvert produkt.
Se hva som går inn i utgivelsene dine
Book en demo, så viser vi hver komponent byggene dine henter inn, og hvilke av utgivelsene dine en ny sårbarhet berører.
Book en demo