La Ley de Resiliencia Operativa Digital (DORA) exige que las entidades financieras integren prácticas de revisión de código fuente DORA dentro de un SDLC seguro DORA para mitigar los riesgos relacionados con las vulnerabilidades de las aplicaciones y el código malicioso.

Significado de “cuando sea factible”

El Artículo 25 de DORA establece que los programas de pruebas de software deben incluir revisiones del código fuente “cuando sea factible”. Este requisito se aplica cuando el código fuente está efectivamente disponible para la entidad financiera. En consecuencia, la revisión de código es obligatoria para el software desarrollado internamente y para desarrollos personalizados realizados por terceros, mientras que puede excluirse para paquetes “listos para usar” (off-the-shelf) cuando el código no se proporciona.

Revisión de código, SAST, DAST y revisión manual

Las entidades financieras deben adoptar un enfoque riguroso para las pruebas de software DORA, en línea con el Reglamento Delegado (UE) 2024/1774:

• Static Application Security Testing (SAST): Análisis estático del código fuente para detectar vulnerabilidades lógicas y de seguridad sin ejecutar el programa.
• Dynamic Application Security Testing (DAST): Pruebas dinámicas realizadas con el software en funcionamiento para identificar fallos que surgen durante la ejecución.
• Pruebas de seguridad para sistemas expuestos: Se requieren verificaciones de seguridad exhaustivas para aplicaciones y sistemas accesibles desde Internet antes de su puesta en producción.

Aplicaciones personalizadas y funciones críticas

El nivel y la intensidad de las pruebas deben estar correlacionados con la criticidad de las funciones empresariales respaldadas por los activos TIC. Para las aplicaciones que sustentan funciones críticas o importantes, DORA prevé:

• Verificación mediante pruebas de que los nuevos sistemas son adecuados para operar según lo previsto.
• Análisis de la calidad del software desarrollado internamente para prevenir errores que puedan causar interrupciones operativas.
• Implementación de controles para salvaguardar la integridad del código fuente, evitando manipulaciones no autorizadas durante el desarrollo y la distribución.

Integración en el ciclo de desarrollo (SDLC seguro)

• Segregación de entornos: Los entornos de desarrollo y pruebas deben estar separados rigurosamente del entorno de producción.
• Gestión de datos de prueba: Está prohibido el uso de datos reales en entornos que no sean de producción, a menos que estén anonimizados, seudonimizados o aleatorizados, garantizando la integridad y confidencialidad.
• Gobernanza de proyectos: Los proyectos TIC que impactan en funciones críticas deben ser reportados regularmente al órgano de administración.

Evidencias para auditoría y gestión de remediación

• Identificación de anomalías: Cada vulnerabilidad o anomalía detectada debe ser analizada.
• Plan de acción: Es obligatorio preparar un plan de acción para corregir las deficiencias, definiendo responsabilidades y plazos.
• Monitoreo: La implementación de las medidas correctivas debe ser monitoreada constantemente para asegurar que el riesgo residual permanezca dentro de los límites previstos.

Preguntas frecuentes

• ¿La revisión de código es obligatoria?
• Sí, es necesaria para todo el software desarrollado internamente o personalizado. Para el software de terceros, es obligatoria “cuando sea factible”, es decir, cuando el proveedor pone a disposición el código fuente.
• ¿Es suficiente con SAST?
• No. Se requiere que las revisiones de código incluyan tanto SAST como DAST para una evaluación completa de la seguridad de las aplicaciones.
• ¿Cómo definir las prioridades?
• Las prioridades deben seguir un enfoque basado en el riesgo, dando preferencia a los sistemas que soportan funciones críticas o importantes y a aquellos expuestos a redes externas o Internet.

Construya software resiliente: solicite una evaluación de su SDLC seguro y de su programa de pruebas de aplicaciones para alinear sus procesos de desarrollo con los requisitos técnicos de DORA.