Lista de materiales hardware (HBOM) y cumplimiento CRA

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 chips físicos, módulos y el firmware que ejecutan. El CRA no usa el término «HBOM», pero los productos de hardware, los componentes de hardware comercializados por separado, la diligencia sobre componentes de terceros y el inventario de componentes del SBOM llevan a la misma necesidad práctica: saber qué hardware y qué firmware hay dentro del producto.

Por qué el HBOM importa bajo el CRA

El ámbito del CRA va más allá de los productos solo de software. Los productos de hardware, los componentes de hardware comercializados por separado y el firmware dentro de esos componentes forman parte del problema de inventario del producto.

Esto importa a los fabricantes porque la diligencia sobre componentes no se limita a bibliotecas de código abierto. Un procesador en tu PCB, un módulo inalámbrico en tu placa de desarrollo o un elemento seguro en tu gateway IoT pueden llevar firmware y versiones relevantes para la seguridad. No puedes gestionar esos riesgos sin inventariarlos.

La obligación de SBOM es el lugar jurídico de este trabajo: pide los componentes contenidos en productos con elementos digitales. Por tanto, un módulo ESP32 incorpora al registro de componentes tanto el módulo físico como su pila de firmware. El HBOM es la herramienta práctica para capturar ese inventario.

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
Rol de cumplimiento	Requisito explícito de inventario de componentes	Extensión práctica de ese mismo inventario para productos de hardware
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	Expediente técnico, sección de inventario de componentes	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. Incluye cualquier componente físico que procese, almacene o transmita datos digitales porque esos componentes pueden afectar a la ciberseguridad.

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.

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. Para el trabajo CRA, trata el firmware como software porque es código informático que se ejecuta dentro de un sistema electrónico de información.

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 sigue el mismo flujo de gestión y notificación que cualquier otra 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	Base recomendada para 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 o posterior 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 o posterior 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 o posterior 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.