Cyberbeveiliging voor makers van maritieme software en uitrusting
Schepen draaien nu op software van tientallen leveranciers, en klasseregels en EU-wetgeving verwachten dat elke leverancier weet wat er in zijn software zit en die veilig houdt. CRACI draait uw GitHub Actions-builds en legt elk component vast dat in elke release gaat.
Welke regels gelden voor welke maritieme producten
Een maritieme leverancier valt onder drie regimes die elkaar overlappen maar niet samenvallen: EU-productwetgeving, classificatieregels voor nieuwe schepen en de IMO-richtsnoeren voor scheepsexploitanten. Bepaal per product wat van toepassing is voordat u het bewijs plant.
De CRA sluit uitrusting onder de MED uit
Artikel 2, lid 4, van de Cyber Resilience Act, Verordening (EU) 2024/2847, luidt: "Deze verordening is niet van toepassing op uitrusting die binnen het toepassingsgebied van Richtlijn 2014/90/EU valt." Die richtlijn inzake uitrusting van zeeschepen, de Marine Equipment Directive (MED), dekt uitrusting die aan boord van een EU-schip wordt of zal worden geplaatst en waarvoor de IMO-verdragen goedkeuring door de administratie van de vlaggenstaat vereisen: de uitrusting met wheel mark (stuurwielmarkering). Voorbeelden zijn navigatieapparatuur zoals radar, ECDIS, AIS en reisgegevensrecorders, radiocommunicatieapparatuur, brandbeveiliging en reddingsmiddelen. Controleer voor uw eigen artikel de actuele MED-uitvoeringslijst.
Wat onder de CRA blijft vallen
Producten met digitale elementen die in de EU op de markt worden gebracht en geen MED-uitrusting zijn: software aan boord en aan wal die als product wordt verkocht, geïnstalleerd of gedownload; systemen voor scheepsoperaties, accommodatie, catering en hotelbeheer; servicesystemen voor bemanning en passagiers; software voor vloot- en reisbeheer; IoT-sensoren en gateways aan boord; monitorings- en automatiseringsapparatuur die geen goedkeuring van de vlaggenstaat nodig heeft. Software as a service op zichzelf valt buiten de CRA, tenzij het de gegevensverwerking op afstand van een product is, al kan NIS2 wel gelden voor de aanbieder ervan.
Sommige gevallen vragen eerder om een juridische beoordeling dan om een vuistregel: uitrusting van een type met wheel mark die wordt verkocht voor schepen die geen EU-vlag voeren, en producten die MED-uitrusting combineren met softwaremodules buiten de MED.
IACS UR E26 en E27
De unified requirements van de International Association of Classification Societies gelden via de classificatie, niet via EU-wetgeving. Rev.1 van beide geldt voor schepen waarvan het bouwcontract op of na 1 juli 2024 is gesloten. Ze zijn verplicht voor passagiersschepen en hogesnelheidsvaartuigen op internationale reizen, vrachtschepen van 500 GT en meer op internationale reizen, mobiele offshore-booreenheden en bepaalde zelfvarende offshore-eenheden, en dienen als richtsnoer voor andere schepen. Een product dat vanwege de MED buiten de CRA valt, kan toch onder E26 en E27 vallen, en omgekeerd.
IMO
Resolutie MSC.428(98) vraagt scheepsexploitanten om cyberrisico's op te nemen in hun veiligheidsbeheersystemen, uiterlijk bij de eerste jaarlijkse verificatie van het Document of Compliance van de onderneming na 1 januari 2021. De IMO-richtsnoeren voor maritiem cyberrisicobeheer zijn niet-verplichte, algemene richtsnoeren voor exploitanten. De jongste herziening, van mei 2026, zegt dat cyberrisicobeheer rekening moet houden met externe leveranciers, embedded systemen en toeleveringsketens van software en hardware, en vraagt exploitanten beleid vast te stellen voor de beveiliging van de software- en hardwareketen van kritieke systemen. Daarom leggen exploitanten de vraag door naar hun leveranciers.
| Voorbeeldproduct | Met wheel mark (MED)? | Cyber Resilience Act | IACS UR E26 en E27 | Wat de leverancier moet aantonen |
|---|---|---|---|---|
| ECDIS | Ja | Uitgesloten (artikel 2, lid 4) | Ja, op nieuwe schepen die eronder vallen | MED-goedkeuring; E27-documentatie en software-inventaris |
| Motorautomatisering op een nieuw te bouwen vrachtschip | Controleren | Ja, tenzij het MED-uitrusting is | Ja: de voortstuwing is een gedekt systeem | E27-documentatie, inventaris en veilige ontwikkelcyclus; technische documentatie en SBOM voor de CRA |
| Software voor hotel- en cateringbeheer | Nee | Ja, wanneer verkocht als product | Controleren: E26 dekt de netwerkinterface met gedekte systemen | SBOM en afhandeling van kwetsbaarheden voor de CRA |
| Netwerkapparatuur voor bemanningswelzijn | Nee | Ja | Controleren: E26 dekt de interface met gedekte systemen | SBOM en afhandeling van kwetsbaarheden voor de CRA |
| Vlootbeheersoftware als service | Nee | Valt erbuiten, tenzij het de gegevensverwerking op afstand van een product is | Nee: draait aan wal | Antwoorden op leveranciersvragenlijsten van exploitanten; NIS2 kan gelden voor de aanbieder |
| Sensoren voor conditiebewaking aan boord | Controleren | Ja, tenzij het MED-uitrusting is | Controleren: valt eronder als onderdeel van een gedekt systeem | SBOM voor de CRA; E27-documentatie als onderdeel van een gedekt systeem |
De vuistregel: heeft uw product een wheel mark nodig, dan geldt de CRA er niet voor; gaat het op een schip met een bouwcontract vanaf juli 2024, dan geldt E27 waarschijnlijk wel; verkoopt u software of verbonden producten in de EU, ga er dan van uit dat de CRA geldt.
Wat E26 en E27 van leveranciers vragen
E27 is de eis die leveranciers van uitrusting rechtstreeks raakt. Paragraaf 3.1 noemt de documenten die een leverancier voor een computergebaseerd systeem bij het classificatiebureau indient, waaronder:
- Een asset-inventaris (3.1.1): de hardwarecomponenten, met de naam, versie en patchniveau van hun systeemsoftware, zoals het besturingssysteem en de firmware, en de softwarecomponenten, elk met de hardware waarop ze zijn geïnstalleerd, de fabrikant, het model of type, het doel en de softwareversie.
- Een beschrijving van de beveiligingsfuncties (3.1.3) en hun testprocedure, richtlijnen voor de beveiligingsconfiguratie, en plannen voor onderhoud, incidentrespons, herstel en wijzigingsbeheer.
- Documenten over de veilige ontwikkelcyclus (3.1.6), die ook beschrijven hoe software-updates en patches worden afgehandeld.
Paragraaf 4 legt de vereiste beveiligingsfuncties vast, gebaseerd op geselecteerde systeemeisen uit IEC 62443-3-3, zoals authenticatie en bescherming tegen kwaadaardige code. Dit zijn functies van het product.
Paragraaf 5 vereist een veilige ontwikkelcyclus die eisen, ontwerp, implementatie, verificatie, release, onderhoud en end-of-life dekt, vastgelegd in een document dat het classificatiebureau beoordeelt. Die moet maatregelen bevatten uit IEC 62443-4-1: bescherming van code-signing-sleutels (SM-8), documentatie van beveiligingsupdates voor gebruikers (SUM-2), documentatie van beveiligingsupdates voor afhankelijke componenten of het besturingssysteem (SUM-3), authentieke levering van updates (SUM-4), en richtlijnen voor defense-in-depth en hardening (SG-1 tot SG-3).
E26 maakt de cirkel rond op scheepsniveau: de asset-inventaris van het schip voor hardware en software, met de velden uit de E27-inventaris van elke leverancier, wordt gedurende de hele levensduur van het schip actueel gehouden, en wijzigingen in software en hardware die nieuwe kwetsbaarheden kunnen introduceren, worden erin vastgelegd.
Wat E27 niet zegt: SBOM's worden niet genoemd. Een SBOM per release is de nauwkeurigste manier om de softwareversies voor de inventaris en de SUM-3-informatie over afhankelijke componenten te leveren, maar ze ondersteunt die eisen in plaats van er zelf een te zijn.
| Eis uit E26 of E27 | Wat het classificatiebureau of de werf verwacht | Bewijs uit de build | Wat bij u blijft |
|---|---|---|---|
| E27-asset-inventaris (3.1.1) | Elk softwarecomponent met doel en versie, en de systeemsoftware van elk hardwarecomponent | Een SBOM per release, met elk component en zijn versie | Op welke hardware elk component is geïnstalleerd, gegevens over fabrikant en model |
| Updatedocumentatie volgens SUM-2 en SUM-3 | Gedocumenteerde beveiligingsupdates, ook voor afhankelijke componenten en besturingssystemen | Kwetsbaarheidsrecords en buildgeschiedenis voor de componenten in elke release | De updatenotities en advisories die u naar gebruikers stuurt |
| SM-8 en SUM-4 | Beschermde code-signing-sleutels en authentieke levering van updates | Geen: CRACI ondertekent geen software | Uw ondertekeningsproces en sleutelopslag |
| Beveiligingsfuncties volgens paragraaf 4 | Authenticatie, bescherming tegen kwaadaardige code en andere productfuncties | Geen: dit zijn productfuncties | Het productontwerp en het testen ervan |
| Levenscyclusdocument volgens paragraaf 5 | Een beoordeelde beschrijving van hoe beveiliging in elke fase wordt aangepakt | Vastleggingen dat de releasefase beheerst is: wat elke build bevatte en wat hij kon bereiken | Het document schrijven en het proces uitvoeren |
| E26-asset-inventaris van het schip | De inventaris van het schip, actueel gehouden gedurende zijn levensduur | Uw SBOM-exports, overgedragen aan de integrator | Welke versie op welk schip is geïnstalleerd, en de overdracht aan de werf of integrator |
Waarom maritieme software moeilijk bij te houden is
Schepen overleven projecten. Een schip blijft tientallen jaren in de vaart, en de ondersteuningslast voor de software aan boord duurt langer dan het project dat haar heeft geleverd, het team dat haar heeft gebouwd en vaak de productlijn van de leverancier zelf.
Veel kleine leveranciers en integrators. Eén schip vervoert software van tientallen leveranciers, samengebracht door een integrator, en elke overdracht is een kans om uit het oog te verliezen wat er in elke release zit.
Systemen aan boord kunnen niet naar believen worden bijgewerkt. Updates wachten op havenbezoeken, goedkeuring door de klasse of een onderhoudsvenster, dus oude versies blijven lang in gebruik nadat er een fix bestaat. U moet weten op welke schepen nog welke versie draait.
Afgelegen locaties, beperkte connectiviteit. Schepen op zee en afgelegen installaties zijn moeilijk bereikbaar, dus de vastlegging van wat er is geïnstalleerd, moet aan wal bestaan, vanuit de build, niet vanuit een scan van het schip.
Spreadsheets als leidend systeem. We horen van makers van maritieme software dat SBOM's en bijbehorende vastleggingen in veel spreadsheets staan, met de hand bijgehouden. Met elke release raken ze verder verouderd.
Zo bereidt u zich voor, stap voor stap
Beveiligingsfuncties zoals authenticatie horen bij het ontwerp van het product. De onderstaande stappen gaan over het bewijs voor de software die erin gaat.
- Koppel elk product aan zijn regime. Bepaal voor elk product of het MED-uitrusting is, een CRA-product, onder E26 en E27 valt, of meerdere daarvan. Het bewijsplan volgt uit die indeling.
- Maak een SBOM voor elke release. Leg vast wat er in elke release van elk product dat u bouwt gaat, inclusief transitieve afhankelijkheden, zodat de software-inventaris uit de build komt en niet uit het geheugen.
- Houd een inventaris per installatie bij. Houd bij welke versie op welk schip is geïnstalleerd en wanneer die is gewijzigd. Dat voedt de E27-asset-inventaris en de E26-asset-inventaris van de integrator, die wijzigingen vastlegt gedurende de hele levensduur van het schip.
- Monitor op kwetsbaarheden en meld. Controleer geleverde releases opnieuw zodra er nieuwe kwetsbaarheden worden gepubliceerd. Voor producten die onder de CRA vallen, geldt de meldplicht voor actief uitgebuite kwetsbaarheden en ernstige incidenten sinds 11 september 2026.
- Houd bekende kwetsbare pakketten buiten de builds. Blokkeer een build die een bekende kwetsbaarheid zou leveren, zodat die niet terugkomt via een update van een afhankelijkheid.
- Documenteer beveiligingsupdates voor klanten en integrators. Vertel klanten en integrators wat elke beveiligingsupdate oplost, inclusief fixes in afhankelijke componenten en het besturingssysteem, zoals SUM-2 en SUM-3 verwachten.
Waar CRACI past
CRACI draait uw GitHub Actions-builds op eigen runners en legt vast wat er in elke release gaat. Die vastlegging is het gedeelde bewijs achter de CRA, uw E27-documentatie en de vragen van uw klanten.
Elke release vastgelegd
Uw builds draaien op de GitHub Actions-runners van CRACI met runs-on: craci, en de runs verschijnen gewoon in GitHub. Terwijl elke build draait, legt CRACI elk pakket vast dat hij binnenhaalt, ook uit npm en PyPI, met de verborgen afhankelijkheden die in geen enkele lockfile staan en een volledigheidsstatus voor elke job. SBOM's worden geëxporteerd als CycloneDX of SPDX met transitieve afhankelijkheden, gedeclareerde licenties en de kwetsbaarheden die in hun componenten zijn gevonden: de grondstof voor het softwaredeel van een E27-asset-inventaris. Meer over SBOM's uit de build.
Houd kwetsbare pakketten buiten de deur
Policy gates kunnen een build blokkeren die een specifieke CVE bevat, en licentiebeleidsregels kunnen een build blokkeren op een licentie. Een bekend probleem wordt in de CI onderschept, voordat de release een schip bereikt.
Weet welke releases zijn getroffen
CRACI blijft gemonitorde SBOM's opnieuw beoordelen zodra er nieuwe kwetsbaarheden worden gepubliceerd, en de buildgeschiedenis toont binnen de bewaartermijn van uw abonnement welke builds de kwetsbare afhankelijkheid bevatten. De inventarisweergave toont welke softwareversies in welke producten zijn uitgerold. Securityteams triëren elke bevinding en sturen die naar het team dat verantwoordelijk is voor de fix. Voor producten die onder de CRA vallen, stelt CRACI de inhoud van de CRA-meldingen op, en iemand in uw bedrijf dient ze in via het Single Reporting Platform.
Een build die uw secrets niet kan lekken
Elke job draait in zijn eigen geïsoleerde virtuele machine onder een egressbeleid dat u op default deny kunt zetten, dat wordt gevalideerd voordat de job start en bij een fout blokkeert (fail closed). Met een default-deny-beleid wordt een verbinding met een host die de build niet nodig heeft geblokkeerd, en dat leidt tot een melding.
Wanneer CRACI niet het antwoord is
CRACI is er voor teams die software bouwen. Het past niet in deze gevallen:
- Niet voor scheepsexploitanten en reders die netwerkmonitoring aan boord, inbraakdetectie, E26-naleving op scheepsniveau of documentatie voor hun veiligheidsbeheersysteem zoeken. CRACI is er voor de mensen die de software bouwen, niet voor de vloot die haar gebruikt.
- Geen CRA-programma voor makers van MED-uitrusting: uitrusting met wheel mark valt buiten de CRA. CRACI kan de softwarebuilds erachter nog steeds vastleggen voor E27 en voor verzoeken van klanten, als ze op GitHub Actions draaien.
- Niet voor leveranciers die niet op GitHub Actions bouwen, die buildmachines met Windows of macOS nodig hebben, of runners in hun eigen cloudaccount. CRACI draait vandaag beheerde Linux-runners op Europese infrastructuur; andere CI-systemen, Windows- en macOS-runners en door de klant gehoste runners staan op de roadmap.
- Niet voor hardwarestuklijsten. CRACI legt software vast; het beheert geen hardware-BOM's.
- Niet de E27-beveiligingsfuncties of een klassegoedkeuring. CRACI implementeert geen authenticatie, bescherming tegen malware of andere productfuncties, ondertekent geen software, schrijft uw document over de veilige ontwikkelcyclus niet en handelt niet namens u met het classificatiebureau.
- Geen tool voor herstelstatistieken: CRACI rapporteert geen gemiddelde hersteltijd of hersteltermijnen.
Maritieme cyberbeveiliging uitgelegd
Veelgestelde vragen over de CRA, IACS UR E26 en E27 en de IMO-richtsnoeren voor maritieme leveranciers
Is de Cyber Resilience Act van toepassing op scheepsuitrusting?
Niet op uitrusting binnen het toepassingsgebied van Richtlijn 2014/90/EU inzake uitrusting van zeeschepen. Artikel 2, lid 4, van de CRA sluit die uitdrukkelijk uit. Dat gaat om uitrusting met wheel mark die volgens de IMO-verdragen goedkeuring van de vlaggenstaat nodig heeft. Andere verbonden producten en software die voor schepen worden verkocht, zoals hotelsystemen, bemanningsnetwerken, sensoren en vlootsoftware die aan boord is geïnstalleerd, kunnen nog steeds onder de CRA vallen.
Welke maritieme producten zijn uitgesloten van de CRA?
Uitrusting binnen het toepassingsgebied van de MED: uitrusting aan boord van EU-schepen waarvoor de IMO-verdragen goedkeuring van de vlaggenstaat vereisen, zoals radar, ECDIS, AIS, reisgegevensrecorders, radiocommunicatie, brandbeveiliging en reddingsmiddelen. Controleer de actuele MED-uitvoeringslijst voor uw artikel en vraag een juridische beoordeling voor gemengde producten of schepen onder andere vlaggen.
Wat is IACS UR E27, en wie moet eraan voldoen?
UR E27 is de unified requirement van de International Association of Classification Societies over de cyberweerbaarheid van systemen en uitrusting aan boord. Rev.1 geldt voor schepen waarvan het bouwcontract op of na 1 juli 2024 is gesloten, en is verplicht voor passagiersschepen, hogesnelheidsvaartuigen en vrachtschepen van 500 GT en meer op internationale reizen, en voor bepaalde offshore-eenheden. Leveranciers van gedekte systemen voldoen eraan via het classificatiebureau.
Wat vragen E26 en E27 van leveranciers van uitrusting?
E27 vraagt leveranciers om documentatie, waaronder een asset-inventaris met elk softwarecomponent en zijn versie, beveiligingsfuncties op basis van IEC 62443-3-3, en een veilige ontwikkelcyclus met maatregelen uit IEC 62443-4-1, zoals het documenteren van beveiligingsupdates. E26 is de eis op scheepsniveau: de asset-inventaris van het schip gebruikt dezelfde velden en wordt gedurende de hele levensduur van het schip actueel gehouden.
Vereist UR E27 een SBOM?
Nee. E27 noemt geen SBOM's. Het vraagt om een asset-inventaris met elk softwarecomponent en zijn versie, en om documentatie van beveiligingsupdates voor afhankelijke componenten en het besturingssysteem. Een SBOM per release is de nauwkeurigste manier om die informatie te leveren, maar het is geen eis van E27.
Zijn de IMO-richtsnoeren voor cyberrisicobeheer verplicht?
Nee. De IMO-richtsnoeren voor maritiem cyberrisicobeheer zijn niet-verplichte richtsnoeren voor scheepsexploitanten, herzien in mei 2026. Wat van exploitanten wordt verwacht, volgt uit Resolutie MSC.428(98), die hen vraagt cyberrisico's op te nemen in hun veiligheidsbeheersystemen, en de richtsnoeren vragen exploitanten nu beleid vast te stellen voor de beveiliging van de software- en hardwareketen.
Is de CRA van toepassing op software die aan rederijen wordt verkocht?
Meestal wel, als ze in de EU op de markt wordt gebracht als product met digitale elementen, geïnstalleerd of gedownload, en geen MED-uitrusting is. Software die puur als service wordt aangeboden, valt buiten de CRA, tenzij het de gegevensverwerking op afstand van een product is, al kan NIS2 gelden voor de aanbieder ervan. Controleer de classificatie van elk product.
Zie wat er in uw releases gaat
Boek een demo, dan laten we elk component zien dat uw builds binnenhalen, en welke van uw releases een nieuwe kwetsbaarheid raakt.
Demo boeken