Cybersécurité pour les fabricants de logiciels et d'équipements maritimes
Les navires fonctionnent désormais avec des logiciels de dizaines de fournisseurs, et les règles de classification comme le droit européen attendent de chaque fournisseur qu'il sache ce que contiennent ses logiciels et qu'il les maintienne sécurisés. CRACI exécute vos builds GitHub Actions et enregistre chaque composant qui entre dans chaque release.
Quelles règles s'appliquent à quels produits maritimes
Un fournisseur du secteur maritime relève de trois régimes qui se recoupent sans coïncider : le droit européen des produits, les règles de classification des navires neufs et les orientations de l'OMI destinées aux exploitants de navires. Déterminez lequel s'applique à chaque produit avant de planifier les preuves.
Le CRA exclut les équipements relevant de la directive relative aux équipements marins
L'article 2(4) du Cyber Resilience Act, le règlement (UE) 2024/2847, dispose : « Le présent règlement ne s'applique pas aux équipements relevant du champ d'application de la directive 2014/90/UE. » Cette directive, la directive relative aux équipements marins (MED), couvre les équipements placés ou destinés à être placés à bord d'un navire de l'UE pour lesquels les conventions de l'OMI exigent l'approbation de l'administration de l'État du pavillon : les équipements portant le wheel mark (marque « barre à roue »). Il s'agit par exemple des équipements de navigation comme le radar, l'ECDIS, l'AIS et les enregistreurs des données du voyage, des équipements de radiocommunication, de la protection contre l'incendie et des engins de sauvetage. Vérifiez la liste d'exécution MED en vigueur pour votre propre équipement.
Ce qui reste dans le champ du CRA
Les produits comportant des éléments numériques mis sur le marché de l'UE qui ne sont pas des équipements MED : logiciels de bord et à terre vendus comme produit, installés ou téléchargés ; systèmes de gestion des opérations du navire, de l'hébergement, de la restauration et de l'hôtellerie ; systèmes de services pour l'équipage et les passagers ; logiciels de gestion de flotte et de voyage ; capteurs et passerelles IoT embarqués ; équipements de surveillance et d'automatisation qui ne nécessitent pas l'approbation de l'État du pavillon. Un logiciel en tant que service seul est hors du champ du CRA, sauf s'il constitue la solution de traitement de données à distance d'un produit, même si NIS2 peut encore s'appliquer à son fournisseur.
Certains cas demandent un avis juridique plutôt qu'une règle : les équipements d'un type portant le wheel mark vendus pour des navires qui ne battent pas pavillon d'un État de l'UE, et les produits qui combinent un équipement MED avec des modules logiciels hors MED.
IACS UR E26 et E27
Les exigences unifiées de l'International Association of Classification Societies s'appliquent par la classification, pas par le droit européen. La Rev.1 de chacune s'applique aux navires dont le contrat de construction est signé le 1er juillet 2024 ou après. Elles sont obligatoires pour les navires à passagers et les engins à grande vitesse effectuant des voyages internationaux, les navires de charge de 500 GT et plus effectuant des voyages internationaux, les unités mobiles de forage au large et certaines unités offshore autopropulsées, et servent d'orientation pour les autres navires. Un produit exclu du CRA en raison de la MED peut tout de même relever d'E26 et d'E27, et inversement.
OMI
La résolution MSC.428(98) demande aux exploitants de navires de traiter les cyberrisques dans leurs systèmes de gestion de la sécurité au plus tard lors de la première vérification annuelle du document de conformité de la compagnie après le 1er janvier 2021. Les directives de l'OMI sur la gestion des cyberrisques maritimes sont des orientations générales non obligatoires destinées aux exploitants. Leur dernière révision, de mai 2026, indique que la gestion des cyberrisques doit tenir compte des fournisseurs tiers, des systèmes embarqués et des chaînes d'approvisionnement logicielles et matérielles, et demande aux exploitants d'établir des politiques de sécurité de la chaîne d'approvisionnement logicielle et matérielle pour les systèmes critiques. C'est pourquoi les exploitants transmettent la question à leurs fournisseurs.
| Exemple de produit | Wheel mark (MED) ? | Cyber Resilience Act | IACS UR E26 et E27 | Ce que le fournisseur doit démontrer |
|---|---|---|---|---|
| ECDIS | Oui | Exclu (article 2(4)) | Oui, sur les navires neufs concernés | Approbation MED ; documentation E27 et inventaire logiciel |
| Système d'automatisation des machines sur un navire de charge neuf | À vérifier | Oui, sauf s'il s'agit d'un équipement MED | Oui : la propulsion est un système couvert | Documentation E27, inventaire et cycle de développement sécurisé ; documentation technique CRA et SBOM |
| Logiciel de gestion hôtelière et de restauration | Non | Oui, lorsqu'il est vendu comme produit | À vérifier : E26 couvre son interface réseau avec les systèmes couverts | SBOM et traitement des vulnérabilités pour le CRA |
| Équipement réseau pour le bien-être de l'équipage | Non | Oui | À vérifier : E26 couvre son interface avec les systèmes couverts | SBOM et traitement des vulnérabilités pour le CRA |
| Logiciel de gestion de flotte en tant que service | Non | Hors champ, sauf s'il constitue la solution de traitement de données à distance d'un produit | Non : il fonctionne à terre | Réponses aux questionnaires fournisseurs des exploitants ; NIS2 peut s'appliquer au fournisseur |
| Capteurs de surveillance de l'état embarqués | À vérifier | Oui, sauf s'il s'agit d'équipements MED | À vérifier : concernés lorsqu'ils font partie d'un système couvert | SBOM CRA ; documentation E27 lorsqu'ils font partie d'un système couvert |
La règle empirique : si votre produit a besoin d'un wheel mark, le CRA ne s'y applique pas ; s'il est installé sur un navire dont le contrat date de juillet 2024 ou après, E27 s'applique probablement ; si vous vendez des logiciels ou des produits connectés dans l'UE, partez du principe que le CRA s'applique.
Ce qu'E26 et E27 demandent aux fournisseurs
E27 est l'exigence qui atteint directement les fournisseurs d'équipements. Sa section 3.1 liste les documents qu'un fournisseur soumet à la société de classification pour un système informatisé, notamment :
- Un inventaire des actifs (3.1.1) : les composants matériels, avec le nom, la version et le niveau de correctifs de leur logiciel système, comme le système d'exploitation et le firmware, et les composants logiciels, chacun avec le matériel sur lequel il est installé, son fabricant, son modèle ou type, sa fonction et sa version logicielle.
- Une description des capacités de sécurité (3.1.3) et de leur procédure de test, des lignes directrices de configuration de sécurité, et des plans de maintenance, de réponse aux incidents, de reprise et de gestion des changements.
- Les documents du cycle de développement sécurisé (3.1.6), qui décrivent aussi la façon dont les mises à jour logicielles et les correctifs sont gérés.
La section 4 fixe les capacités de sécurité requises, sur la base d'une sélection d'exigences système de l'IEC 62443-3-3, comme l'authentification et la protection contre les codes malveillants. Ce sont des capacités du produit.
La section 5 exige un cycle de développement sécurisé couvrant les exigences, la conception, la mise en œuvre, la vérification, la mise en production, la maintenance et la fin de vie, consigné dans un document que la société de classification examine. Il doit inclure des contrôles issus de l'IEC 62443-4-1 : protection des clés de signature de code (SM-8), documentation des mises à jour de sécurité pour les utilisateurs (SUM-2), documentation des mises à jour de sécurité des composants dépendants ou du système d'exploitation (SUM-3), livraison authentique des mises à jour (SUM-4), et recommandations de défense en profondeur et de durcissement (SG-1 à SG-3).
E26 boucle la boucle au niveau du navire : l'inventaire des actifs du navire, matériels et logiciels, avec les champs de l'inventaire E27 de chaque fournisseur, est tenu à jour pendant toute la vie du navire, et les modifications logicielles et matérielles susceptibles d'introduire de nouvelles vulnérabilités y sont consignées.
Ce qu'E27 ne dit pas : il ne mentionne pas les SBOM. Une SBOM par release est le moyen le plus précis de produire les versions logicielles de l'inventaire et les informations SUM-3 sur les composants dépendants, mais elle soutient ces exigences plutôt que d'en être une.
| Exigence E26 ou E27 | Ce qu'attend la société de classification ou le chantier naval | Preuves issues du build | Ce qui reste de votre ressort |
|---|---|---|---|
| Inventaire des actifs E27 (3.1.1) | Chaque composant logiciel avec sa fonction et sa version, et le logiciel système de chaque composant matériel | Une SBOM par release, avec chaque composant et sa version | Le matériel sur lequel chaque composant est installé, les informations de fabricant et de modèle |
| Documentation des mises à jour SUM-2 et SUM-3 | Des mises à jour de sécurité documentées, y compris pour les composants dépendants et les systèmes d'exploitation | Enregistrements de vulnérabilités et historique des builds pour les composants de chaque release | Les notes de mise à jour et les avis de sécurité que vous envoyez aux utilisateurs |
| SM-8 et SUM-4 | Des clés de signature de code protégées et une livraison authentique des mises à jour | Aucune : CRACI ne signe pas les logiciels | Votre processus de signature et le stockage de vos clés |
| Capacités de sécurité de la section 4 | Authentification, protection contre les codes malveillants et autres capacités du produit | Aucune : ce sont des fonctions du produit | La conception du produit et ses tests |
| Document de cycle de vie de la section 5 | Une description examinée de la façon dont la sécurité est traitée à chaque phase | Des enregistrements montrant que la phase de mise en production est maîtrisée : ce que chaque build contenait et ce qu'il pouvait atteindre | La rédaction du document et la conduite du processus |
| Inventaire des actifs du navire E26 | L'inventaire du navire, tenu à jour pendant toute sa vie | Vos exports de SBOM, remis à l'intégrateur | La version installée sur chaque navire, et la remise au chantier naval ou à l'intégrateur |
Pourquoi les logiciels maritimes sont difficiles à suivre
Les navires survivent aux projets. Un navire reste en service pendant des décennies, et la charge du support des logiciels embarqués dure plus longtemps que le projet qui les a livrés, l'équipe qui les a construits et souvent la gamme de produits du fournisseur elle-même.
De nombreux petits fournisseurs et intégrateurs. Un seul navire embarque des logiciels de dizaines de fournisseurs, assemblés par un intégrateur, et chaque passation est une occasion de perdre la trace de ce que contient chaque release.
Les systèmes embarqués ne peuvent pas être mis à jour à volonté. Les mises à jour attendent les escales, l'approbation de la classe ou une fenêtre de maintenance : les anciennes versions restent donc en service longtemps après qu'un correctif existe. Vous devez savoir quels navires exécutent encore quelle version.
Des sites isolés, une connectivité limitée. Les navires en mer et les installations isolées sont difficiles à atteindre : l'enregistrement de ce qui a été installé doit donc exister à terre, à partir du build, et non à partir d'un scan du navire.
Des tableurs comme système de référence. Les éditeurs de logiciels maritimes nous disent que les SBOM et les enregistrements associés sont répartis dans de nombreux tableurs, tenus à la main. Ils deviennent obsolètes à chaque release.
Comment se préparer, étape par étape
Les capacités de sécurité comme l'authentification relèvent de la conception du produit. Les étapes ci-dessous portent sur les preuves concernant les logiciels qui y entrent.
- Associez chaque produit à son régime. Pour chaque produit, déterminez s'il s'agit d'un équipement MED, d'un produit CRA, d'un produit relevant d'E26 et d'E27, ou de plusieurs à la fois. Le plan de preuves découle de cette cartographie.
- Produisez une SBOM pour chaque release. Enregistrez ce qui entre dans chaque release de chaque produit que vous construisez, y compris les dépendances transitives, afin que l'inventaire logiciel provienne du build et non de la mémoire.
- Tenez un inventaire par installation. Suivez quelle version est installée sur quel navire et quand elle a changé. Cela alimente l'inventaire des actifs E27 et l'inventaire des actifs du navire E26 de l'intégrateur, qui consigne les modifications pendant toute la vie du navire.
- Surveillez les vulnérabilités et signalez-les. Revérifiez les releases livrées à mesure que de nouvelles vulnérabilités sont publiées. Pour les produits dans le champ du CRA, le signalement des vulnérabilités activement exploitées et des incidents graves s'applique depuis le 11 septembre 2026.
- Empêchez les paquets réputés vulnérables d'entrer dans les builds. Bloquez un build qui livrerait une vulnérabilité connue, afin qu'elle ne revienne pas par une mise à jour de dépendance.
- Documentez les mises à jour de sécurité pour les clients et les intégrateurs. Indiquez aux clients et aux intégrateurs ce que corrige chaque mise à jour de sécurité, y compris les correctifs dans les composants dépendants et le système d'exploitation, comme l'attendent SUM-2 et SUM-3.
La place de CRACI
CRACI exécute vos builds GitHub Actions sur ses propres runners et enregistre ce qui entre dans chaque release. Cet enregistrement est la preuve commune derrière le CRA, votre documentation E27 et les questions de vos clients.
Chaque release enregistrée
Vos builds s'exécutent sur les runners GitHub Actions de CRACI avec runs-on: craci, et les exécutions apparaissent toujours dans GitHub. Pendant chaque build, CRACI enregistre chaque paquet récupéré, npm et PyPI compris, avec les dépendances cachées qu'aucun lockfile ne liste et un état de complétude pour chaque job. Les SBOM s'exportent en CycloneDX ou SPDX avec les dépendances transitives, les licences déclarées et les vulnérabilités trouvées dans leurs composants : la matière première de la partie logicielle d'un inventaire des actifs E27. En savoir plus sur les SBOM au build.
Tenez les paquets vulnérables à l'écart
Les garde-fous de politique peuvent bloquer un build qui contient une CVE précise, et des règles de politique de licences peuvent bloquer un build en raison d'une licence. Un problème connu est détecté dans la CI, avant que la release n'atteigne un navire.
Sachez quelles releases sont touchées
CRACI continue de réévaluer les SBOM surveillées à mesure que de nouvelles vulnérabilités sont publiées, et l'historique des builds montre quels builds contenaient la dépendance vulnérable, dans la limite de la durée de conservation de votre offre. La vue d'inventaire montre quelles versions logicielles sont déployées sur quels produits. Les équipes de sécurité trient chaque résultat et l'acheminent vers l'équipe responsable de la correction. Pour les produits relevant du CRA, CRACI prépare le contenu des notifications CRA, et une personne de votre entreprise les soumet via la Single Reporting Platform.
Un build qui ne peut pas divulguer vos secrets
Chaque job s'exécute dans sa propre machine virtuelle isolée, sous une politique de trafic sortant que vous pouvez régler en refus par défaut, validée avant le démarrage du job et qui bloque tout en cas d'échec. Avec une politique en refus par défaut, une connexion vers un hôte dont le build n'a pas besoin est bloquée et déclenche une alerte.
Quand CRACI n'est pas la solution
CRACI s'adresse aux équipes qui construisent des logiciels. Il ne convient pas dans ces cas :
- Pas pour les exploitants et armateurs de navires qui cherchent une surveillance du réseau de bord, une détection d'intrusion, la conformité E26 au niveau du navire ou une documentation pour leur système de gestion de la sécurité. CRACI s'adresse à ceux qui construisent les logiciels, pas à la flotte qui les exécute.
- Pas un programme CRA pour les fabricants d'équipements MED : les équipements portant le wheel mark sont hors du champ du CRA. CRACI peut tout de même enregistrer les builds logiciels qui les sous-tendent pour E27 et pour les demandes des clients, s'ils s'exécutent sur GitHub Actions.
- Pas pour les fournisseurs qui ne construisent pas sur GitHub Actions, qui ont besoin de machines de build Windows ou macOS, ou de runners dans leur propre compte cloud. CRACI exploite aujourd'hui des runners Linux managés sur une infrastructure européenne ; d'autres systèmes CI, les runners Windows et macOS et les runners hébergés par le client figurent sur la roadmap.
- Pas pour les nomenclatures matérielles. CRACI enregistre les logiciels ; il ne gère pas les BOM matérielles.
- Pas les capacités de sécurité E27 ni une approbation de classe. CRACI n'implémente pas l'authentification, la protection contre les malwares ni d'autres capacités du produit, ne signe pas les logiciels, ne rédige pas votre document de cycle de développement sécurisé et ne traite pas avec la société de classification à votre place.
- Pas un outil de métriques de remédiation : CRACI ne rend compte ni du délai moyen de remédiation ni des échéances de remédiation.
La cybersécurité maritime expliquée
Questions fréquentes sur le CRA, l'IACS UR E26 et E27 et les directives de l'OMI pour les fournisseurs maritimes
Le Cyber Resilience Act s'applique-t-il aux équipements marins ?
Pas aux équipements relevant du champ d'application de la directive relative aux équipements marins, 2014/90/UE. L'article 2(4) du CRA les exclut purement et simplement. Cela couvre les équipements portant le wheel mark qui nécessitent l'approbation de l'État du pavillon au titre des conventions de l'OMI. D'autres produits connectés et logiciels vendus pour les navires, comme les systèmes hôteliers, les réseaux d'équipage, les capteurs et les logiciels de flotte installés à bord, peuvent encore relever du CRA.
Quels produits maritimes sont exclus du CRA ?
Les équipements relevant du champ d'application de la directive relative aux équipements marins : équipements placés à bord des navires de l'UE pour lesquels les conventions de l'OMI exigent l'approbation de l'État du pavillon, comme le radar, l'ECDIS, l'AIS, les enregistreurs des données du voyage, la radiocommunication, la protection contre l'incendie et les engins de sauvetage. Vérifiez la liste d'exécution MED en vigueur pour votre équipement, et demandez un avis juridique pour les produits mixtes ou les navires sous d'autres pavillons.
Qu'est-ce que l'IACS UR E27, et qui doit s'y conformer ?
L'UR E27 est l'exigence unifiée de l'International Association of Classification Societies sur la cyberrésilience des systèmes et équipements de bord. La Rev.1 s'applique aux navires dont le contrat de construction est signé le 1er juillet 2024 ou après, et elle est obligatoire pour les navires à passagers, les engins à grande vitesse et les navires de charge de 500 GT et plus effectuant des voyages internationaux, ainsi que pour certaines unités offshore. Les fournisseurs de systèmes couverts s'y conforment par l'intermédiaire de la société de classification.
Qu'exigent E26 et E27 des fournisseurs d'équipements ?
E27 demande aux fournisseurs une documentation comprenant un inventaire des actifs qui liste chaque composant logiciel avec sa version, des capacités de sécurité tirées de l'IEC 62443-3-3, et un cycle de développement sécurisé avec des contrôles issus de l'IEC 62443-4-1, comme la documentation des mises à jour de sécurité. E26 est l'exigence au niveau du navire : l'inventaire des actifs du navire utilise les mêmes champs et est tenu à jour pendant toute la vie du navire.
L'UR E27 exige-t-elle une SBOM ?
Non. E27 ne mentionne pas les SBOM. Elle demande un inventaire des actifs qui liste chaque composant logiciel avec sa version, et une documentation des mises à jour de sécurité des composants dépendants et du système d'exploitation. Une SBOM par release est le moyen le plus précis de produire ces informations, mais ce n'est pas une exigence d'E27.
Les directives de l'OMI sur la gestion des cyberrisques sont-elles obligatoires ?
Non. Les directives de l'OMI sur la gestion des cyberrisques maritimes sont des orientations non obligatoires destinées aux exploitants de navires, révisées en mai 2026. Ce que l'on attend des exploitants découle de la résolution MSC.428(98), qui leur demande de traiter les cyberrisques dans leurs systèmes de gestion de la sécurité, et les directives demandent désormais aux exploitants de fixer des politiques de sécurité de la chaîne d'approvisionnement logicielle et matérielle.
Le CRA s'applique-t-il aux logiciels vendus aux compagnies maritimes ?
En général oui, s'ils sont vendus sur le marché de l'UE comme produit comportant des éléments numériques, installés ou téléchargés, et ne sont pas des équipements MED. Un logiciel proposé uniquement en tant que service est hors du champ du CRA, sauf s'il constitue la solution de traitement de données à distance d'un produit, même si NIS2 peut s'appliquer à son fournisseur. Vérifiez la classification de chaque produit.
Découvrez ce qui entre dans vos releases
Réservez une démo et nous vous montrerons chaque composant récupéré par vos builds, et lesquelles de vos releases sont touchées par une nouvelle vulnérabilité.
Réserver une démo