Seguridad del firmware
Seguridad de firmware embebido en dispositivos RTOS y bare-metal
La seguridad de firmware embebido consiste en saber qué componentes se ejecutan en un microcontrolador o en un dispositivo con RTOS y mantenerlos libres de vulnerabilidades conocidas, incluso cuando no hay un sistema operativo que inspeccionar. KROMSE cubre hoy el firmware basado en Linux; las imágenes bare-metal y RTOS y los componentes de hardware están en la hoja de ruta.
Plan gratuito, sin tarjeta.
Por qué el firmware RTOS y bare-metal es difícil de analizar
El firmware basado en Linux incluye un sistema de archivos con bases de datos de paquetes y binarios separados, así que un escáner puede desempaquetarlo y leer lo que contiene. El firmware bare-metal y RTOS suele ser un único blob enlazado estáticamente: la aplicación, el kernel del RTOS (FreeRTOS, Zephyr, ThreadX, NuttX y otros), las pilas de red como lwIP y las bibliotecas criptográficas como Mbed TLS o wolfSSL se compilan juntos, sin nombres ni archivos de versión.
Identificar componentes en una imagen así requiere firmas de código conocido o metadatos de compilación del fabricante. Sin ninguna de las dos cosas, un escáner honesto solo puede decir que no se ha podido extraer nada.
Empieza por la compilación, no por el binario
En los productos embebidos, el inventario más fiable suele salir del sistema de compilación, porque el fabricante lo tiene y un escáner que mira el binario no.
- Zephyr: el manifiesto de west (west.yml) fija los módulos y sus revisiones.
- ESP-IDF: idf_component.yml y el archivo de bloqueo de dependencias enumeran los componentes gestionados.
- PlatformIO y Arduino: platformio.ini, library.properties y los archivos de sketch nombran las bibliotecas.
- Conan y vcpkg: los lockfiles registran las versiones de los paquetes C y C++.
- Yocto y Buildroot: los manifiestos de imagen y de licencias enumeran todos los paquetes de una compilación Linux.
Qué espera el Cyber Resilience Act
El CRA no hace excepciones con los dispositivos pequeños. Un producto con microcontrolador y conexión de red es un producto con elementos digitales; su fabricante necesita un SBOM que cubra, como mínimo, las dependencias de máximo nivel, un proceso de gestión de vulnerabilidades, actualizaciones de seguridad durante el período de soporte y la notificación del artículo 14.
Varios tipos de componentes aparecen en las listas de productos importantes del Reglamento, como los microprocesadores y microcontroladores con funcionalidades relacionadas con la seguridad en la clase I, y los microprocesadores y microcontroladores resistentes a las manipulaciones en la clase II, lo que implica una evaluación de la conformidad más estricta.
Los componentes de hardware también cuentan
También se publican vulnerabilidades de hardware: procesadores, chipsets de radio, elementos seguros. Una lista de materiales de hardware permite a un fabricante comprobar cuáles de sus productos usan una pieza afectada. El requisito de SBOM del CRA se refiere al software, pero la gestión de vulnerabilidades abarca todo el producto.
Actualizaciones para dispositivos en servicio
Encontrar un componente vulnerable es solo la mitad de la obligación. El CRA exige distribuir las actualizaciones de seguridad de forma segura y sin demora durante todo el período de soporte, que debe ser de al menos cinco años salvo que se prevea un uso más corto del producto, y cada actualización debe seguir disponible durante al menos diez años o durante el resto del período de soporte.
En los productos con microcontrolador, eso significa planificar la vía de actualización desde el diseño: una cadena de arranque seguro, imágenes firmadas, memoria flash suficiente para una imagen de respaldo y una forma de llegar a dispositivos que rara vez se conectan. Incorporar todo esto después del lanzamiento suele ser imposible.
Pasos prácticos para empezar ya
Hasta que las herramientas puedan leer cualquier imagen, los propios registros del fabricante soportan la mayor parte del peso.
- Conserva los manifiestos de compilación y los lockfiles de cada versión de firmware publicada.
- Registra por producto las versiones del RTOS, de la pila de red y de la biblioteca criptográfica.
- Suscríbete a los avisos de seguridad de cada RTOS y biblioteca que distribuyes.
- Planifica cómo recibirán actualizaciones de seguridad los dispositivos en servicio durante el período de soporte.
Disponible hoy en KROMSE
Lo que KROMSE cubre hoy para productos embebidos:
- Imágenes de firmware basadas en Linux: se desempaquetan, se inventarían y se contrastan con vulnerabilidades conocidas.
- Los manifiestos de compilación embebidos se enumeran en el inventario (Zephyr west.yml, ESP-IDF, PlatformIO, Arduino, Conan, vcpkg, CMake, Yocto y Buildroot); la mayoría todavía no se contrasta con avisos de seguridad.
- Los manifiestos de Yocto y Buildroot pueden subirse como un SBOM y se contrastan con OSV.dev.
- Las imágenes bare-metal y RTOS se marcan como no analizables, nunca como limpias.
Próximamente
En la hoja de ruta, todavía no disponible. Las fechas son objetivos, no promesas; esta página cambia el mismo día en que una funcionalidad está operativa.
- Próximamente · T1 2027Firmware bare-metal y RTOS. KROMSE identificará componentes en firmware sin sistema de archivos Linux, como imágenes bare-metal y RTOS basadas en FreeRTOS o Zephyr.
- Próximamente · T1 2027Componentes de hardware. KROMSE contrastará los componentes de hardware de tu producto con los avisos de hardware publicados.
- Próximamente · T4 2026 (diciembre)Seguridad para robótica. KROMSE añadirá avisos de ROS 2, identificación de componentes dentro del firmware de PX4 y ArduPilot, y datos de vulnerabilidades específicos de robots.
Preguntas frecuentes
¿Puede KROMSE analizar firmware FreeRTOS o Zephyr?
Todavía no como imagen binaria. KROMSE enumera en su inventario los manifiestos de compilación de Zephyr y de otros entornos embebidos, pero la identificación de componentes dentro de imágenes bare-metal y RTOS está en la hoja de ruta. El análisis de una imagen así indica que no se ha podido extraer nada.
¿Se aplica el CRA a los dispositivos con microcontrolador?
Sí, si el dispositivo es un producto con elementos digitales con una conexión de datos directa o indirecta. El tamaño no importa. Los microprocesadores y microcontroladores con funcionalidades relacionadas con la seguridad figuran entre los productos importantes del anexo III.
¿Qué es una lista de materiales de hardware?
Una lista de los componentes de hardware de un producto, como procesadores, chipsets de radio y elementos seguros, con sus referencias de pieza. Permite a un fabricante averiguar rápidamente qué productos usan una pieza con una vulnerabilidad publicada.
¿El período de soporte se aplica también a los dispositivos pequeños?
Sí. Todo producto con elementos digitales necesita un período de soporte que refleje su tiempo de uso previsto y sea de al menos cinco años, salvo que se prevea un uso más corto. Durante ese período hay que proporcionar actualizaciones de seguridad, así que el mecanismo de actualización tiene que diseñarse desde el principio.
¿Cómo se crea un SBOM para firmware RTOS?
Empieza por el sistema de compilación: el manifiesto de west de Zephyr, los archivos de bloqueo de componentes de ESP-IDF, la configuración de PlatformIO o los lockfiles de Conan y vcpkg registran lo que entró en la imagen. Conviértelos a CycloneDX o SPDX y conserva uno por versión.