Una vulnerabilidad en una dependencia, una actualización que afecta a varias versiones o una incidencia que requiere coordinar a distintos equipos. Son situaciones habituales en el desarrollo de software, pero con el Cyber Resilience Act (CRA) adquieren una nueva dimensión: la regulatoria.
Para quienes desarrollamos software, la seguridad no es un requisito aislado. Forma parte de las decisiones que se toman desde la arquitectura hasta el mantenimiento de una aplicación.
En knowmad mood conocemos estos desafíos de primera mano. Por eso abordamos el CRA desde dentro: desde la experiencia de construir software y la necesidad de trasladar sus exigencias a procesos reales de ingeniería.
Del código al marcado CE: las 5 claves del CRA
El CRA establece requisitos de ciberseguridad para los productos con elementos digitales comercializados en la Unión Europea, incluidos los productos de software sujetos a su ámbito de aplicación.
Para sus fabricantes, la adaptación implica actuar sobre cinco ámbitos:
|
Clave |
¿Qué supone para el fabricante? |
|
Seguridad desde el diseño |
Integrar controles durante todo el SDLC: arquitectura, desarrollo, pruebas, CI/CD y mantenimiento. |
|
Mantenimiento seguro |
Gestionar versiones, dependencias y actualizaciones durante el periodo de soporte. |
|
Gestión de vulnerabilidades |
Detectar, evaluar, priorizar y corregir vulnerabilidades de forma continua. |
|
Evaluación de riesgos |
Identificar los riesgos de ciberseguridad y aplicar las medidas correspondientes. |
|
Conformidad y marcado CE |
Documentar y demostrar que el software cumple los requisitos aplicables. |
No se trata de cinco tareas independientes, sino de capacidades que deben funcionar de forma coordinada durante el ciclo de vida del producto.
El reloj ya está en marcha
Aunque los principales requisitos del CRA serán aplicables a partir del 11 de diciembre de 2027, las obligaciones de notificación de vulnerabilidades activamente explotadas e incidentes graves de seguridad ya están en aplicación desde el 11 de septiembre de 2026.
Cuando se produce uno de estos supuestos, el fabricante afectado debe emitir una alerta temprana en un máximo de 24 horas, sin demora injustificada, y una notificación más completa en 72 horas, a través de la Single Reporting Platform (SRP) establecida por ENISA.
Ahora imaginemos que se descubre una vulnerabilidad activamente explotada en un componente utilizado por varias aplicaciones.
¿Sabemos qué versiones están afectadas? ¿Quién evalúa el impacto? ¿Quién autoriza la notificación? ¿Podría activarse el procedimiento un viernes por la noche?
Ahí es donde los requisitos del CRA se encuentran con la realidad del desarrollo de software.
De conocer los requisitos a poder aplicarlos
La adaptación al CRA exige conectar ingeniería, seguridad, operaciones y cumplimiento.
Desde nuestra experiencia en desarrollo de software, en knowmad mood podemos acompañar a otros fabricantes en ese proceso: identificar brechas, incorporar prácticas de desarrollo seguro y DevSecOps, mejorar la gestión de vulnerabilidades y preparar las evidencias técnicas necesarias para la conformidad.
Porque la ciberresiliencia no se demuestra únicamente con documentación, sino con procesos capaces de funcionar cuando realmente se necesitan.
¿Tu organización podría responder en 24 horas?
Hemos creado el CRA 24h Readiness Autodiagnóstico para ayudarte a descubrirlo.
En solo 3 minutos y a través de 12 preguntas, descubre el nivel de preparación de tu organización para responder ante las obligaciones de notificación del CRA y recibe recomendaciones para mejorar.
Fuentes: