Desarrollo de software seguro como obligación normativa: CRA, DORA y NIS2
El desarrollo de software entra en una nueva etapa regulatoria en Europa. La ciberseguridad, que hasta ahora se abordaba en muchos casos como una buena práctica o como un añadido posterior, pasa a convertirse en una exigencia normativa transversal. Con la entrada en vigor de regulaciones como el Cyber Resilience Act (CRA), la Digital Operational Resilience Act (DORA) y la Directiva NIS2, la forma en la que se diseña, construye, despliega y mantiene el software deberá transformarse en profundidad.
Estas normativas introducen obligaciones específicas para fabricantes, desarrolladores, entidades financieras, infraestructuras críticas y proveedores de servicios digitales, estableciendo un mensaje común: la seguridad debe estar integrada desde el diseño y mantenerse durante todo el ciclo de vida del software.
Cyber Resilience Act (CRA)
- Aprobación final: marzo de 2024.
- Aplicación obligatoria: mediados de 2025 (24 meses tras publicación oficial).
CRA es la primera legislación de la UE centrada en garantizar que todos los productos con elementos digitales (hardware y software) incorporen medidas de ciberseguridad por diseño y por defecto. Afecta tanto a productos comerciales como industriales, incluyendo aplicaciones, firmware, routers, smart devices o software de propósito general.
Requisitos destacados
- Aplicación de medidas de seguridad desde el diseño y configuración por defecto segura (Art. 10).
- Gestión continua de vulnerabilidades, incluyendo monitorización, respuesta y actualizaciones obligatorias (Art. 11).
Periodo de mantenimiento de seguridad mínimo de 5 años, incluso para software que ya ha sido desplegado. - Obligación de notificar vulnerabilidades activamente explotadas a ENISA en un plazo de 24 h (Art. 12).
- Evaluaciones de conformidad, documentación técnica extensa y trazabilidad en el desarrollo.
CRA redefine el desarrollo moderno: la gestión de la seguridad ya no puede quedar limitada a capas externas o a fases finales del producto, sino que debe incorporarse en el core del proceso de ingeniería.
■ Ya no basta con pasar un npm audit al final y cruzar los dedos. Las normativas exigen mucho más que escanear dependencias: piden evidencia de seguridad activa, mantenida y demostrable.
Digital Operational Resilience Act (DORA)
- Aprobado: diciembre de 2022.
- Aplicación directa en toda la UE: 17 de enero de 2025.
El Reglamento DORA se centra en asegurar la resiliencia operativa digital de todo el ecosistema financiero europeo, incluyendo bancos, aseguradoras, fintechs y, especialmente, a los proveedores TIC considerados críticos. Esto incluye servicios cloud, gestión de datos, desarrollo software y otros subcontratistas tecnológicos esenciales.
Áreas clave de cumplimiento
- Gestión de riesgos TIC (Capítulo II): políticas claras, responsabilidades definidas, gestión de configuraciones, actualizaciones, accesos y activos críticos.
- Gestión de incidentes (Capítulo III): clasificación, comunicación interna, notificación obligatoria al regulador en 4 h.
- Pruebas de resiliencia digital (Capítulo IV): desde escaneos y auditorías hasta pruebas avanzadas tipo Red Teaming.
- Gestión de terceros TIC (Capítulo V): controles específicos para proveedores críticos (contratos, SLA, evaluación de riesgos).
- Intercambio de información (Capítulo VI): colaboración e inteligencia compartida frente a amenazas.
La aplicación de un SSDLC formal y documentado es fundamental para cumplir con los requisitos de prueba, trazabilidad y control de riesgos en todo el entorno tecnológico.
NIS2 (Directiva 2022/2555)
- Entrada en vigor: enero de 2023.
- Transposición obligatoria en Estados miembros: antes del 17 de octubre de 2024.
La nueva Directiva NIS2 sustituye a su predecesora con un alcance mucho más amplio. Clasifica a las organizaciones en dos grandes categorías: entidades esenciales y críticas, e incluye sectores como:
- Energía, transporte, salud, agua potable y residuos.
- Infraestructuras digitales, gestión pública, servicios financieros.
- Proveedores de hosting, servicios cloud, DNS, redes sociales, centros de datos y desarrollo de software
Requisitos de seguridad destacados
- Políticas de gobernanza de Ciberseguridad alineadas con el riesgo real.
- Evaluación y mitigación de riesgos en toda la cadena de suministro.
- Procesos de detección, respuesta y notificación de incidentes.
- Formación continua del personal técnico y directivo. Aplicación de medidas durante todo el ciclo de vida del desarrollo (Art. 21).
■ NIS2 establece también sanciones significativas por incumplimiento, con multas proporcionales a la facturación y responsabilidad explícita para los órganos de gestión de las entidades afectadas.
Conclusión: el SSDLC es ahora una exigencia normativa
Estas tres normativas convergen en un punto común: la ciberseguridad debe estar integrada desde el primer diseño del software y mantenerse operativa durante todo su ciclo de vida.
El marco de trabajo SSDLC, lejos de ser una recomendación, se convierte en un componente técnico y legal obligatorio en múltiples sectores. Esto implica:
- Incorporar análisis de riesgos y pruebas de seguridad automatizadas en el pipeline de desarrollo.
- Garantizar la trazabilidad de las decisiones de diseño, gestión de cambios y actualizaciones.
- Establecer procesos formales de revisión de código, auditorías y documentación técnica.
- Prepararse para notificaciones obligatorias, inspecciones y auditorías por parte de autoridades competentes.
■ El desarrollo seguro ya no es opcional: es un pilar técnico, operativo y legal que afecta al presente y futuro del software en Europa.