HBOM: lista de materiales de hardware para el CRA

Su SBOM enumera bibliotecas y paquetes de software. No le dirá si el módulo de radio de su producto ha quedado sin soporte, si el bootloader admite actualizaciones o qué lote utilizó un chipset de sustitución.

Esa es la función de una lista de materiales de hardware (HBOM). El CRA no usa el término «HBOM», pero los productos de hardware, el firmware, la diligencia debida sobre componentes de terceros y el inventario de componentes del SBOM apuntan a la misma necesidad práctica: saber qué hardware y qué firmware hay dentro del producto, y saber si puede actuar cuando aparece una vulnerabilidad.

Por qué el HBOM importa bajo el CRA

El ámbito del CRA va más allá de los productos de solo 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 debida sobre componentes no se limita a las bibliotecas de código abierto. Un procesador en su PCB, un módulo inalámbrico en su placa de desarrollo o un elemento seguro en su gateway IoT pueden llevar firmware, ajustes de seguridad y fechas de soporte. No puede gestionar esos riesgos sin inventariarlos.

La obligación del SBOM es donde suele aterrizar esta evidencia. El CRA pide a los fabricantes identificar y documentar componentes y vulnerabilidades, incluso mediante un SBOM legible por máquina que cubra al menos las dependencias de primer nivel. Un módulo ESP32, por tanto, 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 esa parte hardware del inventario.

Los períodos de soporte forman parte del mismo cuadro. El CRA le permite tener en cuenta los períodos de soporte de los componentes principales. Su documentación técnica necesita entonces la información usada para fijar el período de soporte del producto. Si un chipset o módulo alcanza el fin de soporte antes de que termine el período de soporte de su producto, el HBOM es donde ese hecho debe hacerse visible primero.

Cómo es un HBOM en una cadena de suministro real

Imagina un importador de la UE que compra un gateway conectado a un ODM de Shenzhen. El importador no necesita cada resistencia. Sí necesita los datos de fabricación que cambian el riesgo de ciberseguridad: módulo de radio, versión de firmware base, estado de soporte y sustituciones aprobadas.

La diferencia clave es el registro tal como se fabricó. Un BOM de diseño dice lo que ingeniería pretendía usar. El HBOM también debe capturar lo que la fábrica realmente envió.

HBOM frente a SBOM: comparativa rápida

Para conocer la obligación completa del SBOM, consulte Requisitos de SBOM bajo el CRA. Para la comparativa de formatos, consulte CycloneDX vs SPDX.

Qué incluir y dónde detenerse

El CRA no ofrece una lista normativa de campos para el HBOM. Tampoco le exige listar cada componente físico pasivo. Su base de inventario de componentes establece un umbral de dependencias de primer nivel para el SBOM, y el lado hardware debe seguir la misma lógica de riesgo.

Use este criterio: liste el hardware que pueda cambiar el riesgo de ciberseguridad del producto, el estado de vulnerabilidades, la ruta de actualización o la evidencia del período de soporte.

Empieza con los componentes que realizan alguna de estas funciones:

• Procesan datos: procesadores principales, SoCs, microcontroladores, FPGAs y ASICs relacionados con la seguridad.
• Almacenan código o secretos: flash, eMMC, módulos de plataforma de confianza (TPM), elementos seguros y controladores de almacenamiento.
• Transmiten datos: módulos Wi-Fi, Bluetooth, Zigbee, Thread, LoRaWAN, NFC, Ethernet, celular y GNSS.
• Arrancan o actualizan el producto: gestores de arranque, bootloaders, UEFI, BIOS, firmware del controlador de gestión de placa base (BMC) y controladores de actualización.
• Hacen cumplir la seguridad: aceleradores criptográficos, raíces de confianza hardware, almacenes de claves y enclaves seguros.
• Exponen acceso de servicio: puertos de depuración de producción, JTAG, UART, SWD o interfaces de gestión donde el estado de bloqueo de producción importa.

Los componentes pasivos como resistencias y condensadores ordinarios quedan normalmente fuera del HBOM salvo que tengan una función de seguridad, una identidad digital, firmware o un riesgo de sustitución conocido. La prueba práctica es simple: si una vulnerabilidad, un aviso, una notificación de EOL o una sustitución del proveedor para esa pieza cambiaría su decisión de riesgo del producto, inclúyala.

Categorías de hardware prioritarias

Las siguientes categorías no son una lista normativa. Son las entradas con más probabilidades de importar en la evidencia CRA porque llevan firmware, claves, interfaces o dependencias de soporte del proveedor.

Para cada entrada, registre como mínimo: nombre del componente, fabricante, versión de hardware o stepping, y versión de firmware cuando corresponda. Vincule cada entrada de hardware a su entrada de firmware correspondiente mediante relaciones de dependencia de CycloneDX.

Capas de firmware que se pasan por alto

Un único campo «versión de firmware» suele ser demasiado superficial. Muchos productos contienen varias capas de firmware con distintos propietarios, rutas de actualización y fuentes de vulnerabilidades.

Las capas que se pasan por alto con más frecuencia son:

• Firmware de arranque: ROM de arranque, bootloader, gestor de arranque y configuración de arranque seguro.
• Firmware de radio: firmware Wi-Fi, Bluetooth, banda base celular, Zigbee, Thread, LoRaWAN y NFC.
• Firmware de plataforma: UEFI, BIOS, BMC, ROMs de opción y microcódigo de CPU. NIST SP 800-193 trata el firmware de plataforma como el hardware y firmware fundamental necesario para arrancar y operar un sistema.
• Firmware de controladores: controladores de almacenamiento, tarjetas de red, controladores de alimentación, hubs de sensores y controladores embebidos.
• Firmware de seguridad: firmware de TPM, sistemas operativos de elemento seguro, applets de elemento seguro, imágenes de entorno de ejecución de confianza (TEE) y firmware de HSM.
• Lógica programable: bitstreams de FPGA y configuración de ASIC o FPGA relacionados con la seguridad.
• Blobs binarios del proveedor: blobs de firmware suministrados por el SDK que se incluyen en la imagen del producto pero son mantenidos por el proveedor del chip o módulo.

Cada capa debe ser un componente separado cuando tiene su propia versión, ruta de actualización, mantenedor o fuente de avisos. Eso es lo que le permite responder más adelante a la pregunta útil: ¿qué versiones exactas del producto están afectadas por este aviso de firmware?

Campos que hacen útil un HBOM

El umbral normativo es más estrecho que un HBOM útil. Los campos siguientes no son todos obligatorios bajo el CRA. Son la evidencia que le permite gestionar vulnerabilidades, cambios de proveedor y decisiones sobre el período de soporte sin empezar de cero.

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 tanto del hardware como 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 directa. El firmware que se ejecuta en un chip de su producto es un componente de software de su producto con elementos digitales. Debe aparecer en su 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.

Si el firmware no puede actualizarse

Algunos firmware no pueden actualizarse en el campo. La ROM de arranque puede estar programada en máscara. El código del elemento seguro puede estar controlado por el proveedor. Un módulo de radio puede no ofrecer ninguna ruta de actualización al cliente. Eso no hace que el componente desaparezca de la evidencia CRA.

El CRA espera que las vulnerabilidades sean subsanables mediante actualizaciones de seguridad cuando corresponda. Si un componente de hardware no puede recibir actualizaciones, documente ese hecho en el HBOM y en la evaluación de riesgos.

Registre:

• Estado de actualización: actualizable en el campo, solo por el proveedor, solo en fábrica o inmutable.
• Motivo: ROM, memoria de un solo uso, módulo de proveedor bloqueado, restricción de certificación o ausencia de canal de actualización expuesto.
• Controles compensatorios: aislamiento, función desactivada, restricción de red, autenticación adicional o mitigación a nivel de producto.
• Ruta de respuesta: actualización de firmware, sustitución del módulo, retirada de unidades, aviso al cliente o declaración VEX not_affected cuando la ruta vulnerable no es alcanzable.
• Alcance afectado: versión del producto, revisión de PCB, rango de lote o número de serie.

Si una vulnerabilidad explotable no puede corregirse ni mitigarse, los deberes de acción correctiva del CRA pueden obligar a medidas correctoras, retirada del mercado o recuperación. El HBOM debe darle el rango de producto afectado antes de que esa decisión se vuelva urgente.

El EOL de los componentes afecta al período de soporte

El período de soporte del producto no es solo una promesa de servicio al cliente. Es parte del modelo de gestión de vulnerabilidades del CRA.

El CRA le permite tener en cuenta los períodos de soporte de los componentes principales integrados de terceros al fijar el período de soporte del producto. Su documentación técnica necesita entonces la información utilizada para determinar ese período de soporte. La orientación del CRA sobre ejemplos de hardware de larga vida útil incluye placas base, microprocesadores, routers, módems, conmutadores y sistemas de control industrial, que suelen usarse durante más de cinco años.

Eso convierte el EOL de los componentes en un campo del HBOM, no solo en una nota de aprovisionamiento.

Para los componentes principales, registre:

• Fecha de fin de soporte del proveedor: mes y año cuando esté disponible.
• Fecha del último lanzamiento de firmware: la fecha más reciente en que el proveedor publicó una actualización de firmware relevante para la seguridad.
• Fuente de avisos: página PSIRT, feed CSAF, lista de correo o contacto del proveedor.
• Ruta de sustitución: pieza compatible por pines, plan de rediseño, decisión de última compra o decisión de EOL del producto.
• Cobertura contractual: si las obligaciones de parches y avisos del proveedor cubren su período de soporte del producto declarado.

Si un módulo principal acaba con soporte antes que su producto, debe tomar una decisión antes de la puesta en el mercado. Amplíe la cobertura del proveedor, elija una pieza diferente, limite el período de soporte del producto cuando esté justificado o documente un plan de sustitución.

CycloneDX como formato unificado de SBOM y HBOM

CycloneDX gestiona tanto los componentes de hardware como los de software en un único documento. No necesita un formato de archivo separado para su HBOM.

Historial de tipos de componente (relevante para hardware)

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 orientación sobre tipos de componente de CycloneDX trata el dispositivo físico y el software que se ejecuta en él como componentes separados. Un procesador o chipset debe representarse como device, mientras que el código que se ejecuta en él debe representarse como firmware o operating-system, según el caso.

Esta orientación 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.

Use 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. Alinearse con 1.6 o posterior mantiene su SBOM y su HBOM en el mismo documento y cumple con TR-03183.

CycloneDX también tiene propiedades oficiales cdx:device:* para detalles de hardware como función, ubicación en la placa, tipo de dispositivo, número de serie, número de lote e identificadores GS1. Use esos nombres donde corresponda. Si añade propiedades personalizadas para la actualización o el estado de seguridad, nómbrelas con un espacio de nombres claro para que los lectores no las confundan con la taxonomía oficial de CycloneDX.

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",
  "version": 1,
  "components": [
    {
      "type": "device",
      "bom-ref": "device:esp32-wroom-32e",
      "name": "ESP32-WROOM-32E",
      "version": "Rev 3",
      "manufacturer": { "name": "Espressif Systems" },
      "description": "Wi-Fi and Bluetooth SoC module",
      "externalReferences": [
        {
          "type": "documentation",
          "url": "https://www.espressif.com/sites/default/files/documentation/esp32-wroom-32e_esp32-wroom-32ue_datasheet_en.pdf"
        }
      ],
      "properties": [
        { "name": "cdx:device:function", "value": "Wi-Fi and Bluetooth connectivity" },
        { "name": "cdx:device:deviceType", "value": "SMD module" },
        { "name": "example:firmware:updateable", "value": "vendor-supported" },
        { "name": "example:security:secure-boot", "value": "supported" }
      ]
    },
    {
      "type": "firmware",
      "bom-ref": "firmware:esp-idf-4.4.1",
      "name": "ESP-IDF",
      "version": "4.4.1",
      "description": "Espressif IoT Development Framework running on ESP32"
    },
    {
      "type": "library",
      "bom-ref": "library:mbedtls-2.28.0",
      "name": "mbedtls",
      "version": "2.28.0",
      "purl": "pkg:generic/mbedtls@2.28.0",
      "description": "TLS library in firmware"
    }
  ],
  "dependencies": [
    { "ref": "device:esp32-wroom-32e", "dependsOn": ["firmware:esp-idf-4.4.1"] },
    { "ref": "firmware:esp-idf-4.4.1", "dependsOn": ["library:mbedtls-2.28.0"] }
  ]
}

El array dependencies hace explícita la relación entre hardware y firmware. Cuando mbedtls publica un parche para un CVE, puede rastrear qué dispositivo se ve afectado y qué versión de firmware hay que actualizar.

El ejemplo omite un CPE de hardware a propósito. Las cadenas CPE de la Base de Datos Nacional de Vulnerabilidades (NVD) son específicas de cada producto, y los identificadores a nivel de módulo o de chip no siempre coinciden. Añada un campo cpe solo cuando haya verificado la entrada exacta de NVD para el componente. Para la comparativa de formatos y la elección de herramientas, consulte CycloneDX vs SPDX.

La correspondencia de vulnerabilidades de hardware es diferente

Los escáneres de vulnerabilidades de software suelen hacer la correspondencia por Package URL (PURL), Common Platform Enumeration (CPE) o metadatos de paquetes. Con el hardware es más complicado.

PURL está diseñado para ecosistemas de paquetes de software como npm, Maven, PyPI, Debian y RPM. Es útil para paquetes de firmware o bibliotecas donde el software se distribuye como un paquete. No es el identificador adecuado para un chip físico.

CPE puede representar hardware mediante part=h, y CycloneDX tiene un campo cpe de primer nivel en los componentes. Úsalo cuando exista un CPE de NVD verificado. Pero no des por sentado que cada chip, módulo o imagen de firmware tiene uno.

Para entradas de hardware sin un CPE fiable, mantenga el rastro de correspondencia legible por personas:

• nombre exacto del fabricante
• número de pieza del fabricante
• revisión o stepping de hardware
• nombre y versión del firmware
• URL de aviso del proveedor o PSIRT
• contacto del proveedor
• identificador GS1 cuando esté disponible, usando la propiedad cdx:device:gs1:* correspondiente

Luego monitorice las fuentes que realmente publican avisos de hardware y firmware: la página PSIRT del proveedor, NVD, las Vulnerabilidades Explotadas Conocidas de CISA, los avisos ICS de CISA cuando corresponda, y feeds sectoriales para productos industriales, médicos o de radio. Use VEX o evidencia equivalente cuando un componente está presente pero la función vulnerable no es alcanzable en su producto. Para el flujo de notificación, consulte Notificación de vulnerabilidades e incidentes CRA.

Qué pedir a proveedores y fabricantes por contrato

La diligencia debida sobre componentes recae en el fabricante. Para el hardware, eso significa pedir datos de seguridad y ciclo de vida antes de que la pieza quede fijada en el producto.

Pida a los proveedores y fabricantes por contrato:

• Identidad exacta enviada: número de pieza del fabricante, revisión de hardware, versión de firmware y cualquier sustitución aprobada.
• Ruta de actualización: si el firmware es actualizable en el campo, solo por el proveedor, solo en fábrica o inmutable.
• Seguridad de la actualización: detalles de firma, autenticación, antirrollback y distribución segura.
• Fechas de soporte: EOL del componente, fecha de última compra, último lanzamiento de firmware y fecha de fin de soporte.
• Canal de avisos: página PSIRT, lista de correo de seguridad, feed CSAF, portal de soporte o contacto nominado.
• Estado de vulnerabilidades conocidas: avisos actuales, versiones de firmware corregidas y cualquier declaración VEX o CSAF.
• Trazabilidad de producción: BOM tal como se fabricó por tirada de producción, rango de lote o número de serie donde puedan producirse sustituciones.
• Ruta de la cadena de suministro: distribuidor autorizado o fuente del fabricante original del componente donde el riesgo de falsificación o mercado gris sea relevante.

Un BOM de diseño no es suficiente cuando un fabricante de diseño original (ODM) o un fabricante por contrato puede sustituir módulos durante la producción. Necesitas el registro de componentes tal como se fabricaron para las unidades que pones en el mercado de la UE.