Seguridad del firmware
Análisis de vulnerabilidades de firmware para imágenes basadas en Linux
Un escáner de vulnerabilidades de firmware desempaqueta una imagen de firmware, identifica los componentes de software que contiene y los contrasta con las vulnerabilidades conocidas. KROMSE lo hace hoy con imágenes de firmware basadas en Linux de hasta 512 MB y te dice con claridad lo que no ha podido ver.
Plan gratuito, sin tarjeta.
Por qué el firmware necesita su propio análisis
El firmware es donde se detiene el análisis del código fuente. Una imagen de dispositivo contiene el código del fabricante, pero también un kernel Linux, una biblioteca C, un busybox, una biblioteca SSL y decenas de paquetes que aportan un board support package (BSP) o un sistema de compilación como Yocto o Buildroot. Muchos de ellos no aparecen nunca en un repositorio que controle el equipo de producto.
La imagen es, además, lo que realmente ejecutan los clientes. Analizarla responde a la pregunta que importa para el Cyber Resilience Act: qué componentes, y en qué versiones, hay en el producto que se introdujo en el mercado.
Cómo funciona el análisis de firmware
Un análisis tiene tres pasos: extraer, identificar y contrastar. Cada uno puede fallar sin hacer ruido, así que un buen escáner informa de lo que no ha podido hacer con la misma claridad que de lo que ha encontrado.
- Extraer: desempaquetar la imagen de forma recursiva, atravesando sistemas de archivos como SquashFS, JFFS2, CramFS y UBI, y cabeceras propias de cada fabricante.
- Identificar: enumerar los paquetes a partir de las bases de datos de paquetes e identificar los binarios, por ejemplo por sus cadenas de versión.
- Contrastar: comprobar los componentes identificados frente a datos de vulnerabilidades como OSV.dev y fuentes basadas en NVD.
- Informar: indicar la cobertura, incluidos los archivos que no se han podido desempaquetar o identificar.
Qué puede decirte un análisis de firmware y qué no
Identificar binarios es, por naturaleza, menos seguro que leer un lockfile. Un binario puede estar parcheado sin que cambie su cadena de versión, o compilado sin la funcionalidad que hace explotable una vulnerabilidad. Por eso los hallazgos en firmware son un punto de partida para la revisión de ingeniería, no un veredicto.
Algunas imágenes no pueden analizarse en absoluto desde fuera: las cifradas o firmadas de forma opaca, y el firmware bare-metal o RTOS sin sistema de archivos. Un escáner debería decirlo en lugar de devolver un resultado vacío y tranquilizador.
El firmware y el Cyber Resilience Act
El CRA cubre los productos de hardware con elementos digitales y su software, así que el firmware de un dispositivo conectado forma parte de lo que el fabricante debe proteger, documentar y actualizar. Le afecta el requisito de SBOM del anexo I, parte II, y también la notificación del artículo 14 cuando un componente del firmware se está aprovechando activamente.
En los dispositivos que pasan años en servicio, el reto práctico es conservar el inventario de cada imagen publicada y volver a comprobarlo a medida que se publican nuevas vulnerabilidades.
Cómo preparar las imágenes para el análisis
Unos pocos hábitos hacen que los análisis de firmware sean más completos y que sea más fácil actuar sobre ellos.
- Analiza exactamente la imagen que distribuyes, no una compilación de desarrollo.
- Guarda los manifiestos de compilación de Yocto o Buildroot junto a la imagen; aportan detalle sobre los paquetes.
- Registra la versión de la imagen y el producto al que pertenece, para que los hallazgos se correspondan con versiones concretas.
- Vuelve a analizar cuando cambien los datos de vulnerabilidades, no solo cuando cambie la imagen.
Cómo leer los resultados: cobertura y confianza
Hay dos cifras que importan tanto como la lista de hallazgos: qué parte de la imagen se ha desempaquetado y cuántos componentes se han podido identificar. Un resultado con pocos hallazgos y poca cobertura dice poco; uno con muchos hallazgos procedentes de la identificación de binarios necesita revisión antes de llegar a un cliente o a una autoridad.
Registra la decisión sobre cada hallazgo relevante: afectado, no afectado y por qué, o corregido en una versión concreta. Esas decisiones son lo que comunica un documento VEX, y lo que pedirá una notificación del artículo 14 o el cuestionario de un cliente.
Disponible hoy en KROMSE
El análisis de firmware de KROMSE cubre hoy imágenes basadas en Linux.
- Sube una imagen de firmware basada en Linux de hasta 512 MB; KROMSE la desempaqueta de forma recursiva.
- Los paquetes se enumeran y se contrastan con OSV.dev, y los binarios se comparan sin conexión con datos de vulnerabilidades basados en NVD.
- El sistema de archivos raíz desempaquetado también se revisa en busca de errores de configuración y secretos incrustados, cuyos valores nunca se almacenan.
- Los archivos .px4 de PX4 se extraen de su envoltorio antes de desempaquetarlos.
- Cada análisis genera SBOM CycloneDX y SPDX e indica lo que no se ha podido desempaquetar o identificar.
- Las imágenes cifradas y el firmware bare-metal o RTOS se marcan como no analizables, no como limpios.
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
¿Qué firmware puede analizar KROMSE?
Imágenes de firmware basadas en Linux de hasta 512 MB, que KROMSE desempaqueta atravesando los sistemas de archivos embebidos habituales antes de identificar los componentes. Las imágenes cifradas y el firmware bare-metal o RTOS sin sistema de archivos todavía no son compatibles, y el resultado del análisis lo indica.
¿En qué se diferencia un análisis de firmware de uno de código fuente?
Un análisis de código fuente lee las dependencias que declara tu repositorio. Un análisis de firmware examina la imagen terminada, incluidos el sistema operativo, las bibliotecas y los paquetes que añade el sistema de compilación, que a menudo no aparecen nunca en tu repositorio. Los dos son útiles; la imagen es lo que ejecutan los clientes.
¿Son siempre exactos los hallazgos en firmware?
Ningún escáner puede prometerlo. Identificar binarios por sus cadenas de versión puede pasar por alto parches retroportados o señalar un componente que está presente pero no es explotable. Trata los hallazgos en firmware como evidencias que debe revisar un ingeniero, y registra la decisión.
¿Puede KROMSE analizar firmware de drones PX4?
En parte. KROMSE extrae los archivos .px4 de PX4 de su envoltorio y los somete al mismo desempaquetado y a las mismas comprobaciones que el resto del firmware, pero la identificación de los componentes basados en NuttX que contienen todavía no está disponible. La imagen de un ordenador de a bordo auxiliar (companion computer) basado en Linux sí puede analizarse por completo. La cobertura específica para robótica está en la hoja de ruta.
¿Se aplica el CRA al firmware?
Sí, como parte de un producto con elementos digitales. El firmware de un dispositivo conectado debe cumplir los requisitos esenciales, estar cubierto por el SBOM y la gestión de vulnerabilidades, y quedar sujeto a la notificación del artículo 14 si uno de sus componentes se está aprovechando activamente.