Las pruebas de seguridad de aplicaciones estáticas ( SAST ) se utilizan para proteger el software revisando el código fuente del software para identificar fuentes de vulnerabilidades. Aunque el proceso de análisis estático del código fuente ha existido desde que existen las computadoras, la técnica se extendió a la seguridad a finales de los 90 y la primera discusión pública sobre la inyección SQL fue en 1998, cuando las aplicaciones web integraron nuevas tecnologías como JavaScript y Flash .
A diferencia de las herramientas de prueba dinámica de seguridad de aplicaciones (DAST) para pruebas de caja negra de la funcionalidad de la aplicación, las herramientas SAST se centran en el contenido del código de la aplicación, las pruebas de caja blanca . Una herramienta SAST escanea el código fuente de las aplicaciones y sus componentes para identificar posibles vulnerabilidades de seguridad en su software y arquitectura. Las herramientas de análisis estático pueden detectar aproximadamente el 50% de las vulnerabilidades de seguridad existentes. [1]
En el ciclo de vida de desarrollo de software (SDLC), SAST se realiza temprano en el proceso de desarrollo y a nivel de código, y también cuando todas las piezas de código y componentes se reúnen en un entorno de prueba consistente. SAST también se utiliza para garantizar la calidad del software, [2] incluso si los numerosos falsos positivos resultantes impiden su adopción por parte de los desarrolladores [3]
Las herramientas SAST están integradas en el proceso de desarrollo para ayudar a los equipos de desarrollo, ya que se centran principalmente en desarrollar y entregar software respetando las especificaciones solicitadas. [4] Las herramientas SAST, al igual que otras herramientas de seguridad, se centran en reducir el riesgo de tiempo de inactividad de las aplicaciones o que la información privada almacenada en las aplicaciones no se vea comprometida.
Para el año 2018, la base de datos de Privacy Rights Clearinghouse [5] muestra que más de 612 millones de registros han sido comprometidos por piratería.
Pruebas de seguridad de las aplicaciones en su lanzamiento: pruebas de seguridad de aplicaciones estáticas (SAST), pruebas de seguridad de aplicaciones dinámicas (DAST) y pruebas de seguridad de aplicaciones interactivas (IAST), una combinación de las dos. [6]
Las herramientas de análisis estático examinan sintácticamente el texto de un programa. Buscan un conjunto fijo de patrones o reglas en el código fuente. En teoría, también pueden examinar una versión compilada del software. Esta técnica se basa en la instrumentación del código para realizar el mapeo entre los componentes compilados y los componentes del código fuente para identificar problemas. El análisis estático se puede realizar manualmente como revisión o auditoría del código para diferentes propósitos, incluida la seguridad, pero requiere mucho tiempo. [7]
La precisión de la herramienta SAST está determinada por su alcance de análisis y las técnicas específicas utilizadas para identificar vulnerabilidades. Los diferentes niveles de análisis incluyen:
El alcance del análisis determina su precisión y capacidad para detectar vulnerabilidades utilizando información contextual. [8] Las herramientas SAST, a diferencia de DAST, brindan a los desarrolladores comentarios en tiempo real y les ayudan a proteger las fallas antes de pasar el código al siguiente nivel.
A nivel de función, una técnica común es la construcción de un árbol de sintaxis abstracta para controlar el flujo de datos dentro de la función. [9]
Desde finales de los 90, la necesidad de adaptarse a los desafíos empresariales ha transformado el desarrollo de software con la componenteización [10] impuesta por procesos y organización de equipos de desarrollo. [11] Seguir el flujo de datos entre todos los componentes de una aplicación o grupo de aplicaciones permite validar las llamadas requeridas a procedimientos dedicados para la desinfección y que se tomen las acciones adecuadas para contaminar los datos en fragmentos de código específicos. [12] [13]
El auge de las aplicaciones web implicó probarlas: Verizon Data Breach informó en 2016 que el 40% de todas las filtraciones de datos utilizan vulnerabilidades de las aplicaciones web. [14] Además de las validaciones de seguridad externas, cada vez se presta más atención a las amenazas internas. El Clearswift Insider Threat Index (CITI) informó que el 92% de los encuestados en una encuesta de 2015 dijeron que habían experimentado incidentes de seguridad o de TI en los 12 meses anteriores y que el 74% de estas violaciones fueron originadas por personas internas. [15] [16] Lee Hadlington clasificó las amenazas internas en 3 categorías: maliciosas, accidentales y no intencionales. El crecimiento explosivo de las aplicaciones móviles implica proteger las aplicaciones en una etapa más temprana del proceso de desarrollo para reducir el desarrollo de códigos maliciosos. [17]
Cuanto antes se solucione una vulnerabilidad en el SDLC, más barato será solucionarla. Los costos de reparación en desarrollo son 10 veces menores que en pruebas y 100 veces menores que en producción. [18] Las herramientas SAST se ejecutan automáticamente, ya sea a nivel de código o de aplicación, y no requieren interacción. Cuando se integran en un contexto de CI/CD, las herramientas SAST se pueden utilizar para detener automáticamente el proceso de integración si se identifican vulnerabilidades críticas. [19]
Debido a que la herramienta escanea todo el código fuente, puede cubrir el 100% del mismo, mientras que las pruebas dinámicas de seguridad de la aplicación cubren su ejecución, posiblemente faltando parte de la aplicación, [6] o configuración no segura en archivos de configuración.
Las herramientas SAST pueden ofrecer funcionalidades ampliadas, como pruebas de calidad y arquitectura. Existe una correlación directa entre la calidad y la seguridad. El software de mala calidad también es software mal protegido. [20]
Aunque los desarrolladores son positivos sobre el uso de herramientas SAST, existen diferentes desafíos para la adopción de herramientas SAST por parte de los desarrolladores. [4] La usabilidad de los resultados generados por estas herramientas puede cuestionar hasta qué punto los desarrolladores pueden hacer uso de estas herramientas. Las investigaciones muestran que, a pesar del largo tiempo que generan estas herramientas, es posible que carezcan de usabilidad. [21]
Con Agile Processes en el desarrollo de software, la integración temprana de SAST genera muchos errores, ya que los desarrolladores que utilizan este marco se centran primero en las características y la entrega. [22]
Escanear muchas líneas de código con herramientas SAST puede generar cientos o miles de advertencias de vulnerabilidad para una sola aplicación. Puede generar muchos falsos positivos, aumentando el tiempo de investigación y reduciendo la confianza en dichas herramientas. Este es particularmente el caso cuando la herramienta no puede captar el contexto de la vulnerabilidad. [3]