10. Pruebas de Seguridad Criterios para verificar si el diseño y la implementación de la aplicación cumplen con los requerimientos de seguridad establecidos. 10.1 Comienzo Temprano de la Etapa de Pruebas Cuanto más temprano se descubran los fallos y errores, más económico será corregirlos, y menor será el impacto sobre la integridad del resto del código. Idealmente, debería comenzarse con las pruebas de seguridad en paralelo a la etapa de desarrollo. A efectos de detectar y corregir tempranamente posibles vulnerabilidades. 10.2 Revisiones de Código entre Pares. Se realiza en paralelo con las tareas de desarrollo. No se requiere una cobertura total del código. Se recomienda comenzar por los componentes más críticos de la aplicación. Esta práctica reduce drásticamente la cantidad de errores y fallos que permanecen en el código sin ser detectadas. Aumenta los niveles de comunicación entre miembros del equipo, ayuda a consolidar criterios de buenas prácticas e incrementa las habilidades programáticas individuales. Es preferible establecer una metodología estándar de corrección y validación de errores para todo el equipo. Se recomienda limitar los bloques de revisión a alrededor de 400 líneas de código y períodos de una hora. 10.3 Herramientas de escaneo estático. El análisis estático de un IDE, compilador, intérprete o herramienta especializada puede ofrecer una excelente medida para prevenir errores o fallos. Este tipo de herramientas complementa a las revisiones manuales para detectar errores sintácticos o que requieren seguir flujos de ejecución muy largos para ser interpretado por humanos. Las herramientas tienen la debilidad de ofrecer falsos positivos y falsos negativos. Es posible reconfigurar o ajustar las alertas para prevenir resultados falsos. Esta práctica no sustituye las revisiones manuales de código. 10.4 Pruebas de Penetración Se evalúa la seguridad del sistema desde la perspectiva de un atacante. Cumple la función de detectar vulnerabilidades que escaparon a todos los otros controles de seguridad anteriores. Por si sola, este tipo de pruebas no es suficiente para garantizar la seguridad de una aplicación. Corregir fallos detectados mediante pruebas de penetración, suele ser mucho menos económico que prevenirlos en etapas tempranas del ciclo de desarrollo. 10.5 Auditorías Manuales de Código Algunos fallos son difíciles de detectar con herramientas o pruebas de penetración, pero resultan evidentes al leer el código responsable. Este tipo de pruebas suele llamarse White-box o transparent-box. 10.6 Pruebas Tercerizadas y Confidencialidad En caso de que las pruebas sean realizadas por personal ajeno a la organización se recomienda documentar las condiciones de las actividades de prueba, definiendo: alcance, objetivos, tipos de pruebas y horarios IF-2021-76718462-APN-DNCIB#JGM Página 23 de 35