Tu SBOM enumera bibliotecas y paquetes de software, pero ¿qué ocurre con el firmware grabado en tu chip Bluetooth o con el microcontrolador en el corazón de tu dispositivo? Una lista de materiales de hardware (HBOM, por sus siglas en inglés) amplía el inventario de componentes para cubrir los chips físicos, los módulos y el firmware que ejecutan. El CRA define «producto con elementos digitales» en el artículo 3(1) de forma que incluye los productos de hardware, y define «hardware» en el artículo 3(5) como un sistema electrónico de información físico o partes del mismo capaces de procesar, almacenar o transmitir datos digitales. El reglamento no utiliza en ningún momento el término «HBOM», pero la obligación de documentar y ejercer la diligencia debida sobre todos los componentes, incluido el hardware, se deriva directamente del artículo 3(1), el artículo 13(5) y el anexo I, parte II, punto 1.
Resumen
- Un HBOM es un inventario estructurado de los componentes físicos de tu producto, incluido el firmware que lleva cada componente
- El CRA no exige un HBOM con ese nombre, pero el artículo 3(1) extiende el ámbito del CRA a los productos de hardware, el artículo 13(5) exige la diligencia debida sobre todos los componentes de terceros, y el anexo I, parte II, punto 1, exige documentar los «componentes contenidos en los productos con elementos digitales»
- El firmware es software según el artículo 3(4): «consiste en código informático» y debe aparecer en tu SBOM junto a las entradas de componentes de hardware
- CycloneDX es el formato unificado práctico:
type: devicecubre el hardware físico,type: firmwarecubre el software embebido, y ambos pueden coexistir en un único documento CycloneDX 1.6 - BSI TR-03183 no cubre actualmente el HBOM como concepto; sus tres partes se centran en listas de materiales de software e informes de vulnerabilidades
- La Comisión puede especificar el formato y los elementos del SBOM mediante actos de ejecución (artículo 13(24)), pero en el texto del CRA no existe ningún mandato paralelo para un formato HBOM separado
Por qué el HBOM importa bajo el CRA
El ámbito del CRA va más allá de los «productos de software». El artículo 3(1) define «producto con elementos digitales» como:
«producto con elementos digitales»: producto consistente en programas informáticos o equipos informáticos y sus soluciones de procesamiento de datos remoto, incluidos los componentes consistentes en programas informáticos o equipos informáticos que se introduzcan en el mercado por separado
El artículo 3(5) define «hardware» como:
«equipo informático»: sistema electrónico de información físico, o partes de este, capaz de tratar, almacenar o transmitir datos digitales
Esa definición abarca el procesador de tu PCB, el módulo inalámbrico de tu placa de desarrollo y el elemento seguro de tu pasarela IoT. No son aspectos secundarios del cumplimiento del CRA, sino que están dentro de su ámbito.
El artículo 13(5) impone entonces una obligación concreta sobre ti como fabricante:
A efectos del cumplimiento de lo dispuesto en el apartado 1, los fabricantes ejercerán la diligencia debida al integrar componentes procedentes de terceros de modo que estos componentes no comprometan la seguridad del producto con elementos digitales, también cuando se integren componentes de programas informáticos libres y de código abierto que no se hayan comercializado en el transcurso de una actividad comercial.
No puedes ejercer la diligencia debida sobre componentes de hardware que no has inventariado. El anexo I, parte II, punto 1, amplía esto aún más: el SBOM debe cubrir las «vulnerabilidades y componentes contenidos en los productos con elementos digitales». Un producto que contiene un módulo ESP32 contiene la pila de firmware de ese módulo como componente. El HBOM es la herramienta práctica para capturar ese inventario.
El CRA no contiene ninguna disposición que exija un documento llamado HBOM. La obligación es inventariar todos los componentes, incluidos los componentes de hardware, dentro de la obligación de SBOM ya existente conforme al anexo I, parte II, punto 1. El HBOM es un enfoque práctico para cumplir esa obligación en productos con gran complejidad de hardware, no un documento de cumplimiento separado.
HBOM frente a SBOM: comparativa rápida
| Dimensión | SBOM | HBOM |
|---|---|---|
| Ámbito principal | Bibliotecas de software, paquetes, marcos | Componentes físicos: chips, módulos, elementos seguros |
| Cobertura de firmware | Puede incluir entradas type: firmware |
Firmware listado junto al componente de hardware principal |
| Mandato CRA | Explícito, anexo I, parte II, punto 1 | Implícito, a través del ámbito del artículo 3(1) y la diligencia debida del artículo 13(5) |
| Cobertura BSI TR-03183 | Sí, TR-03183-2 (v2.1.0, 2025) | No, ninguna de las tres partes de TR-03183 cubre el HBOM |
| Soporte CycloneDX | Todas las versiones | type: device desde v1.1; type: firmware desde v1.2 (mayo 2020) |
| Herramienta de generación típica | Syft, Trivy, cdxgen | Manual o mediante hojas de datos del proveedor de hardware; aún no hay herramientas maduras de generación automática |
| Lugar en el expediente técnico | Anexo VII, punto 2(b) y punto 8 | Misma ubicación, como parte del inventario unificado de componentes |
Para conocer la obligación completa del SBOM, consulta Requisitos de SBOM bajo el CRA. Para la comparativa de formatos, consulta CycloneDX vs SPDX.
Qué incluir en un HBOM
Las categorías siguientes reflejan criterios prácticos de ingeniería, no una lista normativa. El CRA no enumera categorías de componentes de hardware. Debes incluir cualquier componente físico que procese, almacene o transmita datos digitales, porque eso es lo que cubre el artículo 3(5).
Componentes de procesamiento y conectividad
Son las entradas de mayor prioridad porque su firmware es el vector más probable de vulnerabilidades:
- Procesador principal de aplicación o SoC (nombre, fabricante, versión o stepping, versión de firmware)
- Módulos inalámbricos: Wi-Fi, Bluetooth, Zigbee, LoRa, celular (cada uno con su versión de firmware)
- Microcontroladores secundarios que gestionan subsistemas específicos
Componentes de seguridad
El hardware de seguridad merece sus propias entradas porque las vulnerabilidades aquí tienen el mayor impacto:
- Chips de módulo de plataforma de confianza (TPM)
- Elementos seguros y módulos de seguridad de hardware
- Aceleradores criptográficos
- Cualquier componente que almacene claves, certificados o credenciales en reposo
Componentes de almacenamiento
El almacenamiento importa cuando contiene código, configuración o datos sensibles:
- Memoria flash que contiene el cargador de arranque o el firmware
- Módulos eMMC o SD si se usan para almacenamiento persistente
- EEPROM que almacena la configuración del dispositivo
Para cada entrada, registra como mínimo: nombre del componente, fabricante, versión de hardware o stepping, y versión de firmware cuando corresponda. Vincula cada entrada de hardware a su entrada de firmware correspondiente mediante relaciones de dependencia de CycloneDX.
Una parte significativa de las vulnerabilidades IoT implica firmware que nunca se actualiza tras el envío. Documentar las versiones de firmware en tu HBOM es el requisito previo para la monitorización y la remediación. No puedes rastrear lo que no has listado. Consulta los errores más comunes en el SBOM para ver el patrón más amplio.
Cómo encaja el firmware en la definición de software del CRA
El firmware se trata a veces como una categoría especial, distinta del hardware y del software. El CRA no crea esa tercera categoría. El artículo 3(4) define software como:
«programa informático»: la parte de un sistema electrónico de información consistente en un código informático
El firmware consiste en código informático. Por tanto, bajo el CRA, el firmware es software. No es una interpretación que vaya más allá del texto; se deriva directamente de la definición.
La palabra «firmware» no aparece en ningún lugar del reglamento CRA. Esto es intencionado: la definición del artículo 3(4) es suficientemente amplia para incluirlo, por lo que no se necesita ninguna clasificación separada.
La implicación práctica es clara. El firmware que se ejecuta en un chip de tu producto es un componente de software de tu producto con elementos digitales. Debe aparecer en tu inventario de componentes. Si contiene una vulnerabilidad, esa vulnerabilidad está sujeta a las mismas obligaciones de notificación del artículo 14 que cualquier vulnerabilidad de software.
CycloneDX como formato unificado de SBOM y HBOM
CycloneDX gestiona tanto los componentes de hardware como los de software en un único documento. No necesitas un formato de archivo separado para tu HBOM.
Historial de tipos de componente (relevante para hardware)
| Versión CycloneDX | Fecha de lanzamiento | Adición relevante |
|---|---|---|
| 1.1 o anterior | 2018 | Introducido type: device |
| 1.2 | 2020-05-26 | Añadido type: firmware |
| 1.5 | 2023-06-26 | Añadido type: device-driver |
| 1.6 | 2024 | Recomendación actual de conformidad con el CRA |
| 1.7 | October 2025 | Última versión estable |
Ten en cuenta que no existe type: hardware en ninguna versión de CycloneDX. El tipo correcto para un chip físico o módulo es type: device.
La especificación CycloneDX v1.2 orienta sobre cómo modelar hardware con firmware:
"A hardware device such as a processor, or chip-set. A hardware device containing firmware SHOULD include a component for the physical hardware itself, and another component of type 'firmware' or 'operating-system' (whichever is relevant), describing information about the software running on the device."
Esta guía se corresponde directamente con el tratamiento del CRA: el dispositivo físico y su firmware son componentes relacionados pero distintos, cada uno con su propia identidad y versión.
Usa CycloneDX 1.6 para los nuevos trabajos de HBOM. BSI TR-03183-2 v2.1.0 (2025-08-20) elevó su requisito mínimo de CycloneDX a 1.6. Alinearte con 1.6 mantiene tu SBOM y tu HBOM en el mismo documento y cumple con TR-03183.
Ejemplo: dispositivo ESP32 con pila de firmware
El ejemplo siguiente muestra un componente de hardware real (ESP32-WROOM-32E), su firmware (ESP-IDF) y una biblioteca dentro del firmware (mbedtls), todo en un único documento CycloneDX 1.6 con relaciones de dependencia:
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"components": [
{
"type": "device",
"name": "ESP32-WROOM-32E",
"version": "Rev 3",
"manufacturer": { "name": "Espressif Systems" },
"description": "WiFi+BT SoC Module",
"properties": [
{ "name": "firmware-version", "value": "4.4.1" },
{ "name": "secure-boot", "value": "supported" }
]
},
{
"type": "firmware",
"name": "ESP-IDF",
"version": "4.4.1",
"description": "Firmware on ESP32"
},
{
"type": "library",
"name": "mbedtls",
"version": "2.28.0",
"description": "TLS library in firmware"
}
],
"dependencies": [
{ "ref": "ESP32-WROOM-32E", "dependsOn": ["ESP-IDF"] },
{ "ref": "ESP-IDF", "dependsOn": ["mbedtls"] }
]
}
El array dependencies hace explícita la relación entre hardware y firmware. Cuando mbedtls publica un parche para un CVE, puedes rastrear qué dispositivo se ve afectado y qué versión de firmware hay que actualizar.
Para la comparativa de formatos y la elección de herramientas, consulta CycloneDX vs SPDX.
Preguntas frecuentes
¿El CRA exige explícitamente un HBOM?
No, el CRA no utiliza el término «HBOM» en ningún lugar. La obligación de documentar los componentes de hardware se deriva de forma indirecta: el artículo 3(1) incluye los productos de hardware en el ámbito del CRA, el artículo 13(5) exige la diligencia debida sobre todos los componentes de terceros, y el anexo I, parte II, punto 1, exige documentar los «componentes contenidos en los productos con elementos digitales». El HBOM es el enfoque práctico para cumplir estas obligaciones en productos de hardware, no un requisito regulatorio con nombre propio.
¿El firmware de un chip Bluetooth se considera software bajo el CRA?
Sí. El artículo 3(4) define software como «la parte de un sistema electrónico de información que consiste en código informático». El firmware consiste en código informático, por lo que cae dentro de esa definición. La palabra «firmware» no aparece en el CRA; no es necesario que aparezca, porque la definición del artículo 3(4) ya lo cubre. Cualquier firmware que se ejecute en un componente de tu producto es un componente de software de tu producto con elementos digitales y debe aparecer en tu inventario de componentes.
¿Cubre BSI TR-03183 el HBOM?
No. BSI TR-03183 consta de tres partes: parte 1 (requisitos generales), parte 2 (SBOM) y parte 3 (informes de vulnerabilidades). Ninguna de ellas cubre el HBOM como concepto estructural. TR-03183-2 menciona el firmware únicamente como tipo de archivo de componente dentro de una lista de materiales de software, usando el campo software_additionalPurpose: firmware. Si necesitas documentar componentes de hardware para el cumplimiento del CRA, debes usar el criterio de ingeniería y los tipos de hardware nativos de CycloneDX, en lugar de confiar en la guía de TR-03183 para esa parte de tu inventario.
¿Qué versión de CycloneDX admite componentes de software y hardware?
type: device está en CycloneDX desde la v1.1 (2018 o anterior). type: firmware se añadió en la v1.2, lanzada en mayo de 2020. Ambos están por tanto disponibles en cualquier versión reciente de CycloneDX. Para trabajos con el CRA, usa la v1.6 o posterior: BSI TR-03183-2 v2.1.0 (agosto de 2025) elevó su requisito mínimo de CycloneDX a 1.6, y la última versión estable es la 1.7 (octubre de 2025). No existe type: hardware en ninguna versión de CycloneDX; usa type: device para los componentes físicos.