Saltar al contenido
folhas.io
secure by design para productos conectados· Artículos

Artículos

SBOM para firmware embebido: lo que pide el CRA y cómo se genera sin mentir

La lista de materiales de software que exige el CRA no se escribe a mano. Para firmware, la única SBOM creíble sale del sistema de build, y el escaneo de binarios sirve para lo que no construimos nosotros.

Publicado

El Cyber Resilience Act exige, en el Anexo I, Parte II, que el fabricante identifique y documente los componentes del producto, incluso mediante una SBOM en formato legible por máquina que cubra, como mínimo, las dependencias de primer nivel. La SBOM no tiene que ser pública: forma parte de la documentación técnica y se entrega a las autoridades de vigilancia del mercado cuando la solicitan.

Para una aplicación web, esto es trabajo de una tarde. Para firmware, es donde la mayoría de los fabricantes va a fallar, y a fallar de una forma específica: entregando una SBOM que parece completa y no lo es.

El problema del firmware

Una imagen de firmware embebido normalmente no lleva gestor de paquetes a bordo. No hay base de datos dpkg ni apk que un escáner pueda consultar. Cuando se apunta una herramienta de análisis de composición a un rootfs extraído, la cobertura depende de lo que sobrevivió a la compilación: firmas de binarios, banners de versión, strings. El resultado son lagunas grandes y silenciosas, porque la herramienta no sabe lo que no encontró.

La consecuencia práctica: una SBOM generada por escaneo de binario sobre firmware es un punto de partida, y no basta como documento de conformidad.

La regla que resuelve casi todo

La SBOM creíble sale del sistema de build, no del binario. El sistema de build es el único sitio que sabe exactamente qué entró en la imagen, con qué versión, con qué parches y con qué licencia.

Los tres ecosistemas dominantes ya lo hacen de forma nativa:

  • Yocto: la clase create-spdx está incluida por defecto vía INHERIT_DISTRO desde Kirkstone (4.0). Un build normal de la imagen produce un .spdx.json en el directorio de deploy, derivado de los mismos inputs que produjeron el binario. Para quien prefiera CycloneDX, la meta-layer meta-cyclonedx produce SBOM CycloneDX 1.6/1.7 con CPE y purl corregidos para una mejor correspondencia con el NVD.
  • Buildroot: make legal-info genera el manifiesto completo de paquetes, versiones y licencias; el conversor cyclonedx-buildroot lo transforma en CycloneDX JSON.
  • Zephyr: west spdx genera documentos SPDX 2.3 para la aplicación, el Zephyr, el build y las dependencias de módulos. Atención a la limitación documentada: los blobs binarios de proveedores y las bibliotecas fuera del árbol no entran; hay que añadirlos como componentes externos o documentarlos como lagunas.

¿Y lo que no construimos nosotros?

Aquí es donde el análisis de binarios tiene su lugar legítimo: el bootloader entregado por el proveedor del SoC, el blob de radio, la biblioteca precompilada de un socio. Para esos, una herramienta de composición binaria produce un documento que después se reconcilia con el manifiesto del build. El método son dos inventarios, uno de lo que controlamos y otro de lo que heredamos, fundidos en un solo documento, con las lagunas identificadas como tales.

Diagrama: el sistema de build genera la SBOM de lo que construimos; el escaneo de binario inventaría los componentes heredados; los dos se reconcilian en un único documento final, con las lagunas declaradas.
Dos inventarios, un documento: el build responde por lo que construimos, el escaneo por lo que heredamos.

Qué formato

Los dos formatos aceptados en la práctica son SPDX (norma ISO/IEC 5962) y CycloneDX (ECMA-424). La orientación técnica alemana BSI TR-03183-2, el documento más citado por auditores y organismos notificados en el contexto del CRA, recomienda CycloneDX 1.6+ o SPDX 3.0.1+. CycloneDX tiene un tipo de componente nativo firmware y soporte VEX integrado, lo que lo convierte en la elección natural para el flujo CRA; Yocto produce SPDX de forma nativa. La respuesta pragmática para quien usa Yocto: generar ambos.

Como referencia de contenido mínimo, los “minimum elements” norteamericanos (actualizados por la CISA en julio de 2026, en sustitución de la versión NTIA de 2021) siguen siendo el listón práctico: proveedor, nombre, versión, identificador único (purl y/o CPE), relación de dependencia, autor y fecha de la SBOM. El campo que más vale es la versión: la correspondencia con vulnerabilidades es precisa hasta el número. “Usamos OpenSSL” no dice nada; “OpenSSL 3.0.11” dice exactamente qué advisories se aplican.

Qué significa esto para quien fabrica

Tres decisiones que tomamos en nuestro propio producto, y que recomendamos a cualquier equipo:

  1. La SBOM es un artefacto del pipeline. Se genera en cada build con tag, se guarda junto al binario, y ningún humano la escribe ni la corrige a mano. Si el proceso exige edición manual, el proceso está mal.
  2. La SBOM solo es útil conectada a monitorización. Un inventario parado es conformidad de papel; conectado a una herramienta de seguimiento de CVE (por ejemplo Dependency-Track), se convierte en el sistema de alerta que alimenta la obligación de gestión de vulnerabilidades del propio CRA, y el detonante del proceso de notificación de 24h/72h.
  3. Las lagunas se declaran. Un blob que no conseguimos descomponer es una línea en la SBOM con esa indicación, no una omisión. Ante una autoridad de vigilancia del mercado, una laguna documentada es un estado; una omisión descubierta es otro problema.

Fuentes