La pruebas de seguridad de aplicaciones de tipo estático, auditoría de código o static application security testing (SAST), se utilizan para proteger la seguridad del software y los sistemas donde este funciona, al revisar el código fuente del software para identificar el origen de las vulnerabilidades. Aunque las revisiones de código siempre han existido como parte del proceso de desarrollo de software desde su origen, esta práctica se introdujo en la seguridad a finales de la década de 1990. La primera discusión pública sobre una inyección SQL ocurrió en 1998, cuando las aplicaciones web integraron nuevas tecnologías como como JavaScript y Flash.
A diferencia de las herramientas de pruebas de seguridad de aplicaciones dinámicas (DAST), que habitualmente se utilizan para las pruebas de caja negra de las funciones de la aplicación y con ello su apariencia, las herramientas SAST se centran en el contenido del código de la aplicación, resultando habitualmente en la práctica por excelencia de las pruebas de caja blanca, que someten al las aplicaciones a una auditoría en mayor profundidad. Las herramientas SAST escanean el código fuente de una aplicación y sus componentes, identificando posibles vulnerabilidades de seguridad en su código y arquitectura. Las herramientas de análisis estático pueden detectar aproximadamente el 50% de las vulnerabilidades de seguridad existentes.
En desarrollo seguro S-SDLC, las pruebas SAST se ejecutan durante el proceso de desarrollo y sobre el código, también se ejecutan a lo largo de la fase de pruebas, como por ejemplo durante las pruebas de integración y las pruebas finales que cierran una versión del producto software. A continuación se expone un resumen de los pasos de una SAST.
1 – Realizar un recorrido por la aplicación
El objetivo es entender la aplicación, de forma suficiente: dependiendo del tiempo disponible para las pruebas pero también de la criticidad requerida, y de forma completa: dando una cobertura suficiente que no deje partes esenciales fuera. En este recorrido se cubre las diferentes funcionalidades de la aplicación (revisando el análisis funcional) y la forma de esta (análisis orgánico): diseño, arquitectura, despliegue, etc…
2 – Comunicación con los desarrolladores
Hablar con los desarrolladores, con el responsable de desarrollo, arquitecto, etc… Establecer un tiempo para realizar entrevistas y en general implicarte en el proyecto de desarrollo de software: cuanto más te vincules con el equipo de desarrollo y más se vinculen ellos con la ciberseguridad, mucho más efectivas serán tus pruebas SAST. Esto te ayudará:
- Identificar y priorizar cuales son los puntos de mayor riesgo.
- Entender cual es la lógica de los desarrolladores detrás de una particular funcionalidad.
- Establecer una relación de confianza y apreciación de trabajo mutuo. Respetando la complejidad y dificultades del contexto concreto del proyecto, y del desarrollo de software en general.
3 – Analizar el modelo de amenazas
Tener en cuenta el modelo de amenazas, para entender la forma y probabilidad de ocurrencia de estas, nos dispone a pensar en los mayores riesgos que afronta la aplicación y su exposición. Por supuesto el modelo de amenazas debe estar realizado, si no se dispone de el, puede dedicarse un poco de tiempo a tratar las más importantes.
4 – Definir objetivos de las pruebas
Habiendo entendido la aplicación y teniendo en cuenta el contexto de seguridad de esta y sus riesgos. Identificamos los objetivos de las pruebas:
- Revisión de código sobre las posibles vulnerabilidades más graves.
- Revisión de código sobre las vulnerabilidades señaladas en el top 10 de OWASP.
- Revisión de código sobre alguna posible vulnerabilidades particular de esa aplicación.
5 – Definir el alcance de la revisión
- Ser claro en que buscar principalmente y de que puede prescindirse.
- Calcular estimación de tiempo y esfuerzo requerido.
- Definir limitaciones, como por ejemplo de presupuesto.
6 – Llevar a cabo el análisis estático automático
- Dentro de lo posible, usar múltiples herramientas de análisis estático para combinar sus posibilidades.
- Revisar los resultados de vulnerabilidad y debilidad, identificando las más comunes.
Confirmar cuales son verdaderos positivos y diferenciarlos de los falsos positivos.
7 – Llevar a cabo el análisis estático manual
Inspeccionar el código del software línea a línea, identificando los puntos de mayor criticidad de este: autenticación, autorización, validación de datos de entrada, criptografía, exposición de información, etc…
8 – Identificar y adaptar los cambios necesarios, recomendaciones
Identificar las buenas prácticas, del entorno tecnológico y los cambios necesarios para dar respuesta a las vulnerabilidades descubiertas. Teniendo en cuenta en la medida de lo posible el contexto del proyecto y adaptando a este las recomendaciones habitualmente muy genéricas, señaladas por las herramientas automáticas y los proveedores de tecnología.
9 – Redacción de los entregables
Describir en detalle las vulnerabilidades encontradas y la solución propuesta, además realizar un extracto ejecutivo a modo de resumen, que ofrezca visibilidad de forma clara a cualquier persona independientemente de sus conocimientos técnicos previos.
