Un SBOM en el CRA es prueba, no un archivo generado una vez

En el Cyber Resilience Act la lista de materiales de software no es un recuerdo de auditoría. El anexo I parte II pide al fabricante identificar y documentar vulnerabilidades, incluido un SBOM. El artículo 13 ata esa documentación a una evaluación de riesgo a lo largo del ciclo de vida. El 11 de diciembre de 2027 el SBOM está en el expediente técnico que puede pedir la vigilancia del mercado.

Un export CycloneDX o SPDX del pipeline del año pasado no hace ese trabajo si el producto en el mercado de la Unión ya lleva dos versiones menores.

Qué quiere de verdad el CRA del SBOM

El reglamento no elige su formato. Elige su deber. Comercializa un producto con elementos digitales. Debe diligencia debida sobre componentes de terceros. Tiene que poder decir qué hay en la versión que envió y tratar vulnerabilidades durante el periodo de soporte declarado en la compra (mes y año).

Eso convierte el SBOM en un registro de producto, no de repositorio. La unidad es la versión del PDE: el firmware en la caja, el instalador en la tienda, la biblioteca que vende como componente. Un volcado de monorepo que mezcla tres SKU no es prueba. Una caja en la nube que operaciones no abre un viernes por la noche tampoco.

El SBOM también tiene que servir cuando el 11 de septiembre de 2026 arranque el artículo 14. Una vulnerabilidad explotada de forma activa en una dependencia transitiva es un problema de 24 h solo si puede nombrar los productos que la contienen.

Que coincida con la versión enviada, o el expediente ya está mal

El fallo habitual es el desvío. La tienda muestra 3.4.1. El SBOM del disco compartido salió de main en marzo. Dos sprints añadieron una librería TLS y quitaron un SDK de proveedor. El escaneo sigue. La prueba no.

Bloquee el SBOM al build que salió del almacén:

• la misma cadena de versión que en el catálogo,
• el mismo commit / digest de imagen que firmó,
• componentes propios y de terceros, con proveedor y versión,
• una fecha, para ver cuándo el archivo dejó de coincidir con el producto.

La diligencia debida se queda en el componente. Si un proveedor publica un arreglo, la fila tiene que mostrar que lo vio, lo evaluó frente a este PDE y o tomó la actualización o aceptó un riesgo documentado frente al anexo I. Una insignia verde en un escáner SaaS no es esa fila.

El SBOM alimenta la cola, la cola no es el SBOM

El CRA no es un escáner. El SBOM dice a la cola qué componentes existen. El escáner dice cuáles de ellos tienen debilidades conocidas. El artículo 14 hace la tercera pregunta: ¿se explota de forma activa, o es un incidente grave, y puede avisar al CSIRT y a ENISA en 24 horas?

Si esos tres objetos viven en tres herramientas con tres nombres de producto, el reloj de 24 h ya está perdido. El cruce mínimo es aburrido e innegociable:

1. Identidad PDE en el catálogo.
2. Líneas de SBOM unidas a esa identidad.
3. Hallazgos unidos a esas líneas.
4. Dueño nombrado y estado 24 h / 72 h.

Sin el cruce obtiene silencio (nadie sabe que el producto está afectado) o ruido (cada CVE del sector cae en una lista de correo).

Qué debe estar en el expediente técnico

El 11 de diciembre de 2027 el expediente no es «adjuntar latest SBOM.pdf». Es la identidad del producto, la evaluación de riesgo, las pruebas del anexo I, el SBOM de la versión comercializada, el periodo de soporte, las instrucciones, la declaración UE y el marcado CE.

Eso tiene consecuencias para el almacenamiento:

• la autoridad pregunta por este producto, no por el patrimonio de software de la empresa,
• el SBOM puede hacer falta años después de que el tren de versiones se haya ido,
• exportar no puede significar copiar el catálogo a la nube de un proveedor.

Crado AI guarda el SBOM on-premise, junto al catálogo y a la cola del artículo 14, por eso. La lista de materiales es parte del expediente que puede mostrar antes de que el producto salga del almacén.

Una práctica de SBOM que aguante antes de septiembre de 2026

1. Genere el SBOM desde el pipeline para cada versión que aún soporte, no solo para el siguiente release.
2. No envíe si la versión del catálogo y la del SBOM no coinciden.
3. En cada línea de terceros conserve proveedor y versión, para que la diligencia tenga asa.
4. Una los hallazgos a esas líneas. Ciérrelos o acéptelos frente al anexo I, no frente a un recuento de tickets.
5. Ensaye un drill del artículo 14: elija un componente, liste los PDE, nombre al dueño, cronometre la alerta temprana.

Si el paso 5 no lo hace una tarde laboral, el SBOM sigue siendo un archivo. Aún no es prueba.