Su cliente quiere una SBOM: guía para proveedores de componentes y software

Esta guía es para proveedores de una cadena de suministro industrial: ECU, pantallas, controladores, pasarelas, variadores, pilas de Linux embebido y módulos de firmware. Si vende software y un cliente le ha enviado una solicitud puntual, empiece por cómo responder a una solicitud de SBOM de un cliente, que cubre ese caso.

Por qué los OEM lo piden ahora

La solicitud de SBOM de un OEM suele ser la normativa del propio OEM que llega a su puerta a través de un contrato. De qué normativa se trate determina qué debe tener el OEM y cuánto de ello se le traslada a usted.

El Reglamento de Ciberresiliencia

Según el Reglamento (UE) 2024/2847 de Ciberresiliencia (Cyber Resilience Act), un producto con elementos digitales incluye «los componentes consistentes en programas informáticos o equipos informáticos que se introduzcan en el mercado por separado» (artículo 3, punto 1). Un componente que vende por sí solo en la UE es un producto en sí mismo, y usted es su fabricante, con su propia obligación de SBOM: el anexo I, parte II, punto 1, pide una nomenclatura de materiales de los programas informáticos «en un formato comúnmente utilizado y legible por máquina, que incluya, como mínimo, las dependencias de máximo nivel del producto». Si el componente está destinado a integrarse en otros productos, sus instrucciones también deben dar «la información necesaria para que el integrador cumpla» los requisitos esenciales (anexo II, punto 8, letra f)).

El OEM también tiene obligaciones que le alcanzan a usted. Los fabricantes «ejercerán la diligencia debida al integrar componentes procedentes de terceros» (artículo 13, apartado 5), y cuando el OEM detecta una vulnerabilidad en un componente que ha integrado, debe notificarla a la persona o entidad que fabrica o mantiene el componente (artículo 13, apartado 6). La guía de la Comisión sobre el CRA de julio de 2026 indica que la evidencia de diligencia debida puede consistir en documentación obtenida del fabricante del componente, y no menciona las SBOM; en la práctica, una SBOM suele ser la documentación que piden los OEM. Las obligaciones de notificación se aplican desde el 11 de septiembre de 2026 y el reglamento se aplica en su totalidad desde el 11 de diciembre de 2027. Las piezas de recambio fabricadas con las mismas especificaciones que los componentes a los que sustituyen están excluidas (artículo 2, apartado 6). Para el resto del reglamento, consulte qué es el CRA y la guía del CRA.

Vehículos

El CRA no se aplica a los productos regulados por el Reglamento (UE) 2019/2144, el reglamento de homologación de tipo de vehículos (artículo 2, apartado 2, letra c)). Los componentes de vehículos homologados llegan al mercado según las normas de vehículos, y esas normas nunca mencionan una SBOM.

• El Reglamento n.º 155 de las Naciones Unidas (ciberseguridad) exige al fabricante recopilar y verificar información a lo largo de la cadena de suministro para demostrar que los riesgos relacionados con los proveedores se identifican y se gestionan (5.1.1(a)), mostrar cómo su sistema de gestión de la ciberseguridad gestionará las dependencias que puedan existir con proveedores contratados, prestadores de servicios o suborganizaciones del fabricante (7.2.2.5) e identificar y gestionar, para el tipo de vehículo que se homologa, los riesgos relacionados con los proveedores (7.3.2).
• El Reglamento n.º 156 de las Naciones Unidas (actualizaciones de software) exige que todas las versiones de software iniciales y actualizadas sean identificables de forma única (7.1.1.2) y, para cada número de identificación de software RX (RXSWIN), un registro auditable que describa todo el software pertinente para el RXSWIN (7.1.2.3).
• ISO/SAE 21434 organiza el trabajo de ciberseguridad entre OEM y proveedor como actividades distribuidas, con el reparto acordado en un cybersecurity interface agreement (acuerdo de interfaz de ciberseguridad).
• El SBOM Informational Report de Auto-ISAC (febrero de 2025) recoge las recomendaciones del propio sector.

En automoción, la SBOM llega como requisito contractual, no legal.

Automatización industrial

IEC 62443-4-1 se aplica a los proveedores de productos para sistemas de automatización y control industrial. No menciona las SBOM, pero la práctica 6, gestión de problemas relacionados con la seguridad (DM-1 a DM-6), y la práctica 7, gestión de actualizaciones de seguridad (SUM-1 a SUM-5, incluido SUM-3, «Dependent component or operating system security update documentation»), son donde una SBOM sirve de evidencia.

Máquinas

El Reglamento (UE) 2023/1230 relativo a las máquinas se aplica desde el 20 de enero de 2027 y no menciona las SBOM. Sus requisitos esenciales de protección contra la corrupción (anexo III, 1.1.9) piden que el software esencial para la conformidad se indique y se proteja, que «la máquina o el producto relacionado indicarán el software que tengan instalado y que les resulte necesario para funcionar con seguridad», y que se recojan pruebas de las intervenciones en ese software. Las máquinas con elementos digitales también entran en el CRA, a diferencia de los vehículos homologados, y por eso los fabricantes de máquinas ya piden SBOM a sus proveedores. Consulte CRACI para fabricantes de máquinas e IoT industrial.

NIS2 y clientes certificados

Si suministra a entidades esenciales o importantes, por ejemplo en semiconductores, el artículo 21, apartado 2, letra d), de NIS2 exige a su cliente abordar la seguridad de la cadena de suministro. No menciona las SBOM. Los clientes lo convierten en cuestionarios, y los controles 5.21 y 8.8 del anexo A de ISO/IEC 27001 son donde una SBOM sirve de evidencia. Consulte las SBOM como evidencia de ISO 27001, SOC 2 y NIS2.

Los regímenes, uno al lado del otro

Régimen	Se aplica a	¿Menciona una SBOM?	Lo que llega al proveedor
Reglamento de Ciberresiliencia (CRA)	Productos con elementos digitales en el mercado de la UE, incluidos los componentes vendidos por separado	Sí, anexo I, parte II (1)	Directamente si usted introduce el componente en el mercado; a través de la diligencia debida del OEM (art. 13(5)) y de las notificaciones de vulnerabilidades (art. 13(6))
UN R155 y R156	Fabricantes de vehículos que solicitan la homologación de tipo	No	Gestión de riesgos de proveedores (R155 7.2.2.5, 7.3.2) e identificación de software (R156), a través de contratos
ISO/SAE 21434	Ingeniería de ciberseguridad de vehículos de carretera, OEM y proveedores	No en su descripción pública	Actividades distribuidas y un acuerdo de interfaz de ciberseguridad
IEC 62443-4-1	Proveedores de productos para sistemas de automatización y control industrial	No	Directamente si es usted el proveedor del producto; las SBOM sirven de evidencia para DM y SUM
Reglamento (UE) 2023/1230 relativo a las máquinas	Máquinas y productos relacionados en el mercado de la UE	No	Identificación y protección del software (anexo III 1.1.9); el CRA se aplica junto a él
NIS2	Entidades esenciales e importantes	No	Cuestionarios de seguridad de la cadena de suministro y cláusulas contractuales (art. 21(2)(d), 21(3))

Sea cual sea la vía, el cliente necesita lo mismo: una SBOM exacta de cada versión de software que usted entrega.

Qué suelen pedir los OEM

Los requisitos varían de un OEM a otro, pero convergen en la misma lista. Compruebe su SBOM con ella antes de la primera entrega.

Requisito	Expectativa habitual
Formato	CycloneDX o SPDX, JSON o XML, con una versión mínima de la especificación. BSI TR-03183-2 fija CycloneDX 1.6 o posterior, o SPDX 3.0.1 o posterior.
Campos	Alineados con los CISA 2026 Minimum Elements o con BSI TR-03183-2: autor, marca de tiempo y, por componente, nombre, versión, productor e identificadores
Identificadores	Una package URL siempre que el ecosistema la tenga, y un CPE cuando no, para que los componentes puedan cruzarse con las bases de datos de vulnerabilidades
Licencias	Identificadores de licencia SPDX. El especialista en licencias del OEM los lee para evaluar el copyleft y otros riesgos de licencia.
Hashes	Un hash de cada binario entregado, para que el OEM pueda confirmar que la SBOM describe el archivo que recibió. El BSI pide SHA-512.
Profundidad	Dependencias transitivas, no solo el primer nivel
Granularidad	Una SBOM por versión de software o referencia entregada
Entrega y respuesta	Un canal de entrega y plazos de respuesta para las preguntas sobre vulnerabilidades

Muchos OEM comprueban estos puntos automáticamente al recibir el archivo. Consulte la lista de comprobación de calidad de SBOM para ver qué comprobará su cliente y qué herramientas usa, y los ejemplos de SBOM para ver cómo son los campos en un archivo.

Su SBOM cuando hay poco o nada de código abierto

Una ECU o un controlador bare-metal con firmware propietario generado a partir de modelos tiene una SBOM honesta que puede ser corta: la aplicación propietaria, su bootloader, las bibliotecas o la calibración de un fabricante de semiconductores y cualquier componente de código abierto, como una biblioteca criptográfica. Es una respuesta válida. Las reglas:

• Incluya los componentes propietarios con sus propios identificadores: nombre, versión y usted como productor.
• Declare las incógnitas conocidas, como una biblioteca de un fabricante cuyo contenido no puede ver.
• Nunca infle la SBOM para que parezca exhaustiva, y nunca omita una biblioteca de código abierto porque sea pequeña.

En las pantallas y pasarelas basadas en Linux ocurre lo contrario: cientos o miles de componentes, incluidos el kernel, el bootloader y los paquetes del sistema base (consulte dispositivos conectados). Una SBOM que solo incluye su aplicación y unas pocas bibliotecas es lo primero que señala un equipo receptor. Si compila con Yocto, consulte por qué los escáneres no ven lo que hay en los builds de Yocto.

Contratos: qué acordar antes de la primera entrega

Cláusula	Por qué importa
Productos y versiones de software cubiertos	Para que nadie discuta después si una variante o una versión de mantenimiento necesitaba SBOM
Formato y versión de la especificación	Su pipeline de recepción puede rechazar cualquier otra cosa
Campos y el marco que siguen	«BSI TR-03183-2 v2.1.0» o «CISA 2026 Minimum Elements» se puede comprobar; «una SBOM completa», no
Desencadenante de la entrega	Cada versión, cada versión de software enviada al OEM y cada corrección
Canal de entrega	El portal de proveedores del OEM, un intercambio seguro de archivos o correo electrónico bajo NDA
Confidencialidad	Un NDA o el acuerdo de suministro existente, que califique la SBOM como información confidencial
Restricciones de uso	Solo gestión de vulnerabilidades y cumplimiento, sin cesión a terceros sin consentimiento
Notificación de vulnerabilidades, en ambos sentidos	El OEM notifica las vulnerabilidades que encuentra en su componente (CRA art. 13(6)); usted le notifica las suyas
Expectativas sobre VEX	Qué formato, y en cuánto tiempo evalúa una CVE nueva
Conservación	Cuánto tiempo conserva la SBOM de cada versión, en línea con el periodo de soporte del producto
Exactitud e incógnitas conocidas	Una cláusula honesta sobre lo que la SBOM puede y no puede cubrir protege a ambas partes

El SBOM Sharing Primer de la CISA describe el caso de la automoción del mismo modo: las solicitudes de SBOM se incluirían en los acuerdos habituales de intercambio de información (por ejemplo, acuerdo de confidencialidad, cybersecurity interface agreement, development interface agreement).

Compartir sin filtrar propiedad intelectual

Una SBOM no es su código fuente. Enumera nombres de componentes, versiones, productores, licencias, hashes y relaciones. No contiene su código, sus algoritmos, sus datos de calibración ni su diseño.

• El CRA no obliga a los fabricantes a hacer pública la SBOM (considerando 77). Se entrega a una autoridad de vigilancia del mercado previa solicitud motivada (anexo VII, punto 8).
• Las recomendaciones de la CISA sobre el intercambio describen los canales habituales para el software propietario: correo electrónico bajo NDA, el portal de proveedores del cliente o un intercambio seguro de documentos, o un portal propio con acceso controlado, con contratos que regulan la confidencialidad y el acceso.
• Opciones prácticas: una SBOM completa por OEM bajo contrato; identificadores para las partes propietarias que no revelen nombres de proyectos internos; y un documento VEX aparte, para poder actualizar el estado de una vulnerabilidad sin volver a enviar la SBOM.

Con qué frecuencia, y qué pasa después de la entrega

• Una SBOM nueva para cada versión de software que entrega, con el mismo identificador que el OEM graba o registra. En vehículos, eso enlaza con la identificación de software de R156.
• Una SBOM corregida cuando encuentra un error en una que ya envió.
• Una declaración VEX o un aviso de seguridad cuando ha evaluado una vulnerabilidad.

La pregunta siguiente, «¿les afecta la CVE-X?», llega con la próxima gran vulnerabilidad. Esté preparado para responderla por cada versión entregada, algo que solo es posible si conservó la SBOM de cada una.

VEX: lo siguiente que esperará su cliente

Un documento VEX indica si un producto está afectado por una vulnerabilidad. Los Minimum Requirements for VEX de la CISA (abril de 2023) definen cuatro estados: not_affected, affected, fixed y under_investigation. Una declaración not_affected debe dar una de cinco justificaciones o, en su defecto, una declaración de impacto:

• component_not_present
• vulnerable_code_not_present
• vulnerable_code_not_in_execute_path
• vulnerable_code_cannot_be_controlled_by_adversary
• inline_mitigations_already_exist

Una declaración affected necesita una declaración de acción: qué debe hacer el cliente. VEX existe en tres formatos: el perfil VEX de CSAF 2.0, CycloneDX VEX y OpenVEX. La salida SPDX 3.0 de Yocto incluye datos VEX de forma predeterminada (la variable SPDX_INCLUDE_VEX).

Ejemplo práctico. Una pantalla basada en Linux incluye OpenSSL 3.0.8. La CVE-2023-0464 describe un consumo excesivo de recursos al verificar cadenas de certificados X.509 que incluyen restricciones de política. El procesamiento de políticas está desactivado de forma predeterminada y el software de la pantalla nunca lo activa. El proveedor envía una declaración OpenVEX a modo de ejemplo:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/display-fw-5.3.0-2023-0464",
  "author": "Example Displays Product Security",
  "timestamp": "2026-11-11T09:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2023-0464" },
      "products": [{ "@id": "pkg:generic/example/[email protected]" }],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path",
      "impact_statement": "X.509 policy processing is disabled by default and the firmware never enables it."
    }
  ]
}

Generar SBOM de forma repetible

Cómo compila	Forma realista de generar la SBOM
Software compilado en CI	Generar la SBOM en el build que produce el software entregado y conservarla con la versión
Linux embebido basado en Yocto	La salida SPDX propia de Yocto (create-spdx), revisada por lo que omite, o un registro del build de Yocto
Firmware bare-metal de herramientas basadas en modelos	Una biblioteca o herramienta generadora, nunca un editor de texto, mantenida en cada versión y validada antes del envío
Binarios de terceros que integra	Pedir la SBOM a su propio proveedor; el análisis binario como sustituto hasta que llegue

Sea cual sea la vía, valide el archivo antes de enviarlo. La lista de comprobación de calidad de SBOM recoge los validadores que probablemente usará su cliente, CycloneDX vs SPDX le ayuda con el formato, y estandarizar la generación de SBOM explica cómo hacerla igual en todos los equipos.

Qué papel tiene CRACI

Para los proveedores que compilan en GitHub Actions, CRACI sustituye a los runners alojados en GitHub y registra una SBOM de cada build, de modo que cada versión entregada ya tiene la suya.

• La SBOM incluye lo que el build descargó realmente, dependencias transitivas incluidas, con una package URL por paquete y la licencia declarada de cada componente.
• La SBOM de cada job lleva un estado de completitud, así que sabe lo que envía antes de enviarlo.
• Las SBOM se exportan en CycloneDX o SPDX, y CRACI admite VEX.
• Las SBOM vigiladas se reevalúan a medida que se publican vulnerabilidades nuevas, y el historial de builds muestra qué builds contenían una dependencia vulnerable, dentro de su periodo de retención.
• Los builds de Yocto se ejecutan en runners de CRACI y están documentados.
• Se pueden añadir SBOM de terceros, de modo que los componentes que compra se vigilan junto con sus propios builds.

Cuándo CRACI no es la respuesta

• No tiene CI, o compila en GitLab, Jenkins o un servidor de build. Hoy CRACI solo admite GitHub Actions; otros sistemas de CI están en la hoja de ruta.
• Su firmware se genera con herramientas basadas en modelos, sin descarga de paquetes. Ahí un registrador de builds aporta poco.
• Necesita alojar SBOM para muchos OEM en un portal de intercambio, o firmar SBOM. CRACI no ofrece ninguna de las dos cosas.
• Sus builds deben ejecutarse en su propia infraestructura. Los runners alojados por el cliente están en la hoja de ruta.
• Su cliente quiere una prueba de la gestión de la seguridad de su organización, como un certificado ISO 27001 o respuestas a un cuestionario NIS2. Una SBOM es evidencia para una parte de eso, no una certificación. El certificado ISO 27001 de CRACI cubre el servicio de CRACI, no el suyo.

SBOM para proveedores: preguntas frecuentes

Mi cliente, un OEM, me ha pedido una SBOM. ¿Estoy obligado a entregarla?

A menudo lo exige el contrato más que la ley. Si usted mismo introduce en el mercado de la UE un componente con elementos digitales, el Reglamento de Ciberresiliencia exige su propia SBOM. Si no, la obligación es del OEM, que se la traslada a través de la diligencia debida y del acuerdo de suministro.

¿Se aplica el CRA a los componentes que vendo a un fabricante?

Si introduce el componente en el mercado de la UE por separado, sí: el artículo 3, punto 1, incluye los componentes de software o hardware introducidos en el mercado por separado. Si solo llega al mercado dentro del producto del OEM, el fabricante es el OEM y debe ejercer la diligencia debida con su componente (artículo 13, apartado 5). Los componentes de vehículos homologados quedan fuera del CRA (artículo 2, apartado 2, letra c)).

¿Exigen una SBOM UN R155 o ISO/SAE 21434?

No. R155 nunca menciona una SBOM; exige al fabricante del vehículo gestionar los riesgos relacionados con los proveedores. ISO/SAE 21434 organiza el trabajo de ciberseguridad con los proveedores mediante acuerdos de interfaz. En automoción, las SBOM llegan como requisito contractual.

¿Qué formato y qué campos esperará un OEM?

Normalmente CycloneDX o SPDX en JSON o XML, alineado con los CISA 2026 Minimum Elements o con BSI TR-03183-2: autor y marca de tiempo y, por componente, nombre, versión, productor, package URL o CPE, licencia y hash, con las dependencias transitivas.

¿Con qué frecuencia tengo que enviar una SBOM actualizada?

Con cada versión de software que entregue, cada vez que corrija un error y con una declaración VEX o un aviso de seguridad cuando haya evaluado una vulnerabilidad. Acuerde el desencadenante en el contrato.

¿Compartir una SBOM expone nuestra propiedad intelectual?

No. Una SBOM enumera nombres de componentes, versiones, productores, licencias, hashes y relaciones, no código fuente, algoritmos ni datos de calibración. Compártala bajo NDA o en el marco del acuerdo de suministro, con el uso limitado a la gestión de vulnerabilidades y el cumplimiento. El CRA no exige que sea pública.

¿Qué es VEX y me lo pedirá mi cliente?

VEX indica si un producto está afectado por una vulnerabilidad: not_affected, affected, fixed o under_investigation, con una justificación para not_affected. Cuente con que se lo pidan tras la próxima vulnerabilidad de gran repercusión en un componente que usted entrega.

El firmware de nuestra ECU no tiene código abierto. ¿Cómo es nuestra SBOM?

Corta y honesta: la aplicación propietaria, el bootloader, las bibliotecas o calibraciones de un fabricante de semiconductores y cualquier código abierto, como una biblioteca criptográfica, cada uno con sus propios identificadores, más las incógnitas conocidas. No la infle.