Qué le pide el CRA a tu firmware Linux y qué puedes comprobar hoy

El Reglamento (UE) 2024/2847, el Cyber Resilience Act, está en vigor desde diciembre de 2024. Desde el 11 de septiembre de 2026 los fabricantes tienen que notificar las vulnerabilidades explotadas activamente y los incidentes graves. El 11 de diciembre de 2027 se aplica el reglamento completo: requisitos esenciales, documentación técnica y marcado CE con la ciberseguridad dentro.

Si fabricas un producto con Linux embebido y lo vendes en la Unión Europea, esto te afecta. Lo que sigue es una traducción de lo que pide el reglamento a lo que eso significa para una imagen de Yocto o Buildroot, y una lista corta de cosas que puedes comprobar hoy sin contratar a nadie.

Qué pide el reglamento, en términos de firmware

El anexo I del CRA tiene dos partes. La primera describe cómo tiene que ser el producto; la segunda, cómo tienes que gestionar sus vulnerabilidades durante toda su vida útil. Resumido para un dispositivo Linux:

Sobre el producto

• Sin vulnerabilidades explotables conocidas en el momento de la entrega. No dice “sin CVEs”, dice sin vulnerabilidades explotables conocidas. La diferencia importa: un kernel con 200 CVEs listadas puede ser aceptable si ninguna es explotable en tu configuración; una sola CVE en un servicio expuesto a la red no lo es.
• Configuración segura por defecto. Sin contraseñas por defecto, sin servicios de depuración activos en producción, sin puertos abiertos que no hagan falta.
• Integridad y actualizaciones seguras. El dispositivo tiene que poder recibir actualizaciones de seguridad, y esas actualizaciones tienen que estar protegidas: firma, verificación, y a ser posible vuelta atrás si algo falla. Aquí entran secure boot y el mecanismo OTA.
• Protección de datos y de la comunicación. Cifrado en las comunicaciones, almacenamiento protegido de credenciales y claves.
• Registro de eventos de seguridad. El dispositivo tiene que registrar lo relevante para la seguridad de forma que no se pueda manipular sin que se note.
• Reducción de superficie de ataque. Lo que no se usa, no se incluye.

Sobre la gestión de vulnerabilidades

• Inventario de componentes (SBOM) en un formato legible por máquina, al menos de las dependencias de primer nivel. Sin inventario no puedes saber si una vulnerabilidad nueva te afecta.
• Proceso para tratar vulnerabilidades: cómo las detectas, cómo las corriges, cómo distribuyes el parche.
• Punto de contacto para reportes y una política de divulgación coordinada.
• Notificación a la autoridad en 24 horas de los casos graves, con informe a las 72 horas.
• Soporte durante el periodo previsto, con un mínimo de cinco años salvo que el producto esté diseñado para durar menos.

Lo que más cuesta a los fabricantes que conozco no es la lista en sí. Es que la mayoría de productos en el mercado se construyeron sin ninguno de estos mecanismos, con un BSP del fabricante del módulo que nadie ha actualizado desde la fecha de lanzamiento.

Cinco cosas que puedes comprobar hoy

No necesitas una auditoría para hacerte una idea de dónde estás. Con la imagen de producción y una tarde:

1. Genera un SBOM y cuenta los paquetes

Con Syft sobre el rootfs o sobre la imagen:

syft dir:./rootfs -o spdx-json > sbom.spdx.json

Si usas Yocto, compara el resultado con el manifest que genera el build en tmp/deploy/images/<máquina>/. Las diferencias te dicen cuánto se fía tu SBOM de lo que de verdad hay en la imagen.

2. Pásale un escáner de vulnerabilidades

Con Grype sobre ese SBOM:

grype sbom:sbom.spdx.json -o table

El número total asusta siempre. No te quedes con él. Filtra por severidad y, sobre todo, pregúntate para cada CVE alta si el componente afectado está expuesto en tu dispositivo. Un curl vulnerable que solo se usa en un script interno no es lo mismo que un dropbear vulnerable escuchando en el puerto 22.

3. Mira qué escucha en la red

En un dispositivo arrancado:

ss -ltnup

Cada puerto abierto es superficie de ataque. Los sospechosos habituales en productos embebidos: un servidor web de configuración sin TLS, SSH con contraseña, telnet por “compatibilidad”, un servicio de depuración que se quedó activo.

4. Busca credenciales y claves en la imagen

grep -rE "BEGIN (RSA|EC|OPENSSH) PRIVATE KEY" rootfs/
cat rootfs/etc/shadow

Una clave privada dentro de la imagen es la misma clave en todos los dispositivos que has vendido. Una contraseña de root en /etc/shadow es una contraseña por defecto, aunque sea larga.

5. Comprueba si el arranque está verificado

¿El bootloader verifica la firma del kernel? ¿El kernel verifica el rootfs? En i.MX, eso es HAB y, en los modelos recientes, AHAB; en STM32MP, es el secure boot de la cadena TF-A. Si la respuesta es “no lo sé”, la respuesta es no. Y sin arranque verificado, ninguna actualización es segura de verdad, porque cualquiera con acceso físico puede sustituir la imagen.

Qué hacer con lo que encuentres

Estas cinco comprobaciones te dan una foto honesta en una tarde. Lo que no te dan es prioridad ni plan: cuáles de las 137 CVEs importan en tu dispositivo, qué hueco frente al reglamento cuesta más cerrar, y en qué orden conviene hacerlo para llegar a diciembre de 2027 sin rehacer el producto.

Eso es exactamente lo que hace nuestro Quick Scan: nos envías la imagen, y en 48 horas laborables tienes el SBOM, las vulnerabilidades con su explotabilidad en tu dispositivo concreto, los hallazgos de configuración y una página con lo que falta frente al CRA. Por 1.900 euros, con el importe descontado si después contratas la auditoría completa.

Si prefieres hablarlo antes, reserva 30 minutos. Sin compromiso y sin presentación de ventas.