EU CRA: trazabilidad de código y gestión de vulnerabilidades como ley
EU Cyber Resilience Act: la seguridad del software ya es una obligación legal con marcado CE
El Reglamento (UE) 2024/2847 convierte la ciberseguridad en un requisito de comercialización para cualquier producto con elementos digitales en la UE. La trazabilidad del código, la gestión de vulnerabilidades y el SBOM verificable dejan de ser buenas prácticas para convertirse en obligaciones jurídicas.
Puntos clave
- El EU CRA (Reglamento (UE) 2024/2847) publicado el 23 de octubre de 2024 establece requisitos obligatorios de ciberseguridad para todos los productos con elementos digitales comercializados en la UE.
- Las obligaciones de notificación de vulnerabilidades activamente explotadas (Art. 14) son de aplicación desde el 11 de septiembre de 2026 — la primera fecha crítica para fabricantes de software.
- La plena aplicación del reglamento, incluyendo el marcado CE de ciberseguridad, entra en vigor el 11 de diciembre de 2027.
- El Art. 13 exige que los fabricantes documenten y acrediten su Secure Development Lifecycle (SDL) — desde el diseño hasta el fin de vida útil del producto.
- El Art. 16 introduce el Software Bill of Materials (SBOM) como obligación: una lista verificable de todos los componentes de software del producto.
- V-PROOF Git Integration genera la cadena de custodia criptográfica del código commit a commit — la base técnica para cumplir Arts. 13, 14 y 16 simultáneamente.
EU CRA: cuando "secure by design" deja de ser un eslogan y se convierte en ley
Durante décadas, la industria del software ha operado bajo un principio implícito: la ciberseguridad es una característica opcional que se añade si el mercado la exige. El EU Cyber Resilience Act termina con ese modelo. A partir de diciembre de 2027, ningún producto con elementos digitales puede comercializarse en la UE sin acreditar que cumple los requisitos de seguridad del Anexo I del reglamento.
Publicado el 23 de octubre de 2024 en el Diario Oficial de la UE, el Reglamento (UE) 2024/2847 afecta a cualquier producto hardware o software que incluya "elementos digitales" — una definición deliberadamente amplia que cubre desde dispositivos IoT industriales hasta aplicaciones móviles, desde sistemas de control de acceso hasta software de gestión empresarial. Solo quedan excluidos explícitamente los productos ya cubiertos por normativa sectorial específica (dispositivos médicos, vehículos, aviación) y el software como servicio puro sin descarga de componentes en el dispositivo del usuario.
El cambio de paradigma del EU CRA
El EU CRA desplaza la responsabilidad de la ciberseguridad del usuario final al fabricante. Hasta ahora, cuando un software tenía vulnerabilidades, el usuario "aceptaba el riesgo" al instalar el producto. Con el CRA, el fabricante es responsable de la seguridad del producto durante todo su ciclo de vida, incluyendo la gestión de vulnerabilidades post-lanzamiento durante al menos cinco años o durante el período de uso previsto si es mayor.
Las sanciones por incumplimiento son significativas: hasta 15 millones de euros o el 2,5% de la facturación global anual por incumplimiento de los requisitos esenciales de ciberseguridad del Anexo I, y hasta 10 millones o el 2% por incumplimiento de otras obligaciones como la notificación de vulnerabilidades. Los organismos nacionales de vigilancia del mercado son responsables de la supervisión en cada Estado miembro.
Tres categorías, tres niveles de exigencia
El EU CRA clasifica los productos en tres categorías según su nivel de riesgo de ciberseguridad. La categoría determina el procedimiento de evaluación de conformidad requerido para obtener el marcado CE:
Las fechas que los equipos de producto deben tener en su roadmap
Por qué empezar ahora y no en 2027
El EU CRA exige que los fabricantes demuestren un Secure Development Lifecycle — un proceso de desarrollo seguro — no solo que el producto final cumple requisitos puntuales. Un proceso tiene historial. Las auditorías de conformidad mirarán hacia atrás: un fabricante que empiece a sellar criptográficamente su proceso de desarrollo en 2024–2026 tendrá dos o tres años de historial verificable cuando llegue la evaluación. Uno que empiece en diciembre de 2027 tendrá cero historial demostraBLE.
Los artículos que exigen evidencia técnica — y qué genera V-PROOF para cada uno
Cobertura V-PROOF por obligación EU CRA
| Obligación EU CRA | Requisito | Cobertura | Módulo V-PROOF |
|---|---|---|---|
| Art. 13 — Secure Development Lifecycle | |||
| Art. 13(1)SDL documentado | Historial verificable del proceso de desarrollo seguro desde el diseño hasta el despliegue | ✓ Completa | Git Integration |
| Art. 13(3)Gestión de parches | Trazabilidad de la aplicación de parches de seguridad: cuándo, qué versión, quién lo autorizó | ✓ Completa | Git Integration |
| Art. 13(6)Documentación técnica | Documentación técnica actualizada y verificable para evaluación de conformidad | ✓ Completa | V-Seal Core Git Integration |
| Art. 14 — Notificación de vulnerabilidades e incidentes | |||
| Art. 14(1)24h — Alerta ENISA | Registro con timestamp del momento exacto de descubrimiento de la vulnerabilidad explotada | ✓ Completa | V-Seal Core |
| Art. 14(2)72h — Notificación | Registro de las acciones tomadas desde el descubrimiento hasta la notificación formal | ✓ Completa | V-Seal Core |
| Art. 14(7)Notificación a ENISA | La notificación formal a ENISA es responsabilidad del fabricante | — Responsabilidad del fabricante | Proceso regulatorio |
| Art. 16 — Software Bill of Materials (SBOM) | |||
| Art. 16SBOM verificable | Lista completa y verificable de componentes de software, incluyendo dependencias de terceros y open source | ✓ Completa | Git Integration |
| Anexo I — Requisitos esenciales de ciberseguridad | |||
| Anexo I — Parte IRequisitos del producto | Evidencia de implementación de cada control de seguridad requerido en el diseño del producto | ✓ Completa | V-Seal Core |
| Anexo I — Parte IIGestión de vulnerabilidades | Proceso verificable de identificación, análisis y resolución de vulnerabilidades durante el ciclo de vida | ✓ Completa | Git Integration V-Seal Core |
| Convergencia EU CRA + EU AI Act — Para software con componentes de IA | |||
| EU CRA Art. 13+ EU AI Act Art. 12 | Trazabilidad del ciclo de vida de modelos de IA integrados en productos software: versiones, entrenamiento, despliegue | ✓ Completa | AI Orchestrator Git Integration |
EU CRA + EU AI Act: la doble obligación para software con IA integrada
Cualquier producto software que integre componentes de IA está sujeto simultáneamente al EU CRA y al EU AI Act. Y la intersección crea obligaciones adicionales que ninguno de los dos marcos cubre de forma aislada.
Un sistema de detección de anomalías basado en ML integrado en un software de ciberseguridad, un asistente de código con IA, un sistema de recomendación de seguridad en una plataforma SaaS — todos son sistemas de IA bajo el EU AI Act y productos con elementos digitales bajo el EU CRA. El fabricante debe cumplir los requisitos de trazabilidad del ciclo de vida del software (EU CRA Art. 13) y los requisitos de registro de eventos y supervisión humana del sistema de IA (EU AI Act Arts. 12 y 14) con el mismo producto.
V-PROOF cubre la intersección con una sola integración
El módulo AI Orchestrator de V-PROOF registra criptográficamente el ciclo de vida completo de los modelos de IA integrados en el producto: datasets de entrenamiento, versiones del modelo, métricas de evaluación y cada decisión en producción. El módulo Git Integration registra el código que los implementa. Juntos, cubren las obligaciones de trazabilidad del EU CRA (Art. 13) y del EU AI Act (Arts. 12, 16) sin duplicar la integración.
El EU CRA y la seguridad de la cadena de suministro del software
El EU CRA introduce un concepto que cambia la forma en que los equipos de desarrollo deben pensar en sus dependencias: la responsabilidad de la cadena de suministro de software. Los fabricantes son responsables de las vulnerabilidades de los componentes de terceros que integran en sus productos — incluyendo librerías open source.
Esta responsabilidad se extiende a los proveedores de herramientas de desarrollo que el fabricante utiliza en su proceso de SDL. Un fabricante que usa una plataforma de CI/CD o de gestión de código con sede en EE.UU. para gestionar su proceso de desarrollo seguro introduce en su cadena de suministro un componente sujeto al CLOUD Act. Si las autoridades americanas requieren acceso al historial de desarrollo del producto — incluidos los registros de vulnerabilidades descubiertas y sus plazos de resolución — ese proveedor no puede garantizar la confidencialidad.
V-PROOF Git Integration genera la trazabilidad del código con sede legal en España. Los registros del SDL son soberanos: la cadena de custodia criptográfica del proceso de desarrollo permanece bajo jurisdicción de la UE.
V-PROOF ante el EU CRA
Fortalezas, casos de uso regulatorio y límites del alcance
- Cadena de custodia criptográfica del código commit a commit — el SDL documentado y verificable que Art. 13 exige, construido durante el desarrollo normal Art. 13 — SDL verificable
- Timestamp blockchain del momento exacto de descubrimiento de cada vulnerabilidad — esencial para acreditar el cumplimiento del plazo de 24h del Art. 14 Art. 14 — Notificación vuln.
- Trazabilidad de dependencias y componentes de terceros commit a commit — la base técnica para generar y verificar el SBOM del Art. 16 Art. 16 — SBOM
- Historial verificable de implementación de controles del Anexo I — la evidencia para la documentación técnica de evaluación de conformidad y marcado CE Anexo I — Requisitos esenciales
- Cobertura dual EU CRA + EU AI Act para software con componentes de IA integrados — una sola integración para dos marcos normativos Convergencia normativa 2026–2027
- Proveedor con sede legal en España: el proceso de SDL registrado en V-PROOF no está sujeto al CLOUD Act americano Soberanía cadena de suministro
- ISVs (Independent Software Vendors) que comercializan software en la UE y necesitan documentar su SDL antes de diciembre de 2027 Art. 13 — Fabricantes software
- Fabricantes de dispositivos IoT industriales y de consumo con software integrado — especialmente Clase I y II con mayor exigencia de evaluación Clase I–II — Productos críticos
- Equipos DevSecOps que necesitan sellar criptográficamente su pipeline CI/CD como evidencia del proceso de desarrollo seguro Art. 13 — Pipeline CI/CD
- CISOs preparando la documentación técnica para evaluaciones de conformidad de Clase I y II con la mayor antelación posible Arts. 24–32 — Evaluación conformidad
- Fabricantes de software con IA integrada que tienen doble obligación EU CRA + EU AI Act y buscan una sola infraestructura de trazabilidad Convergencia EU CRA + EU AI Act
- El diseño de la arquitectura de seguridad del producto: V-PROOF certifica que el proceso de implementación se ejecutó correctamente, no diseña la arquitectura de seguridad. Diseño de producto
- Pruebas de penetración y security testing (Anexo I): V-PROOF sella los resultados de las pruebas, no las ejecuta. Las pruebas las realiza el equipo de seguridad o un tercero especializado. Anexo I — Security testing
- La notificación formal de vulnerabilidades a ENISA (Art. 14): V-PROOF genera el registro inmutable del descubrimiento; la notificación formal al regulador es responsabilidad del fabricante. Art. 14 — Notificación ENISA
- El marcado CE (Art. 47): requiere evaluación de conformidad por organismo notificado en Clase I y II. V-PROOF genera la evidencia técnica que facilita esa evaluación, no la otorga. Art. 47 — Marcado CE
¿Tiene su equipo de desarrollo el SDL documentado que los evaluadores de conformidad CRA exigirán?
V-PROOF ofrece un diagnóstico estratégico de 48 horas que mapea las obligaciones EU CRA aplicables a sus productos, identifica los gaps de trazabilidad de código existentes y define la integración de Git Integration necesaria.
Solicitar Diagnóstico Estratégico EU CRAFuentes y referencias normativas
- Reglamento (UE) 2024/2847 del Parlamento Europeo y del Consejo, de 23 de octubre de 2024 — EUR-Lex CELEX:32024R2847
- ENISA — EU CRA Implementation Guidance, 2025 — enisa.europa.eu
- Comisión Europea — Preguntas frecuentes sobre el EU CRA — digital-strategy.ec.europa.eu
- CEN/CENELEC — Mandato de normalización para el EU CRA (normas técnicas armonizadas) — cencenelec.eu
- BSI (Bundesamt für Sicherheit in der Informationstechnik) — EU CRA Orientation Guide for Manufacturers, 2025 — bsi.bund.de
- Reglamento (UE) 2024/1689 (EU AI Act) — referencia de convergencia con EU CRA para software con IA — EUR-Lex
