Volver al glosario

SAST

2 min de lectura

En seguridad de aplicaciones, SAST es el análisis estático de seguridad de aplicaciones: analizar el código fuente, el bytecode o los binarios en busca de vulnerabilidades sin ejecutar el software. Lee el código como lo hace un compilador, sigue cómo se mueven los datos desde donde entran hasta donde se usan, e informa de los caminos que parecen inseguros.

29 de julio de 2026
Compartir:

Cómo funciona

El analizador convierte el código en un árbol sintáctico, construye grafos de flujo de control y de flujo de datos, y después sigue los valores contaminados desde las fuentes, como el parámetro de una petición, hasta los sumideros, como un constructor de consultas o una llamada al shell, comprobando si hay un saneador en el camino. Encima de eso aplica reglas de patrón para lo que no necesita flujo de datos ninguno: un secreto escrito a fuego, una comprobación de certificado desactivada, la elección de un cifrado débil.

Su ventaja estructural son la cobertura y el momento. Ve caminos de código difíciles de alcanzar en ejecución, incluidos los manejadores de error y las rutas sin usar, corre en cada commit, y señala la línea exacta, que es lo que hace barato arreglar un hallazgo.

Qué sale mal

Dos límites, y los dos merecen constar en un informe porque son lo que justifica el trabajo posterior. El primero es que el análisis estático razona sobre el código, no sobre la intención, así que hay una clase entera de defectos que le resulta invisible: si este usuario debería poder leer este registro no es una propiedad del código fuente. Los fallos de lógica de negocio y la mayoría de los fallos de autorización caen en ese hueco.

El segundo es que no sabe qué hay desplegado. No ve un proxy inverso permisivo, una marca de depuración activada en el entorno, una versión antigua del servicio que sigue en marcha, ni una dependencia que se resuelve al construir, y por eso se empareja con el análisis de composición de software, y no se espera que lo sustituya.

En la operación, el fallo es el ruido. Una herramienta ajustada para no perderse nada produce suficientes falsos positivos como para que los equipos dejen de leerla, y una regla silenciada se queda silenciada durante años. La medida de un despliegue útil no es cuántos hallazgos levanta, sino cuántos levanta que alguien haya arreglado.

Dónde aparece esto en una auditoría

Cuando un cliente tiene análisis estático en su tubería le pedimos la salida, y la usamos como mapa y no como resultado: enseña qué partes del código se han mirado y qué reglas están apagadas. Los hallazgos que confirmamos de forma dinámica se informan como confirmados; los que la herramienta levantó y no son alcanzables se informan como tales, porque cerrarlos le cuesta dinero al cliente para nada. Comparada con el DAST, esta mitad de la pareja lo ve todo y no demuestra nada, que es justo por lo que existen las dos. Esto forma parte de dónde se acaba el análisis automático y dónde empieza la prueba manual.

¿Quieres ver cómo trabajamos en Asperis Security?

Agenda 30 minutos con uno de nuestros especialistas. Revisamos tu stack y te decimos qué conviene probar primero.