Ciberseguridad para fabricantes de software y equipos marítimos
Los buques funcionan ahora con software de decenas de proveedores, y las reglas de clasificación y el derecho de la UE esperan que cada proveedor sepa qué contiene su software y lo mantenga seguro. CRACI ejecuta sus builds de GitHub Actions y registra cada componente que entra en cada versión.
Qué reglas se aplican a qué productos marinos
Un proveedor del sector marítimo responde ante tres regímenes que se solapan pero no coinciden: la legislación de producto de la UE, las reglas de clasificación para buques nuevos y las orientaciones de la Organización Marítima Internacional (OMI) para los operadores de buques. Determine cuál se aplica a cada producto antes de planificar las evidencias.
El CRA excluye los equipos de la Directiva sobre equipos marinos
El artículo 2, apartado 4, del Cyber Resilience Act, Reglamento (UE) 2024/2847, dice: «El presente Reglamento no se aplica a los equipos que entran en el ámbito de aplicación de la Directiva 2014/90/UE». Esa directiva, la Directiva sobre equipos marinos (MED), cubre los equipos instalados o destinados a instalarse a bordo de un buque de la UE para los que los convenios de la OMI exigen la aprobación de la administración del Estado de abanderamiento: los equipos con wheel mark (la marca de la rueda de timón). Son ejemplos los equipos de navegación como el radar, el ECDIS, el AIS y los registradores de datos de la travesía, los equipos de radiocomunicaciones, la protección contra incendios y los dispositivos de salvamento. Compruebe la lista de ejecución vigente de la MED para su propio equipo.
Lo que sigue en el ámbito del CRA
Los productos con elementos digitales introducidos en el mercado de la UE que no son equipos de la MED: software de a bordo y de tierra vendido como producto, instalado o descargado; sistemas de operaciones del buque, de alojamiento, de restauración y de gestión hotelera; sistemas de servicio para la tripulación y los pasajeros; software de gestión de flotas y de viajes; sensores y pasarelas IoT de a bordo; equipos de monitorización y automatización que no necesitan la aprobación del Estado de abanderamiento. El software como servicio por sí solo queda fuera del CRA, salvo que sea el tratamiento remoto de datos de un producto, aunque la NIS2 puede seguir aplicándose a su proveedor.
Algunos casos necesitan una valoración jurídica en lugar de una regla: equipos de un tipo con wheel mark vendidos para buques que no enarbolan pabellón de la UE, y productos que combinan equipos de la MED con módulos de software ajenos a la MED.
IACS UR E26 y E27
Los requisitos unificados de la Asociación Internacional de Sociedades de Clasificación se aplican a través de la clasificación, no del derecho de la UE. La Rev.1 de ambos se aplica a los buques cuyo contrato de construcción se firme el 1 de julio de 2024 o después. Son obligatorios para los buques de pasaje y las naves de gran velocidad en viajes internacionales, los buques de carga de 500 GT o más en viajes internacionales, las unidades móviles de perforación mar adentro y determinadas unidades mar adentro autopropulsadas, y sirven de orientación para los demás buques. Un producto que queda fuera del CRA por la MED puede seguir en el ámbito de E26 y E27, y viceversa.
OMI
La Resolución MSC.428(98) pide a los operadores de buques que aborden los riesgos cibernéticos en sus sistemas de gestión de la seguridad a más tardar en la primera verificación anual del Documento de cumplimiento de la compañía posterior al 1 de enero de 2021. Las directrices de la OMI sobre la gestión de los riesgos cibernéticos marítimos son orientaciones no obligatorias y de alto nivel para los operadores. Su última revisión, de mayo de 2026, dice que la gestión de los riesgos cibernéticos debe tener en cuenta a los proveedores externos, los sistemas embebidos y las cadenas de suministro de software y hardware, y pide a los operadores que establezcan políticas de seguridad de la cadena de suministro de software y hardware para los sistemas críticos. Por eso los operadores trasladan la pregunta a sus proveedores.
| Ejemplo de producto | ¿Con wheel mark (MED)? | Cyber Resilience Act | IACS UR E26 y E27 | Lo que debe demostrar el proveedor |
|---|---|---|---|---|
| ECDIS | Sí | Excluido (artículo 2, apartado 4) | Sí, en buques nuevos dentro del ámbito | Aprobación MED; documentación de E27 e inventario de software |
| Sistema de automatización del motor en un buque de carga de nueva construcción | Comprobar | Sí, salvo que sea un equipo de la MED | Sí: la propulsión es un sistema cubierto | Documentación de E27, inventario y ciclo de vida de desarrollo seguro; documentación técnica y SBOM del CRA |
| Software de gestión hotelera y de restauración | No | Sí, cuando se vende como producto | Comprobar: E26 cubre su interfaz de red con los sistemas cubiertos | SBOM y gestión de vulnerabilidades para el CRA |
| Equipos de red para el bienestar de la tripulación | No | Sí | Comprobar: E26 cubre su interfaz con los sistemas cubiertos | SBOM y gestión de vulnerabilidades para el CRA |
| Software de gestión de flotas como servicio | No | Fuera, salvo que sea el tratamiento remoto de datos de un producto | No: funciona en tierra | Respuestas a los cuestionarios de proveedores de los operadores; la NIS2 puede aplicarse al proveedor |
| Sensores de monitorización del estado a bordo | Comprobar | Sí, salvo que sean equipos de la MED | Comprobar: dentro del ámbito cuando forman parte de un sistema cubierto | SBOM del CRA; documentación de E27 cuando forman parte de un sistema cubierto |
La regla práctica: si su producto necesita wheel mark, el CRA no se le aplica; si va en un buque contratado a partir de julio de 2024, probablemente se le aplica E27; si vende software o productos conectados en la UE, dé por hecho que se aplica el CRA.
Qué piden E26 y E27 a los proveedores
E27 es el requisito que llega directamente a los proveedores de equipos. La sección 3.1 enumera los documentos que un proveedor presenta a la sociedad de clasificación para un sistema informático, entre ellos:
- Un inventario de activos (3.1.1): los componentes de hardware, con el nombre, la versión y el nivel de parches de su software de sistema, como el sistema operativo y el firmware, y los componentes de software, cada uno con el hardware en el que está instalado, su fabricante, modelo o tipo, finalidad y versión de software.
- Una descripción de las capacidades de seguridad (3.1.3) y su procedimiento de prueba, directrices de configuración de seguridad y planes de mantenimiento, respuesta a incidentes, recuperación y gestión del cambio.
- Documentos del ciclo de vida de desarrollo seguro (3.1.6), que también describen cómo se gestionan las actualizaciones y los parches de software.
La sección 4 establece las capacidades de seguridad exigidas, basadas en una selección de requisitos de sistema de IEC 62443-3-3, como la autenticación y la protección contra código malicioso. Son capacidades del producto.
La sección 5 exige un ciclo de vida de desarrollo seguro que cubra requisitos, diseño, implementación, verificación, publicación, mantenimiento y fin de vida, recogido en un documento que revisa la sociedad de clasificación. Debe incluir controles tomados de IEC 62443-4-1: protección de las claves de firma de código (SM-8), documentación de las actualizaciones de seguridad para los usuarios (SUM-2), documentación de las actualizaciones de seguridad de los componentes dependientes o del sistema operativo (SUM-3), entrega auténtica de las actualizaciones (SUM-4) y directrices de defensa en profundidad y de bastionado (SG-1 a SG-3).
E26 cierra el círculo a nivel de buque: el inventario de activos del buque, de hardware y software, con los campos del inventario E27 de cada proveedor, se mantiene actualizado durante toda la vida del buque, y en él se registran los cambios de software y hardware que pueden introducir nuevas vulnerabilidades.
Lo que E27 no dice: no menciona las SBOM. Una SBOM por versión es la forma más precisa de obtener las versiones de software para el inventario y la información de SUM-3 sobre los componentes dependientes, pero respalda esos requisitos en lugar de ser uno de ellos.
| Requisito de E26 o E27 | Lo que espera la sociedad de clasificación o el astillero | Evidencias del build | Lo que sigue siendo cosa suya |
|---|---|---|---|
| Inventario de activos de E27 (3.1.1) | Cada componente de software con su finalidad y versión, y el software de sistema de cada componente de hardware | Una SBOM por versión, con cada componente y su versión | En qué hardware está instalado cada componente, y los datos de fabricante y modelo |
| Documentación de actualizaciones SUM-2 y SUM-3 | Actualizaciones de seguridad documentadas, también para componentes dependientes y sistemas operativos | Registros de vulnerabilidades e historial de builds de los componentes de cada versión | Las notas de actualización y los avisos que envía a los usuarios |
| SM-8 y SUM-4 | Claves de firma de código protegidas y entrega auténtica de las actualizaciones | Ninguna: CRACI no firma software | Su proceso de firma y el almacenamiento de claves |
| Capacidades de seguridad de la sección 4 | Autenticación, protección contra código malicioso y otras capacidades del producto | Ninguna: son funciones del producto | El diseño del producto y sus pruebas |
| Documento del ciclo de vida de la sección 5 | Una descripción revisada de cómo se gestiona la seguridad en cada fase | Registros de que la fase de publicación está controlada: qué contenía cada build y a qué podía llegar | Redactar el documento y aplicar el proceso |
| Inventario de activos del buque de E26 | El inventario del buque, mantenido actualizado durante toda su vida | Sus exportaciones de SBOM, entregadas al integrador | Qué versión está instalada en qué buque, y la entrega al astillero o al integrador |
Por qué es difícil seguir la pista al software marítimo
Los buques duran más que los proyectos. Un buque sigue en servicio durante décadas, y la carga de soporte del software de a bordo dura más que el proyecto que lo entregó, el equipo que lo construyó y, a menudo, la propia línea de productos del proveedor.
Muchos proveedores e integradores pequeños. Un solo buque lleva software de decenas de proveedores, ensamblado por un integrador, y cada entrega es una ocasión de perder la pista de lo que contiene cada versión.
Los sistemas de a bordo no se pueden actualizar a voluntad. Las actualizaciones esperan a una escala en puerto, a la aprobación de la clase o a una ventana de mantenimiento, por lo que las versiones antiguas siguen en servicio mucho después de que exista una corrección. Necesita saber qué buques siguen ejecutando qué versión.
Ubicaciones remotas, conectividad limitada. Los buques en el mar y las instalaciones remotas son de difícil acceso, por lo que el registro de lo que se instaló tiene que existir en tierra, a partir del build, y no del escaneo del buque.
Hojas de cálculo como sistema de registro. Los fabricantes de software marítimo nos cuentan que las SBOM y los registros relacionados viven en muchas hojas de cálculo, mantenidas a mano. Se desactualizan con cada versión.
Cómo prepararse, paso a paso
Las capacidades de seguridad, como la autenticación, forman parte del diseño del producto. Los pasos siguientes cubren las evidencias sobre el software que entra en él.
- Asigne cada producto a su régimen. Para cada producto, decida si es un equipo de la MED, un producto del CRA, si está en el ámbito de E26 y E27, o varias de estas cosas. El plan de evidencias se deriva de ese mapa.
- Produzca una SBOM de cada versión. Registre lo que entra en cada versión de cada producto que construye, incluidas las dependencias transitivas, para que el inventario de software salga del build y no de la memoria.
- Mantenga un inventario por instalación. Registre qué versión está instalada en qué buque y cuándo cambió. Esto alimenta el inventario de activos de E27 y el inventario de activos del buque de E26 del integrador, que registra los cambios durante toda la vida del buque.
- Monitorice las vulnerabilidades y notifique. Vuelva a comprobar las versiones distribuidas a medida que se publican nuevas vulnerabilidades. Para los productos dentro del ámbito del CRA, la notificación de vulnerabilidades activamente explotadas e incidentes graves se aplica desde el 11 de septiembre de 2026.
- Impida que entren en los builds paquetes con vulnerabilidades conocidas. Bloquee un build que fuera a distribuir una vulnerabilidad conocida, para que no vuelva a través de una actualización de dependencias.
- Documente las actualizaciones de seguridad para clientes e integradores. Explique a clientes e integradores qué corrige cada actualización de seguridad, incluidas las correcciones en componentes dependientes y en el sistema operativo, como esperan SUM-2 y SUM-3.
Dónde encaja CRACI
CRACI ejecuta sus builds de GitHub Actions en sus propios runners y registra lo que entra en cada versión. Ese registro es la evidencia común que respalda el CRA, su documentación de E27 y las preguntas de sus clientes.
Cada versión, registrada
Sus builds se ejecutan en los runners de GitHub Actions de CRACI con runs-on: craci, y las ejecuciones siguen apareciendo en GitHub. Mientras se ejecuta cada build, CRACI registra cada paquete que descarga, npm y PyPI incluidos, con las dependencias ocultas que ningún lockfile enumera y un estado de completitud para cada job. Las SBOM se exportan en CycloneDX o SPDX con las dependencias transitivas, las licencias declaradas y las vulnerabilidades encontradas en sus componentes: la materia prima para la parte de software de un inventario de activos de E27. Más información sobre las SBOM del build.
Mantenga fuera los paquetes vulnerables
Los controles de política pueden bloquear un build que contenga un CVE concreto, y las reglas de política de licencias pueden bloquear un build por una licencia. Un problema conocido se detecta en la CI, antes de que la versión llegue a un buque.
Sepa qué versiones están afectadas
CRACI sigue reevaluando las SBOM monitorizadas a medida que se publican nuevas vulnerabilidades, y el historial de builds muestra qué builds contenían la dependencia vulnerable, dentro del período de retención de su plan. La vista de inventario muestra qué versiones de software están desplegadas en qué productos. Los equipos de seguridad hacen el triaje de cada hallazgo y lo envían al equipo responsable de la corrección. Para los productos sujetos al CRA, CRACI prepara el contenido de las notificaciones del CRA, y una persona de su empresa las presenta a través de la Single Reporting Platform.
Un build que no puede filtrar sus secretos
Cada job se ejecuta en su propia máquina virtual aislada bajo una política de egress que puede configurar con denegación por defecto, validada antes de que empiece el job y que, si falla, bloquea. Con una política de denegación por defecto, una conexión a un host que el build no necesita queda bloqueada y activa una alerta.
Cuándo CRACI no es la respuesta
CRACI es para equipos que construyen software. No encaja en estos casos:
- No para operadores y armadores de buques que buscan monitorización de la red de a bordo, detección de intrusiones, cumplimiento de E26 a nivel de buque o documentación para su sistema de gestión de la seguridad. CRACI es para quienes construyen el software, no para la flota que lo utiliza.
- No es un programa del CRA para fabricantes de equipos de la MED: los equipos con wheel mark quedan fuera del CRA. CRACI puede seguir registrando los builds de software que hay detrás para E27 y para las solicitudes de los clientes, si se ejecutan en GitHub Actions.
- No para proveedores que no construyen en GitHub Actions, que necesitan máquinas de build Windows o macOS, o que necesitan runners dentro de su propia cuenta en la nube. Hoy CRACI ofrece runners Linux gestionados en infraestructura europea; otros sistemas de CI, los runners Windows y macOS y los runners alojados por el cliente están en la hoja de ruta.
- No para listas de materiales de hardware. CRACI registra software; no gestiona BOM de hardware.
- No las capacidades de seguridad de E27 ni una aprobación de clase. CRACI no implementa autenticación, protección contra malware ni otras capacidades del producto, no firma software, no redacta su documento de ciclo de vida de desarrollo seguro y no trata con la sociedad de clasificación en su nombre.
- No es una herramienta de métricas de corrección: CRACI no informa del tiempo medio de corrección ni de plazos de corrección.
La ciberseguridad marítima, explicada
Preguntas habituales sobre el CRA, IACS UR E26 y E27 y las directrices de la OMI para proveedores del sector marítimo
¿Se aplica el Cyber Resilience Act a los equipos marinos?
No a los equipos dentro del ámbito de la Directiva sobre equipos marinos, 2014/90/UE. El artículo 2, apartado 4, del CRA los excluye expresamente. Eso cubre los equipos con wheel mark que necesitan la aprobación del Estado de abanderamiento conforme a los convenios de la OMI. Otros productos conectados y software vendidos para buques, como sistemas hoteleros, redes de tripulación, sensores y software de flota instalado a bordo, pueden seguir sujetos al CRA.
¿Qué productos marinos están excluidos del CRA?
Los equipos dentro del ámbito de la Directiva sobre equipos marinos: equipos instalados a bordo de buques de la UE para los que los convenios de la OMI exigen la aprobación del Estado de abanderamiento, como el radar, el ECDIS, el AIS, los registradores de datos de la travesía, las radiocomunicaciones, la protección contra incendios y los equipos de salvamento. Compruebe la lista de ejecución vigente de la MED para su equipo, y pida una valoración jurídica para productos mixtos o buques con otros pabellones.
¿Qué es IACS UR E27 y quién tiene que cumplirlo?
UR E27 es el requisito unificado de la Asociación Internacional de Sociedades de Clasificación sobre la ciberresiliencia de los sistemas y equipos de a bordo. La Rev.1 se aplica a los buques cuyo contrato de construcción se firme el 1 de julio de 2024 o después, y es obligatoria para los buques de pasaje, las naves de gran velocidad y los buques de carga de 500 GT o más en viajes internacionales, y para determinadas unidades mar adentro. Los proveedores de sistemas cubiertos lo cumplen a través de la sociedad de clasificación.
¿Qué exigen E26 y E27 a los proveedores de equipos?
E27 pide a los proveedores documentación que incluye un inventario de activos que enumere cada componente de software con su versión, capacidades de seguridad tomadas de IEC 62443-3-3 y un ciclo de vida de desarrollo seguro con controles de IEC 62443-4-1, como la documentación de las actualizaciones de seguridad. E26 es el requisito a nivel de buque: el inventario de activos del buque usa los mismos campos y se mantiene actualizado durante toda la vida del buque.
¿Exige UR E27 una SBOM?
No. E27 no menciona las SBOM. Pide un inventario de activos que enumere cada componente de software con su versión, y documentación de las actualizaciones de seguridad de los componentes dependientes y del sistema operativo. Una SBOM por versión es la forma más precisa de obtener esa información, pero no es un requisito de E27.
¿Son obligatorias las directrices de la OMI sobre gestión de los riesgos cibernéticos?
No. Las directrices de la OMI sobre la gestión de los riesgos cibernéticos marítimos son orientaciones no obligatorias para los operadores de buques, revisadas en mayo de 2026. Lo que se espera de los operadores procede de la Resolución MSC.428(98), que les pide abordar los riesgos cibernéticos en sus sistemas de gestión de la seguridad, y las directrices piden ahora a los operadores que establezcan políticas de seguridad de la cadena de suministro de software y hardware.
¿Se aplica el CRA al software vendido a las navieras?
Normalmente sí, si se vende en el mercado de la UE como producto con elementos digitales, instalado o descargado, y no es un equipo de la MED. El software ofrecido puramente como servicio queda fuera del CRA, salvo que sea el tratamiento remoto de datos de un producto, aunque la NIS2 puede aplicarse a su proveedor. Compruebe la clasificación de cada producto.
Vea lo que entra en sus versiones
Reserve una demo y le mostraremos cada componente que descargan sus builds, y a qué versiones afecta una nueva vulnerabilidad.
Reservar una demo