Desarrollo de software seguro como obligación normativa: CRA, DORA y NIS2

29 de abril de 2025

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.

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).

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.

DevSecOps vs SSDLC: ¿Cuál es la mejor estrategia para desarrollo seguro?