Cómo generar un firmware SBOM: herramientas Open Source y flujos de trabajo

Cuando una vulnerabilidad crítica como Log4Shell o Heartbleed de OpenSSL salió a la luz, cada equipo de software se apresuró a responder una sola pregunta: ¿Estamos afectados? Para los fabricantes de firmware, esa pregunta es casi imposible de responder sin un Software Bill of Materials. Un despliegue en contenedor puede consultar su gestor de paquetes en segundos. Un binario de firmware que se ejecuta en dispositivos de producción a lo largo de una planta de fabricación no puede hacerlo. Sin un firmware SBOM, no tienes inventario, y sin inventario, no puedes saber qué necesitas parchear, notificar o reemplazar.

Esta guía cubre los tres caminos prácticos para generar un firmware SBOM usando herramientas open source, los desafíos que hacen que el firmware sea más difícil que el software, y cómo operacionalizar el resultado para el cumplimiento continuo del CRA.

¿Qué es un firmware SBOM?

Un firmware SBOM es un inventario estructurado de todos los componentes de software contenidos en una imagen de firmware: paquetes del sistema operativo, bibliotecas compartidas, bootloaders, módulos del kernel, controladores y cualquier blob binario de proveedor. Se aplican los mismos elementos mínimos de NTIA que para cualquier SBOM de software: nombre del proveedor, nombre del componente, versión, identificador único, relaciones de dependencia, autor de los datos del SBOM y marca temporal, pero son sustancialmente más difíciles de completar para firmware que para una aplicación web.

CycloneDX 1.6 define firmware como un tipo de componente distinto junto al hardware del dispositivo, lo que significa que puedes modelar el producto completo, capas de hardware, firmware y software, en un único documento CycloneDX. Esto es relevante para la clasificación de productos CRA: un router clasificado como producto con elementos digitales debe tener sus componentes de firmware rastreados y monitorizados durante todo el período de soporte.

Un firmware SBOM no es un Hardware Bill of Materials (HBOM). El HBOM documenta componentes físicos: PCBs, chips, conectores. Un firmware SBOM documenta el software que se ejecuta en ese hardware.

¿Por qué generar un SBOM de firmware es más difícil que un SBOM de software estándar?

Generar un SBOM para una aplicación web significa ejecutar npm list --json o pip list. Generarlo para firmware significa reconstruir un manifiesto a partir de artefactos que nunca fueron diseñados para ser inventariados.

La idea central: la generación de firmware SBOM es ingeniería inversa bajo incertidumbre. Estás reconstruyendo un manifiesto a partir de artefactos, no generando uno desde las entradas. Esta distinción define qué herramienta y flujo de trabajo debes elegir.

Los dos enfoques fundamentales

Cada flujo de trabajo de firmware SBOM cae en una de dos categorías:

1. SBOM en tiempo de compilación. Generado durante el proceso de compilación a partir de las entradas exactas del sistema de compilación. Mayor precisión. Requiere acceso al build fuente. Funciona con Yocto y Buildroot.
2. SBOM post-compilación / analizado. Obtenido mediante ingeniería inversa a partir de una imagen de firmware binaria. Menor confianza, pero a menudo la única opción cuando recibes firmware de un ODM o estás auditando un dispositivo que no fabricaste tú.

La elección correcta depende completamente de si controlas la compilación.

Enfoque 1: SBOM en tiempo de compilación con Yocto o Buildroot

Cuándo usar: Eres propietario de la compilación del firmware. Este es el estándar de oro para la precisión.

Yocto: clase create-spdx (integrada)

La bbclass create-spdx está incluida en las versiones recientes de Yocto y se hereda por defecto a través de la configuración de distro de Poky. No se requiere herramientas adicionales. Después de una compilación normal, se generan tres archivos:

# After a normal Yocto build
ls tmp/deploy/spdx/
# IMAGE-MACHINE.spdx.json         ← main SPDX document
# IMAGE-MACHINE.spdx.index.json   ← per-recipe component index
# IMAGE-MACHINE.spdx.tar.zst      ← full archive with all component SBOMs

El SBOM generado incluye todos los componentes de software, versiones exactas, licencias, URLs de origen, parches aplicados y relaciones de dependencia. No hay incertidumbre de extracción, el SBOM se deriva de las mismas entradas que produjeron el binario.

Para realizar también análisis de CVE en tiempo de compilación:

# Add to local.conf
INHERIT += "cve-check"
CVE_CHECK_REPORT_PATCHED = "1"

Consulta la documentación de SBOM de Yocto para ver todas las opciones de configuración.

Buildroot: make legal-info + generador CycloneDX

# Step 1: Generate the component manifest
make legal-info
# Output: output/legal-info/manifest.csv

# Step 2: Convert to CycloneDX SBOM
pip install cyclonedx-buildroot
cyclonedx-buildroot output/legal-info/manifest.csv -o sbom.cdx.json

# Optional: scan for CVEs at build time
python support/scripts/cve-check --nvd-path ./nvd-data/

El conversor cyclonedx-buildroot produce una salida JSON CycloneDX a partir del manifiesto legal de Buildroot, haciéndola inmediatamente utilizable para el cumplimiento del CRA.

Limitación conocida: Los blobs binarios de terceros añadidos a la compilación (firmware Wi-Fi, blobs de GPU) solo se rastrean si los añades manualmente como paquetes de Yocto o Buildroot. Si tu sistema de compilación no sabe de un blob, el SBOM tampoco lo sabrá.

Enfoque 2: análisis de un binario existente

Cuándo usar: Recibiste firmware de un ODM u OEM, o estás auditando un dispositivo que no compilas tú mismo.

Paso 1: Extraer el firmware con binwalk

binwalk v3, la reescritura en Rust de la herramienta original, proporciona extracción más rápida y soporte de formato mejorado para imágenes de firmware modernas:

# Install binwalk v3
pip install binwalk

# Extract all embedded filesystems
binwalk -eM firmware.bin

# Check what got extracted
ls _firmware.bin.extracted/

# Check for encrypted partitions before proceeding
binwalk -E firmware.bin
# High entropy (above 0.9) regions indicate encrypted content

Paso 2a: Identificar la distribución Linux y ejecutar Syft

Si el sistema de archivos extraído contiene una distribución Linux embebida estándar (OpenWRT, basada en Debian, basada en Alpine):

# Check for package manager databases
ls _firmware.bin.extracted/squashfs-root/var/lib/dpkg/    # Debian-based
ls _firmware.bin.extracted/squashfs-root/lib/apk/db/      # Alpine/musl-based
ls _firmware.bin.extracted/squashfs-root/var/lib/opkg/    # OpenWRT/opkg

# Run Syft on the extracted filesystem
syft dir:./_firmware.bin.extracted/squashfs-root/ \
  -o cyclonedx-json=sbom.cdx.json \
  -o spdx-json=sbom.spdx.json

Syft lee bases de datos de gestores de paquetes y genera un SBOM con alta confianza para componentes empaquetados. No ve las bibliotecas C/C++ compiladas directamente en el binario sin entrada en la base de datos de paquetes. Para esas, necesitas el paso 2b.

Paso 2b: Escanear binarios en busca de bibliotecas vulnerables conocidas con cve-bin-tool

# Install Intel's cve-bin-tool
pip install cve-bin-tool

# Scan extracted binary directory
cve-bin-tool ./_firmware.bin.extracted/ \
  --output-file cve-report.json \
  -f cyclonedx

cve-bin-tool usa coincidencia de patrones de cadenas contra firmas para más de 447 bibliotecas embebidas conocidas: OpenSSL, libpng, libxml2, expat, zlib, curl y más. Cubre lo que Syft pierde: bibliotecas compiladas y despojadas en el binario sin entrada en la base de datos de paquetes.

Paso 2c: Análisis profundo de firmware con EMBA

Para un análisis integral que combina extracción, generación de SBOM y una revisión de seguridad completa en un único flujo de trabajo:

# Clone and set up EMBA
git clone https://github.com/e-m-b-a/emba.git
cd emba && sudo ./installer.sh -d

# Run EMBA with SBOM output
sudo ./emba.sh -f /path/to/firmware.bin -l /tmp/emba-log/ -p SBOM

EMBA gestiona la extracción internamente, identifica componentes mediante múltiples estrategias paralelas (coincidencia de cadenas, hashing binario, análisis del sistema de archivos, consultas a bases de datos de CVE), genera un SBOM CycloneDX con datos VEX y produce un informe completo de vulnerabilidades. Es la opción open source más completa para el análisis de firmware de caja negra y es particularmente útil para auditorías de firmware de terceros.

Referencia de herramientas: comparación rápida

SPDX vs CycloneDX: Ambos formatos son ampliamente aceptados. CycloneDX tiene un tipo de componente firmware nativo y soporte VEX integrado, lo que lo convierte en la mejor opción para el cumplimiento del CRA. SPDX es preferido en contextos de cumplimiento de licencias open source y es la salida nativa de Yocto. Para CRA, genera CycloneDX. Si usas Yocto, genera ambos.

Gestión de tu firmware SBOM a lo largo del tiempo

Un SBOM único es una instantánea. Para el cumplimiento del CRA, necesitas un SBOM operativo que evolucione con tu producto.

Compilación → SBOM (CycloneDX) → Dependency-Track → Alerta CVE → Declaración VEX → Informe ENISA (si se explota)

Cuatro pasos para hacer esto operativo:

1. Regenerar en cada compilación de firmware. Conecta la generación de SBOM de Yocto o Buildroot a tu pipeline CI/CD para que cada versión produzca automáticamente un SBOM actualizado.
2. Enviar a Dependency-Track. Dependency-Track de OWASP monitoriza tu SBOM contra feeds de CVE en vivo (NVD, OSV, GitHub Advisory) y te alerta cuando nuevas vulnerabilidades afectan componentes existentes.
3. Emitir declaraciones VEX. Cuando se encuentra una CVE en un componente, documenta si el producto está affected, not_affected, fixed o under_investigation. CycloneDX VEX es el formato; Dependency-Track gestiona el flujo de trabajo. Consulta la guía VEX para más detalles sobre el proceso.
4. Notificar a ENISA. Desde septiembre de 2026, el CRA exige notificar vulnerabilidades activamente explotadas a ENISA en 24 horas. Consulta la guía de notificación a ENISA para el flujo de trabajo exacto. Dependency-Track combinado con VEX es la base operativa que necesitas para estar preparado.

Errores comunes que debes evitar

1. Confiar solo en Syft para firmware. Syft solo ve componentes gestionados por paquetes. Cualquier biblioteca compilada directamente en el binario, sin entrada en la base de datos de paquetes, es invisible. Combina siempre Syft con cve-bin-tool o blint.

2. Ignorar las regiones de alta entropía. binwalk omite silenciosamente las particiones cifradas. Ejecuta análisis de entropía antes de la extracción (binwalk -E); documenta cualquier brecha explícitamente en el SBOM.

3. Olvidar el bootloader. U-Boot, coreboot y GRUB son componentes de firmware con CVEs reales. Están fuera del sistema de archivos del sistema operativo y la mayoría de las herramientas los pasan por alto a menos que se apunten explícitamente. Tu SBOM debe incluir el bootloader.

4. Tratar los SBOMs analizados como autoritativos. Un SBOM obtenido mediante ingeniería inversa post-compilación es una aproximación. Marca los componentes con niveles de confianza. Usa el campo evidence de CycloneDX para documentar cómo se identificó cada componente: coincidencia de cadenas, base de datos de paquetes, hash binario o entrada manual.

5. Sin plan de ciclo de vida. Un SBOM en un único momento no satisface ningún requisito de cumplimiento. Cada día se publican nuevas CVEs. Sin monitorización continua a través de Dependency-Track o equivalente, tu SBOM quedará obsoleto en semanas.

6. Brecha de blobs ODM. Si tu hardware se entrega con firmware de un ODM o proveedor de chips, no puedes analizar lo que no compilaste. Soluciona esto contractualmente: exige la entrega de SBOM a tus proveedores de firmware. Esto no es opcional bajo el CRA, eres responsable del producto completo.

Lista de verificación de cumplimiento CRA para fabricantes de firmware

Fecha límite: Las principales obligaciones del CRA se aplican desde el 11 de diciembre de 2027. La notificación de vulnerabilidades a ENISA comienza el 11 de septiembre de 2026. Necesitas un pipeline operativo de SBOM antes de septiembre de 2026, no diciembre de 2027. Consulta la línea de tiempo de implementación del CRA para el panorama completo.

□ Identificar todos los componentes de firmware en tus productos (el SBOM)
□ Elegir tu enfoque: tiempo de compilación (Yocto/Buildroot) o post-compilación (EMBA/Syft/cve-bin-tool)
□ Generar SBOM en formato JSON CycloneDX (usar también SPDX para cumplimiento de licencias open source)
□ Incluir bootloader, kernel, todos los paquetes de espacio de usuario y cualquier blob de proveedor (o documentarlos como brechas)
□ Ingerir SBOM en Dependency-Track (o equivalente) para monitorización continua
□ Establecer un flujo de trabajo VEX para documentar el estado de explotabilidad de las CVEs
□ Configurar el pipeline de notificación listo para ENISA desde septiembre de 2026
□ Exigir la entrega de SBOM a todos los proveedores de componentes de firmware (ODMs, proveedores de chips)
□ Regenerar el SBOM en cada compilación de firmware y rastrear los cambios a lo largo del tiempo
□ Documentar la metodología de generación de SBOM para propósitos de auditoría