¿Una lista de verificación de SBOM de la CRA te da una página de licencias?

Los equipos de producto deben tratar 2026-2027 como la ventana para poner en marcha el inventario de componentes, la generación de SBOM, los procesos de vulnerabilidades y (por separado) los flujos de divulgación de licencias. Esperar hasta la evaluación de conformidad para descubrir que no tienes un registro de licencias de terceros revisado crea una doble crisis.

Los plazos varían según la clase de producto y los actos de ejecución, y la documentación debe mantenerse al día durante todo el periodo de soporte. Confirma todas las fechas con tu asesoría legal; esta página no es asesoramiento jurídico.

El alcance depende de la clasificación del producto, no del tamaño de la empresa: los productos con elementos digitales comercializados en la UE están dentro del alcance, mientras que los productos ya cubiertos por normas específicas de la UE (dispositivos médicos, vehículos de motor, aviación civil) y los servicios en la nube puros sin un componente de producto suelen quedar excluidos. El software instalable, el firmware, los dispositivos conectados, y muchos modelos de distribución comercial de open source pueden entrar dentro del alcance cuando se venden en la UE.

Las exclusiones para SaaS puro existen en el entendimiento habitual del mercado, pero requieren una revisión legal específica del producto.

La CRA exige un SBOM, pero eso no cubre la divulgación de licencias. El Anexo I, Parte II obliga a los fabricantes a identificar y documentar los componentes, incluido un SBOM en un formato habitual y legible por máquina que cubra al menos las dependencias de primer nivel, lo cual son datos de identidad de componentes, no texto de licencia revisado.

Esa obligación acelera la adopción de SBOM entre los proveedores que venden en la UE. Los equipos generan CycloneDX o SPDX desde CI, a menudo por primera vez, y entregan los archivos a seguridad o cumplimiento. El SBOM satisface la documentación de componentes de la CRA. No genera automáticamente el aviso, la atribución ni el texto completo de la licencia de cada componente.

La documentación de ciberseguridad de la CRA cubre la evaluación de riesgos, las vulnerabilidades, las actualizaciones y el desarrollo seguro. La seguridad de producto, el PSIRT y legal son responsables de ese trabajo. El cumplimiento de licencias cubre las obligaciones de propiedad intelectual en el software de terceros: aviso, atribución, condiciones de copyleft. Un flujo de trabajo distinto con puertas de revisión humana.

Confundirlos crea una falsa confianza. Un equipo puede superar una revisión interna de preparación para la CRA con SBOM y SLA de parcheo, y aun así fallar ante la solicitud de cumplimiento de licencias de un comprador, porque nadie revisó el texto de la licencia.

• SBOM de la CRA: identidad de componentes para la documentación de seguridad y normativa.
• Divulgación de licencias: texto completo y atribución para legal y compras.
• CRA: notificación de vulnerabilidades a las autoridades bajo condiciones definidas.
• Licencia: condiciones de derechos de autor y distribución en las licencias de OSS.
• Misma entrada de lockfile, salidas distintas y responsables distintos.

La CRA espera que la documentación se actualice durante el periodo de soporte cuando cambian las vulnerabilidades y los componentes. Esa misma deriva de dependencias rompe las declaraciones de licencia si nadie vuelve a revisar lo que se distribuyó.

Los equipos de varias personas fusionan actualizaciones de paquetes continuamente. Sin reimportar y volver a publicar en cada versión, tanto tu SBOM de la CRA como tu divulgación de licencias describen el producto de ayer. La documentación normativa y los registros de cara al comprador deben avanzar junto con la base de código.

Los grandes clientes trasladan la postura de la CRA del proveedor a sus programas de cadena de suministro, y aun así pegan apartados de licencias de plantillas de RFP escritas antes de que existiera la CRA. Piden el SBOM, más una página de licencias de open source, más una atestación de que la lista se mantiene.

Los equipos de compras formados en la CRA esperarán un acceso duradero a los artefactos de cumplimiento. Eso no sustituye el contenido de la divulgación de licencias. Eleva el listón de lo actualizados y accesibles que deben ser tus registros.

Organización de seguridad: generación de SBOM, gestión de vulnerabilidades, notificación de incidentes, entradas para la conformidad de la CRA, entrega segura de actualizaciones.

Cumplimiento / legal / operaciones de ingeniería: inventario de licencias de terceros, revisión, puertas de publicación, exportaciones de divulgación, respuestas a cuestionarios de compradores.

Entrada compartida: lockfiles y SBOM de CI. Salida divergente: seguridad usa el SBOM para los CVE; cumplimiento usa la misma importación para los registros de licencia revisados.