El CRA no es un escáner de vulnerabilidades

Un fabricante que trata el Cyber Resilience Act como «escanea el firmware y archiva los CVE» no cierra el expediente, aunque el escáner sea bueno. El Reglamento (UE) 2024/2847 es una norma de seguridad del producto para productos con elementos digitales. Pregunta qué comercializa en la Unión, qué riesgo aceptó, de qué está hecho el producto y cómo lo mantendrá durante el periodo de soporte.

El tratamiento de vulnerabilidades se queda. Es un deber dentro del anexo I parte II y del reloj del artículo 14. No es el producto.

Por qué la historia del escáner vuelve en cada conversación

Un escáner tiene demo. Un catálogo PDE no. Una fila de riesgo anclada al anexo I no enciende un panel en cinco minutos. Por eso el primer herramienta en una conversación CRA suele ser la que seguridad ya paga.

Esa herramienta responde a una pregunta estrecha: qué debilidades conocidas hay en este build. El CRA pregunta más ancho: ¿puede comercializar este producto y lo sostendrá cuando llame una autoridad o un CSIRT? Esos son otros expedientes.

Si el único artefacto CRA que sabe exportar es un informe de vulnerabilidades, no tiene un sistema CRA. Tiene un escáner con portada nueva en la diapositiva.

Primero el mapa de productos

El destinatario principal es el fabricante: quien comercializa un producto con elementos digitales en el mercado de la Unión bajo su nombre o marca. Puede ser un dispositivo, software autónomo o un componente vendido por separado. Importadores y distribuidores arrastran deberes propios. Un escaneo no los ve.

Antes de hablar de colas de CVE hace falta un catálogo. Nombre, versión, tipo, mercados, fecha de puesta a disposición, fin de soporte con mes y año. El CRA se aplica por producto, no una vez para toda la empresa. Una modificación sustancial es una nueva comercialización.

Sin ese mapa no sabe qué SBOM pertenece a cada SKU, qué lagunas del anexo I están abiertas ni a qué CSIRT notifica cuando el 11 de septiembre de 2026 arranque el artículo 14. Un escáner que no conoce la identidad del producto escanea un blob.

El riesgo está anclado al anexo I, no a un color CVSS

El artículo 13 pide una evaluación de riesgo de ciberseguridad a lo largo del ciclo de vida, no una diapositiva antes del lanzamiento. El anexo I tiene dos partes.

Parte I son las propiedades del producto: un nivel adecuado de ciberseguridad frente al riesgo, ninguna vulnerabilidad explotable conocida en el momento de comercializar, configuración segura por defecto, actualizaciones (incluidas las automáticas con opt-out claro), control de acceso, integridad, confidencialidad, menor superficie de ataque, minimización de datos.

Parte II es el tratamiento de vulnerabilidades: identificar y documentar, incluido el SBOM; parchear durante el periodo de soporte; pruebas; política pública de revelación; revelación coordinada; correcciones sin demora indebida.

Un escáner puede alimentar la parte II. No decide si la contraseña por defecto sigue siendo admin, si se puede rechazar la actualización o si la superficie creció al añadir diagnóstico remoto. Una laguna en una hoja aparte no es una evaluación. La fila de riesgo debe apuntar al requisito que no cumple.

«Ninguna vulnerabilidad explotable conocida al comercializar» tampoco es «el último escaneo del viernes salió limpio». Es una afirmación sobre el producto que va a salir del almacén, con el SBOM de esa versión y un dueño que la defiende.

El SBOM es prueba, no un PDF en un cajón

La diligencia debida sobre componentes de terceros se queda en el componente. El SBOM tiene que coincidir con la versión que realmente envía. La versión de la tienda y la del SBOM, que se desalinean tras dos sprints, es el fallo habitual.

El SBOM alimenta la cola de vulnerabilidades. El 11 de septiembre de 2026 empieza el artículo 14 para vulnerabilidades explotadas de forma activa e incidentes graves. Alerta temprana en 24 horas, notificación completa en 72 horas, informe final, por la plataforma única al CSIRT del establecimiento principal y a ENISA.

Un escáner que vuelca 400 CVE en una hoja no le da un dueño a 24 horas. Le da ruido. El corte operativo: cuáles de esos están en el SBOM enviado, cuáles se explotan de forma activa, a qué producto pegan, quién presenta la alerta temprana.

El expediente técnico es lo que puede pedir una autoridad

Desde el 11 de diciembre de 2027 un producto comercializado debe cumplir el anexo I, completar la evaluación de la conformidad, llevar declaración UE y marcado CE. La vigilancia del mercado puede pedir el expediente años después.

Ese expediente no es un informe de vulnerabilidades. Es la identidad del producto, la evaluación de riesgo, las pruebas del anexo I, el SBOM, el periodo de soporte, las instrucciones, la declaración y el marcado. Si falta uno, la vía CE no está cerrada.

La mayoría de los productos de clase por defecto se quedan en el módulo A. El módulo A necesita ese expediente igual. Un escáner mejor en 2027 no escribe la declaración.

Para qué sirve el escáner dentro del CRA

Quédese el escáner. Apúntelo al build que coincide con el SBOM. Ábrale partidas de la parte II y refresque la cola. No lo use como:

• catálogo de productos,
• evaluación del artículo 13,
• lista del anexo I,
• registro del periodo de soporte,
• declaración UE,
• playbook del artículo 14.

Esos objetos tienen dueños, fechas y claves de producto. Un hallazgo no.

Qué sostiene el sistema

Crado AI está construido alrededor de ese bucle, solo on-premise:

1. Catálogo PDE - lo que comercializa.
2. Riesgo y anexo I - qué requisitos se cumplen y cuáles no.
3. SBOM - componentes propios y de terceros, ligados a CVE.
4. Artículo 14 - el reloj 24 h / 72 h.
5. Expediente técnico y CE - lo que puede mostrar antes de que el producto salga del almacén.

El tratamiento de vulnerabilidades se queda. No es el producto. Si su plan CRA es renovar el escáner y un taller CE en 2027, el plan es la diapositiva, no el expediente.