Cybersecurity per i produttori di software ed equipaggiamento marittimo
Le navi funzionano ormai con software di decine di fornitori, e le regole di classe e il diritto UE si aspettano che ogni fornitore sappia che cosa c'è nel proprio software e lo mantenga sicuro. CRACI esegue le Sue build GitHub Actions e registra ogni componente che entra in ogni release.
Quali regole si applicano a quali prodotti marittimi
Un fornitore del settore marittimo risponde a tre regimi che si sovrappongono ma non coincidono: il diritto UE dei prodotti, le regole di classificazione per le navi nuove e gli orientamenti dell'IMO per gli operatori navali. Stabilisca quale si applica a ciascun prodotto prima di pianificare le evidenze.
Il CRA esclude le apparecchiature della direttiva sull'equipaggiamento marittimo
L'articolo 2(4) del Cyber Resilience Act, regolamento (UE) 2024/2847, stabilisce: «Il presente regolamento non si applica alle apparecchiature che rientrano nell'ambito di applicazione della direttiva 2014/90/UE.» Quella direttiva, la direttiva sull'equipaggiamento marittimo (MED), riguarda l'equipaggiamento installato o destinato a essere installato a bordo di una nave UE per il quale le convenzioni IMO richiedono l'approvazione dell'amministrazione dello Stato di bandiera: l'equipaggiamento con il wheel mark (marchio del timone). Ne sono esempi le apparecchiature di navigazione come radar, ECDIS, AIS e registratori dei dati di viaggio, le apparecchiature di radiocomunicazione, la protezione antincendio e i mezzi di salvataggio. Verifichi l'elenco di esecuzione MED vigente per il Suo articolo.
Che cosa resta nell'ambito del CRA
I prodotti con elementi digitali immessi sul mercato UE che non sono equipaggiamento MED: software di bordo e di terra venduto come prodotto, installato o scaricato; sistemi di gestione delle operazioni di bordo, degli alloggi, della ristorazione e dei servizi alberghieri; sistemi di servizio per equipaggio e passeggeri; software di gestione della flotta e dei viaggi; sensori e gateway IoT di bordo; apparecchiature di monitoraggio e automazione che non richiedono l'approvazione dello Stato di bandiera. Il software as a service di per sé è escluso dal CRA, a meno che non costituisca la soluzione di trattamento dati da remoto di un prodotto, anche se la NIS2 può comunque applicarsi al suo fornitore.
Alcuni casi richiedono un parere legale piuttosto che una regola: equipaggiamento di un tipo con wheel mark venduto per navi che non battono bandiera UE, e prodotti che combinano equipaggiamento MED con moduli software al di fuori della MED.
IACS UR E26 ed E27
I requisiti unificati dell'International Association of Classification Societies si applicano tramite la classificazione, non tramite il diritto UE. La Rev.1 di entrambi si applica alle navi il cui contratto di costruzione è stipulato a partire dal 1° luglio 2024. Sono obbligatori per navi passeggeri e unità veloci in viaggi internazionali, navi da carico di 500 GT e oltre in viaggi internazionali, unità mobili di perforazione offshore e alcune unità offshore semoventi, e valgono come orientamento per le altre navi. Un prodotto escluso dal CRA a causa della MED può comunque rientrare nell'ambito di E26 ed E27, e viceversa.
IMO
La risoluzione MSC.428(98) chiede agli operatori navali di affrontare i rischi cyber nei loro sistemi di gestione della sicurezza entro la prima verifica annuale del documento di conformità della compagnia successiva al 1° gennaio 2021. Le linee guida IMO sulla gestione del rischio cyber marittimo sono orientamenti generali non obbligatori per gli operatori. La loro ultima revisione, del maggio 2026, afferma che la gestione del rischio cyber dovrebbe considerare i fornitori terzi, i sistemi embedded e le supply chain del software e dell'hardware, e chiede agli operatori di stabilire policy sulla sicurezza della supply chain del software e dell'hardware per i sistemi critici. Per questo gli operatori girano la domanda ai propri fornitori.
| Esempio di prodotto | Wheel mark (MED)? | Cyber Resilience Act | IACS UR E26 ed E27 | Che cosa deve dimostrare il fornitore |
|---|---|---|---|---|
| ECDIS | Sì | Escluso (articolo 2(4)) | Sì, sulle navi nuove che rientrano nell'ambito | Approvazione MED; documentazione E27 e inventario del software |
| Sistema di automazione dei motori su una nave da carico di nuova costruzione | Da verificare | Sì, a meno che non sia equipaggiamento MED | Sì: la propulsione è un sistema coperto | Documentazione E27, inventario e ciclo di vita dello sviluppo sicuro; documentazione tecnica CRA e SBOM |
| Software di gestione alberghiera e ristorazione | No | Sì, quando è venduto come prodotto | Da verificare: E26 copre la sua interfaccia di rete verso i sistemi coperti | SBOM e gestione delle vulnerabilità per il CRA |
| Apparecchiature di rete per il benessere dell'equipaggio | No | Sì | Da verificare: E26 copre la loro interfaccia verso i sistemi coperti | SBOM e gestione delle vulnerabilità per il CRA |
| Software di gestione della flotta as a service | No | Escluso, a meno che non sia la soluzione di trattamento dati da remoto di un prodotto | No: funziona a terra | Risposte ai questionari per i fornitori degli operatori; la NIS2 può applicarsi al fornitore |
| Sensori di bordo per il monitoraggio delle condizioni | Da verificare | Sì, a meno che non siano equipaggiamento MED | Da verificare: rientrano quando fanno parte di un sistema coperto | SBOM CRA; documentazione E27 quando fanno parte di un sistema coperto |
La regola pratica: se il Suo prodotto ha bisogno del wheel mark, il CRA non si applica; se va su una nave con contratto da luglio 2024, probabilmente si applica E27; se vende software o prodotti connessi nell'UE, dia per scontato che si applichi il CRA.
Che cosa chiedono E26 ed E27 ai fornitori
E27 è il requisito che raggiunge direttamente i fornitori di equipaggiamento. La sezione 3.1 elenca i documenti che un fornitore presenta alla società di classificazione per un sistema computerizzato, tra cui:
- Un inventario degli asset (3.1.1): i componenti hardware, con nome, versione e livello di patch del loro software di sistema, come sistema operativo e firmware, e i componenti software, ciascuno con l'hardware su cui è installato, il produttore, il modello o tipo, lo scopo e la versione del software.
- Una descrizione delle capacità di sicurezza (3.1.3) e della relativa procedura di test, linee guida per la configurazione di sicurezza e piani per manutenzione, risposta agli incidenti, ripristino e gestione delle modifiche.
- Documenti del ciclo di vita dello sviluppo sicuro (3.1.6), che descrivono anche come vengono gestiti gli aggiornamenti software e le patch.
La sezione 4 stabilisce le capacità di sicurezza richieste, sulla base di una selezione di requisiti di sistema della IEC 62443-3-3, come l'autenticazione e la protezione contro il codice malevolo. Sono capacità del prodotto.
La sezione 5 richiede un ciclo di vita dello sviluppo sicuro che copra requisiti, progettazione, implementazione, verifica, rilascio, manutenzione e fine vita, documentato in un documento che la società di classificazione esamina. Deve includere controlli tratti dalla IEC 62443-4-1: protezione delle chiavi di firma del codice (SM-8), documentazione degli aggiornamenti di sicurezza per gli utenti (SUM-2), documentazione degli aggiornamenti di sicurezza dei componenti dipendenti o del sistema operativo (SUM-3), consegna autentica degli aggiornamenti (SUM-4) e indicazioni di defense in depth e hardening (da SG-1 a SG-3).
E26 chiude il cerchio a livello di nave: l'inventario degli asset della nave, hardware e software, con i campi dell'inventario E27 di ciascun fornitore, viene mantenuto aggiornato per tutta la vita della nave, e vi vengono registrate le modifiche software e hardware che possono introdurre nuove vulnerabilità.
Che cosa E27 non dice: non cita le SBOM. Una SBOM per ogni release è il modo più preciso per produrre le versioni del software per l'inventario e le informazioni SUM-3 sui componenti dipendenti, ma supporta questi requisiti anziché esserne uno.
| Requisito E26 o E27 | Che cosa si aspetta la società di classificazione o il cantiere | Evidenze dalla build | Che cosa resta a Lei |
|---|---|---|---|
| Inventario degli asset E27 (3.1.1) | Ogni componente software con il suo scopo e la sua versione, e il software di sistema di ogni componente hardware | Una SBOM per release, con ogni componente e la sua versione | Su quale hardware è installato ogni componente, dati di produttore e modello |
| Documentazione degli aggiornamenti SUM-2 e SUM-3 | Aggiornamenti di sicurezza documentati, anche per componenti dipendenti e sistemi operativi | Registri delle vulnerabilità e storico delle build per i componenti di ogni release | Le note di aggiornamento e gli advisory che invia agli utenti |
| SM-8 e SUM-4 | Chiavi di firma del codice protette e consegna autentica degli aggiornamenti | Nessuna: CRACI non firma il software | Il Suo processo di firma e l'archiviazione delle chiavi |
| Capacità di sicurezza della sezione 4 | Autenticazione, protezione dal codice malevolo e altre capacità del prodotto | Nessuna: sono funzioni del prodotto | La progettazione del prodotto e i suoi test |
| Documento del ciclo di vita della sezione 5 | Una descrizione esaminata di come la sicurezza viene gestita in ogni fase | Record che dimostrano che la fase di rilascio è controllata: che cosa conteneva ogni build e che cosa poteva raggiungere | Redigere il documento e gestire il processo |
| Inventario degli asset della nave E26 | L'inventario della nave, mantenuto aggiornato per tutta la sua vita | Gli export delle Sue SBOM, consegnati all'integratore | Quale versione è installata su quale nave, e la consegna al cantiere o all'integratore |
Perché è difficile tenere traccia del software marittimo
Le navi sopravvivono ai progetti. Una nave resta in servizio per decenni, e l'onere di supporto del software di bordo dura più del progetto che lo ha consegnato, del team che lo ha costruito e spesso della stessa linea di prodotti del fornitore.
Molti piccoli fornitori e integratori. Una sola nave ospita software di decine di fornitori, assemblato da un integratore, e ogni passaggio di consegne è un'occasione per perdere traccia di che cosa contiene ogni release.
I sistemi di bordo non si possono aggiornare a piacimento. Gli aggiornamenti attendono gli scali in porto, l'approvazione della classe o una finestra di manutenzione, quindi le vecchie versioni restano in servizio a lungo dopo che esiste una correzione. Occorre sapere quali navi eseguono ancora quale versione.
Siti remoti, connettività limitata. Le navi in mare e le installazioni remote sono difficili da raggiungere, quindi il record di ciò che è stato installato deve esistere a terra, a partire dalla build, non dalla scansione della nave.
Fogli di calcolo come sistema di riferimento. I produttori di software marittimo ci riferiscono che le SBOM e i relativi record vivono in molti fogli di calcolo, tenuti a mano. Diventano obsoleti a ogni release.
Come prepararsi, passo dopo passo
Le capacità di sicurezza come l'autenticazione fanno parte della progettazione del prodotto. I passaggi seguenti riguardano le evidenze sul software che vi entra.
- Associare ogni prodotto al suo regime. Per ogni prodotto, stabilisca se è equipaggiamento MED, un prodotto CRA, nell'ambito di E26 ed E27, o più di questi. Il piano delle evidenze deriva da questa mappa.
- Produrre una SBOM per ogni release. Registri ciò che entra in ogni release di ogni prodotto che costruisce, comprese le dipendenze transitive, così l'inventario del software deriva dalla build e non dalla memoria.
- Tenere un inventario per installazione. Tenga traccia di quale versione è installata su quale nave e di quando è cambiata. Questo alimenta l'inventario degli asset E27 e l'inventario degli asset della nave E26 dell'integratore, che registra le modifiche per tutta la vita della nave.
- Monitorare le vulnerabilità e segnalarle. Ricontrolli le release distribuite man mano che vengono pubblicate nuove vulnerabilità. Per i prodotti nell'ambito del CRA, la segnalazione delle vulnerabilità attivamente sfruttate e degli incidenti gravi si applica dall'11 settembre 2026.
- Impedire ai pacchetti notoriamente vulnerabili di entrare nelle build. Blocchi una build che distribuirebbe una vulnerabilità nota, così non può ritornare tramite un aggiornamento delle dipendenze.
- Documentare gli aggiornamenti di sicurezza per clienti e integratori. Comunichi a clienti e integratori che cosa corregge ogni aggiornamento di sicurezza, comprese le correzioni nei componenti dipendenti e nel sistema operativo, come richiedono SUM-2 e SUM-3.
Dove si inserisce CRACI
CRACI esegue le Sue build GitHub Actions sui propri runner e registra ciò che entra in ogni release. Quel record è l'evidenza comune dietro il CRA, la Sua documentazione E27 e le domande dei Suoi clienti.
Ogni release registrata
Le Sue build vengono eseguite sui runner GitHub Actions di CRACI con runs-on: craci, e le esecuzioni continuano a comparire in GitHub. Durante ogni build, CRACI registra ogni pacchetto scaricato, compresi npm e PyPI, con le dipendenze nascoste che nessun lockfile elenca e uno stato di completezza per ogni job. Le SBOM si esportano in CycloneDX o SPDX con dipendenze transitive, licenze dichiarate e le vulnerabilità trovate nei loro componenti: la materia prima per la parte software di un inventario degli asset E27. Approfondisca le SBOM in fase di build.
Tenga fuori i pacchetti vulnerabili
I policy gate possono bloccare una build che contiene una CVE specifica, e le regole di policy sulle licenze possono bloccare una build in base a una licenza. Un problema noto viene intercettato in CI, prima che la release raggiunga una nave.
Sappia quali release sono colpite
CRACI continua a rivalutare le SBOM monitorate man mano che vengono pubblicate nuove vulnerabilità, e lo storico delle build mostra quali build contenevano la dipendenza vulnerabile, entro il periodo di conservazione del Suo piano. La vista inventario mostra quali versioni del software sono distribuite in quali prodotti. I team di sicurezza eseguono il triage di ogni risultato e lo inoltrano al team responsabile della correzione. Per i prodotti che rientrano nel CRA, CRACI prepara il contenuto delle notifiche CRA, e una persona della Sua azienda le presenta tramite la Single Reporting Platform.
Una build che non può far trapelare i Suoi secret
Ogni job viene eseguito nella propria macchina virtuale isolata sotto una policy di egress che può impostare su default-deny, convalidata prima dell'avvio del job e in modalità fail closed. Con una policy default-deny, una connessione verso un host di cui la build non ha bisogno viene bloccata e genera un alert.
Quando CRACI non è la risposta
CRACI è per i team che costruiscono software. Non è adatto a questi casi:
- Non per operatori e armatori che cercano monitoraggio della rete di bordo, rilevamento delle intrusioni, conformità E26 a livello di nave o documentazione per il proprio sistema di gestione della sicurezza. CRACI è per chi costruisce il software, non per la flotta che lo utilizza.
- Non un programma CRA per i produttori di equipaggiamento MED: l'equipaggiamento con il wheel mark è escluso dal CRA. CRACI può comunque registrare le build software che lo riguardano per E27 e per le richieste dei clienti, se vengono eseguite su GitHub Actions.
- Non per i fornitori che non costruiscono su GitHub Actions, che hanno bisogno di macchine di build Windows o macOS, o di runner all'interno del proprio account cloud. Oggi CRACI offre runner Linux gestiti su infrastruttura europea; altri sistemi CI, i runner Windows e macOS e i runner ospitati dal cliente sono in roadmap.
- Non per le distinte base hardware. CRACI registra il software; non gestisce le BOM hardware.
- Non le capacità di sicurezza E27 né un'approvazione di classe. CRACI non implementa autenticazione, protezione dal malware o altre capacità del prodotto, non firma il software, non redige il Suo documento sul ciclo di vita dello sviluppo sicuro e non tratta con la società di classificazione al posto Suo.
- Non uno strumento di metriche di remediation: CRACI non riporta il tempo medio di remediation né le scadenze di remediation.
La cybersecurity marittima, spiegata
Domande comuni su CRA, IACS UR E26 ed E27 e linee guida IMO per i fornitori del settore marittimo
Il Cyber Resilience Act si applica all'equipaggiamento marittimo?
Non all'equipaggiamento che rientra nell'ambito della direttiva sull'equipaggiamento marittimo, 2014/90/UE. L'articolo 2(4) del CRA lo esclude espressamente. Questo copre l'equipaggiamento con il wheel mark che richiede l'approvazione dello Stato di bandiera ai sensi delle convenzioni IMO. Altri prodotti connessi e software venduti per le navi, come sistemi alberghieri, reti per l'equipaggio, sensori e software di flotta installati a bordo, possono comunque rientrare nel CRA.
Quali prodotti marittimi sono esclusi dal CRA?
L'equipaggiamento che rientra nell'ambito della direttiva sull'equipaggiamento marittimo: equipaggiamento installato a bordo di navi UE per il quale le convenzioni IMO richiedono l'approvazione dello Stato di bandiera, come radar, ECDIS, AIS, registratori dei dati di viaggio, radiocomunicazione, protezione antincendio e mezzi di salvataggio. Verifichi l'elenco di esecuzione MED vigente per il Suo articolo e chieda un parere legale per prodotti misti o navi con altre bandiere.
Che cos'è IACS UR E27, e chi deve rispettarlo?
UR E27 è il requisito unificato dell'International Association of Classification Societies sulla resilienza cyber dei sistemi e delle apparecchiature di bordo. La Rev.1 si applica alle navi il cui contratto di costruzione è stipulato a partire dal 1° luglio 2024, ed è obbligatoria per navi passeggeri, unità veloci e navi da carico di 500 GT e oltre in viaggi internazionali, e per alcune unità offshore. I fornitori di sistemi coperti lo rispettano tramite la società di classificazione.
Che cosa richiedono E26 ed E27 ai fornitori di equipaggiamento?
E27 chiede ai fornitori una documentazione che comprende un inventario degli asset con ogni componente software e la sua versione, capacità di sicurezza tratte dalla IEC 62443-3-3 e un ciclo di vita dello sviluppo sicuro con controlli della IEC 62443-4-1, come la documentazione degli aggiornamenti di sicurezza. E26 è il requisito a livello di nave: l'inventario degli asset della nave usa gli stessi campi e viene mantenuto aggiornato per tutta la vita della nave.
UR E27 richiede una SBOM?
No. E27 non cita le SBOM. Chiede un inventario degli asset con ogni componente software e la sua versione, e la documentazione degli aggiornamenti di sicurezza dei componenti dipendenti e del sistema operativo. Una SBOM per release è il modo più preciso per produrre queste informazioni, ma non è un requisito di E27.
Le linee guida IMO sulla gestione del rischio cyber sono obbligatorie?
No. Le linee guida IMO sulla gestione del rischio cyber marittimo sono orientamenti non obbligatori per gli operatori navali, rivisti nel maggio 2026. Ciò che si chiede agli operatori deriva dalla risoluzione MSC.428(98), che chiede loro di affrontare i rischi cyber nei propri sistemi di gestione della sicurezza, e le linee guida chiedono ora agli operatori di stabilire policy sulla sicurezza della supply chain del software e dell'hardware.
Il CRA si applica al software venduto alle compagnie di navigazione?
Di solito sì, se è venduto sul mercato UE come prodotto con elementi digitali, installato o scaricato, e non è equipaggiamento MED. Il software offerto esclusivamente come servizio è escluso dal CRA, a meno che non costituisca la soluzione di trattamento dati da remoto di un prodotto, anche se la NIS2 può applicarsi al suo fornitore. Verifichi la classificazione di ogni prodotto.
Veda che cosa entra nelle Sue release
Prenoti una demo e Le mostreremo ogni componente scaricato dalle Sue build, e quali delle Sue release sono colpite da una nuova vulnerabilità.
Prenota una demo