El Cyber Resilience Act (CRA), Reglamento (UE) 2024/2847, no es solo un requisito documental. Conecta requisitos de seguridad del producto, gestión de vulnerabilidades, soporte, actualizaciones y comunicación de incidentes con el acceso al mercado europeo.
Nota de alcance: este artículo resume implicaciones técnicas generales para empresas de software. No sustituye una evaluación jurídica sobre el alcance, las excepciones o las obligaciones contractuales de un producto específico.
Qué cambia en la práctica
El principio central del CRA es tratar la ciberseguridad como una propiedad del producto durante todo su ciclo de vida. La Comisión Europea indica que los dispositivos y el software deben diseñarse, actualizarse y mantenerse de forma segura. La conversación deja de centrarse en una verificación puntual antes del lanzamiento y pasa a un proceso continuo de ingeniería y respuesta.
Para una empresa de software, cuatro áreas tienden a converger:
- desarrollo seguro: requisitos y controles incorporados al proceso de ingeniería;
- visibilidad de componentes: capacidad de identificar componentes y dependencias incluidos en el producto;
- gestión de vulnerabilidades: recibir, evaluar, corregir y comunicar fallas durante el período de soporte;
- evidencia de cumplimiento: registros que demuestren decisiones, pruebas, correcciones y control de cambios.
Los hitos que requieren atención ahora
| Fecha | Hito |
|---|---|
| 11 de junio de 2026 | Comenzaron a aplicarse las disposiciones sobre notificación de organismos de evaluación de la conformidad. |
| 11 de septiembre de 2026 | Comienzan a aplicarse las obligaciones de reporte de vulnerabilidades explotadas activamente e incidentes graves. |
| 11 de diciembre de 2027 | El reglamento pasa a aplicarse por completo. |
Según la Comisión Europea, el reporte previsto para septiembre de 2026 incluye una alerta inicial dentro de las 24 horas desde que se toma conocimiento y una notificación completa dentro de las 72 horas. El proceso usa la Single Reporting Platform y no debe tratarse como una tarea que comienza únicamente cuando ocurre un incidente.
Cumplir una ventana corta de reporte depende de un inventario operativo, responsables claros, clasificación y un proceso de respuesta probado.
Dónde aparece el impacto en ingeniería
El inventario no es una hoja de cálculo producida al final
La organización debe relacionar producto, versión, componentes, dependencias y responsables. Una SBOM puede apoyar esa visibilidad, pero su valor depende de la actualización, identificadores consistentes e integración con el proceso de vulnerabilidades. El inventario debe acompañar al artefacto realmente entregado, no solo al manifiesto de una etapa anterior del build.
La gestión de vulnerabilidades necesita entradas y salidas claras
Recibir un reporte es solo el comienzo. El proceso debe definir triaje, severidad, confirmación de impacto, corrección, distribución de actualizaciones, comunicación y preservación de evidencias. Sin conexión entre PSIRT, desarrollo, producto, soporte y legal, el reloj regulatorio avanza mientras la organización todavía busca al responsable.
El pipeline pasa a producir evidencias
Resultados de pruebas, políticas de aprobación, procedencia, firma e historial de promoción ayudan a responder “¿qué se entregó?” y “¿qué controles se ejecutaron?”. No significa guardar todos los logs indefinidamente, sino definir evidencias proporcionales al riesgo y protegerlas contra modificación o pérdida.
Cómo evaluar el nivel de preparación
- ¿Qué productos y versiones pueden estar dentro del alcance y quién responde por cada uno?
- ¿Qué período de soporte se comunicó y cómo se distribuyen las actualizaciones de seguridad?
- ¿Es posible generar un inventario reproducible a partir del artefacto entregado?
- ¿Existe un canal para recibir vulnerabilidades y un proceso para confirmar explotación activa?
- ¿Quién inicia el reporte y qué datos puede reunir durante las primeras 24 horas?
- ¿Los repositorios y pipelines conservan logs, aprobaciones y procedencia suficientes?
- ¿Una corrección puede construirse, probarse, firmarse y distribuirse sin improvisación?
- 01Productoalcance, versión y responsable definidos
- 02Inventariocomponentes relacionados con el artefacto entregado
- 03Monitoreoseguimiento continuo de vulnerabilidades e incidentes
- 04Triaje y correcciónimpacto confirmado, contenido y tratado
- 05Comunicaciónreporte y actualización de las partes involucradas
- 06Evidenciaregistros preservados para mejorar el proceso
Lo que una herramienta aislada no resuelve
SCA ayuda a identificar componentes y vulnerabilidades conocidas. SAST, DAST y otros controles amplían la cobertura técnica. Ninguno define por sí solo el alcance regulatorio, los responsables, el período de soporte, el proceso de reporte o los criterios de aceptación de riesgo. El CRA exige conectar gobernanza de producto, ingeniería, AppSec y respuesta a incidentes.
También es importante seguir las orientaciones oficiales y los actos de implementación. La Comisión Europea continúa publicando material de apoyo; por lo tanto, los controles y las interpretaciones deben revisarse durante la preparación.
Fuentes y referencias
- Comisión Europea — Cyber Resilience Act: implementación
- Comisión Europea — obligaciones de reporte del CRA
- Comisión Europea — resumen de la legislación
- EUR-Lex — Reglamento (UE) 2024/2847
¿Cómo se aplica esto a su ciclo de software?
Xmart ayuda a evaluar controles, evidencias y arquitectura de AppSec y Software Supply Chain, desde el inventario hasta la operación.
