SAST: qué es, cómo funciona y cómo implementarlo

SAST es una forma de revisar la seguridad del software antes de ejecutar la aplicación.

Analiza código fuente, bytecode o binarios para identificar patrones que pueden convertirse en vulnerabilidades: entradas que llegan a operaciones peligrosas, secretos incrustados, funciones criptográficas débiles, validaciones incompletas o rutas de autorización que requieren revisión.

El escáner ayuda a encontrar señales. No decide por sí solo si existe un riesgo explotable, cuánto afecta al negocio ni cuál es la corrección adecuada. Para que SAST funcione, cada alerta necesita contexto técnico, un responsable, una decisión y una nueva validación.

Esta guía explica qué puede aportar SAST, qué no cubre y cómo integrarlo a un pipeline CI/CD sin convertirlo en una fuente interminable de ruido.

Qué es SAST

SAST significa Static Application Security Testing, traducido como pruebas estáticas de seguridad de aplicaciones.

La palabra estáticas indica que el análisis ocurre sin levantar la aplicación como lo haría un usuario. La herramienta examina representaciones del software y aplica reglas, análisis de flujo de datos, seguimiento de llamadas u otras técnicas para localizar condiciones riesgosas.

Dependiendo de la herramienta y el lenguaje, puede trabajar sobre:

• código fuente;
• bytecode o código intermedio;
• binarios compilados;
• cambios dentro de un pull request;
• repositorios completos;
• reglas personalizadas para patrones propios de la organización.

OWASP incluye las herramientas de análisis de código dentro de SAST y señala que pueden integrarse al IDE o ejecutarse repetidamente durante el desarrollo. NIST, dentro del Secure Software Development Framework, también contempla el análisis estático y otras técnicas para encontrar problemas de seguridad temprano.

SAST no es una compra aislada. Es una práctica dentro del ciclo de desarrollo seguro.

Qué vulnerabilidades puede detectar

La cobertura real depende del lenguaje, el framework, las reglas y la capacidad de la herramienta para comprender el flujo del programa. No todos los escáneres detectan lo mismo.

Un análisis bien configurado puede señalar:

• datos controlados por el usuario que llegan a consultas, comandos o plantillas sin una protección visible;
• secretos, tokens o credenciales escritos directamente en el código;
• funciones criptográficas o algoritmos obsoletos;
• rutas de archivos construidas con entradas no confiables;
• validaciones o controles de acceso inconsistentes;
• uso de APIs peligrosas;
• serialización, manejo de errores o registros que pueden exponer información;
• patrones inseguros repetidos entre módulos;
• correcciones anteriores que vuelven a introducirse.

La herramienta suele aportar archivo, línea, regla y una trayectoria aproximada entre origen y destino. Esa evidencia reduce el tiempo de búsqueda, pero debe revisarse contra el comportamiento real del sistema.

Una alerta por inyección, por ejemplo, puede ser válida si una entrada llega sin protección a una consulta. También puede resultar falsa si existe una validación que el motor no comprende. El resultado correcto no es aceptar ni descartar automáticamente: es comprobar el flujo.

Qué no puede detectar por sí solo

SAST tiene puntos ciegos importantes.

No observa directamente:

• la configuración efectiva del servidor o la nube;
• encabezados, sesiones y comportamiento HTTP en ejecución;
• permisos otorgados fuera del código;
• combinaciones de servicios que crean una exposición;
• datos reales, identidades y decisiones operativas;
• vulnerabilidades conocidas dentro de dependencias, si no incluye una capacidad SCA;
• abuso de lógica de negocio que requiere entender el proceso;
• una cadena completa de ataque y su impacto práctico.

También puede perder problemas cuando usa reglas incompletas, analiza sólo una parte del repositorio o no entiende código generado, metaprogramación, frameworks nuevos o controles internos.

Por eso SAST no demuestra que una aplicación sea segura. Demuestra que se aplicó un tipo de revisión sobre un alcance y una versión específicos.

SAST, SCA, DAST, revisión manual y pentest

Cada técnica responde una pregunta distinta.

Si necesitas profundizar en las dos pruebas automatizadas, revisa SAST vs DAST: diferencias en desarrollo seguro.

Cómo funciona un pipeline SAST práctico

Un solo escaneo al final del proyecto entrega resultados tarde. Un flujo útil combina retroalimentación rápida para cambios nuevos con análisis más profundos y programados.

El flujo recomendado separa dos carriles:

1. Análisis rápido del cambio. Revisa el pull request, muestra hallazgos nuevos y entrega retroalimentación cuando el desarrollador todavía conoce el contexto.
2. Análisis profundo programado. Revisa una superficie mayor para encontrar problemas que requieren más tiempo, reglas o capacidad de cómputo.

Ambos carriles llegan al mismo proceso de triage. Ahí se decide si el hallazgo es válido, cuál es su riesgo, quién lo corrige y qué evidencia se necesita para cerrarlo.

Cómo implementar SAST paso a paso

1. Define el objetivo y el alcance

Empieza por una aplicación o conjunto de repositorios que puedas comprender.

Documenta:

• lenguajes, frameworks y versiones;
• repositorios, ramas y componentes incluidos;
• módulos que manejan autenticación, permisos, pagos o datos sensibles;
• pipeline, frecuencia de cambios y tiempo máximo aceptable para cada análisis;
• responsables de desarrollo, seguridad y aprobación de excepciones;
• evidencia que debe conservarse.

El objetivo inicial no debería ser “encontrar todo”. Puede ser evitar nuevas vulnerabilidades graves en una API crítica o incorporar retroalimentación de seguridad en los pull requests.

2. Ejecuta una línea base sin bloquear

El primer análisis puede descubrir cientos o miles de alertas históricas. Bloquear el pipeline con toda esa deuda provoca que el equipo desactive la herramienta o apruebe excepciones sin revisar.

Durante la línea base:

• agrupa hallazgos por regla, módulo y severidad;
• revisa una muestra para medir precisión;
• identifica reglas que generan ruido;
• separa problemas existentes de hallazgos introducidos por cambios nuevos;
• crea un backlog para la deuda real;
• fija una fecha y un responsable para revisar excepciones.

La línea base permite aplicar una regla sencilla: no agregar riesgo nuevo mientras se reduce la deuda existente por prioridad.

3. Calibra reglas con el contexto del proyecto

No habilites todas las reglas sólo porque existen.

Prioriza las que corresponden a:

• los lenguajes y frameworks usados;
• las rutas donde entran datos;
• los controles de autenticación y autorización;
• los módulos con información sensible;
• las clases de vulnerabilidad ya observadas;
• los requisitos técnicos acordados para el proyecto.

Si una regla produce falsos positivos recurrentes, investiga la causa. Puede requerir configuración, una regla personalizada o una mejora en el patrón de código para que el control sea más claro.

4. Define umbrales por riesgo

La severidad del proveedor no basta. Combínala con el contexto.

Un hallazgo aumenta de prioridad cuando:

• se encuentra en código accesible desde internet;
• afecta autenticación, autorización o aislamiento entre clientes;
• expone secretos o datos sensibles;
• permite llegar a una operación peligrosa;
• aparece en un cambio que está por liberarse;
• repite una vulnerabilidad corregida anteriormente;
• tiene una ruta de explotación comprensible y pocas defensas compensatorias.

Un hallazgo puede bajar de prioridad cuando el código no es alcanzable, el flujo está protegido por un control verificable o la regla no corresponde al lenguaje y contexto. La decisión debe documentarse.

5. Asigna responsables y tiempos

El equipo de desarrollo normalmente corrige el código. Una función de seguridad, AppSec o revisión técnica ayuda a calibrar reglas, validar casos ambiguos y definir criterios.

Cada hallazgo aceptado debería tener:

• propietario;
• severidad ajustada al contexto;
• fecha objetivo;
• versión o rama afectada;
• corrección propuesta;
• evidencia de nueva validación;
• justificación y vencimiento si se acepta temporalmente.

Sin responsables, SAST se convierte en un tablero de alertas.

6. Verifica la corrección

Cerrar el ticket no basta.

La verificación puede incluir:

1. revisar el cambio de código;
2. ejecutar nuevamente la regla SAST;
3. añadir una prueba para evitar regresión;
4. confirmar que no se movió el problema a otra ruta;
5. usar DAST, revisión manual o pentest cuando el riesgo lo justifique;
6. registrar evidencia del resultado.

La meta es demostrar que el riesgo cambió, no sólo que desapareció una alerta.

Cómo priorizar un hallazgo SAST

Un triage consistente evita discusiones basadas únicamente en colores del escáner.

Para los módulos críticos, conserva la decisión junto con el pull request o el sistema de seguimiento. Así una excepción deja de ser conocimiento informal.

Cómo reducir falsos positivos sin ocultar riesgo

Los falsos positivos no se resuelven desactivando el escáner completo.

Usa este orden:

1. confirma que el análisis usa el lenguaje, framework y modo correctos;
2. revisa si falta información de compilación o dependencias;
3. reproduce el flujo señalado;
4. ajusta la regla o agrega una regla personalizada;
5. suprime únicamente la instancia necesaria;
6. escribe la justificación;
7. asigna responsable y fecha de revisión;
8. mide qué reglas producen más ruido.

Una supresión permanente sin explicación puede ocultar una vulnerabilidad futura en la misma línea. Una excepción con alcance, evidencia y vencimiento es revisable.

Qué debe bloquear el pipeline

No existe un umbral universal, pero una política inicial razonable puede bloquear:

• hallazgos nuevos de alta criticidad confirmados;
• secretos válidos introducidos en el cambio;
• flujos peligrosos en autenticación, autorización o aislamiento de datos;
• reaparición de una vulnerabilidad que ya se había corregido;
• incumplimientos de una regla interna obligatoria para un módulo sensible.

Normalmente conviene advertir, pero no bloquear automáticamente:

• alertas históricas incluidas en la línea base;
• hallazgos de baja confianza;
• recomendaciones de estilo;
• reglas nuevas que todavía no fueron calibradas;
• casos donde la herramienta no comprende un control compensatorio.

El proceso de excepción debe identificar quién decide, por cuánto tiempo y con qué mitigación temporal.

Métricas que sí ayudan

Contar todas las alertas abiertas puede castigar a los equipos que analizan más código y premiar a quienes escanean menos.

Mide mejor:

• hallazgos nuevos por cambio o periodo;
• tiempo medio de triage;
• tiempo de corrección por severidad;
• porcentaje de hallazgos reabiertos;
• vulnerabilidades reintroducidas;
• cobertura de repositorios y ramas relevantes;
• reglas con mayor proporción de falsos positivos;
• excepciones activas, vencidas y renovadas;
• correcciones acompañadas por una prueba de regresión;
• causas raíz repetidas que requieren capacitación o componentes seguros reutilizables.

Las métricas deben servir para mejorar el proceso, no para comparar desarrolladores por cantidad de alertas.

Cómo elegir una herramienta SAST

Antes de comparar marcas, prepara una prueba sobre código representativo.

Evalúa:

• soporte real para tus lenguajes, frameworks y sistema de construcción;
• precisión sobre rutas críticas del proyecto;
• análisis de cambios para pull requests;
• integración con IDE, repositorio y pipeline;
• tiempo de ejecución y opciones para análisis incremental;
• capacidad de crear o ajustar reglas;
• explicación del flujo y evidencia para el desarrollador;
• administración de línea base, supresiones y excepciones;
• controles de acceso y tratamiento del código si el servicio es externo;
• exportación de resultados y trazabilidad de remediación;
• costo por repositorio, contribuidor, línea o modalidad de ejecución.

Una demostración sobre un proyecto genérico no prueba que la herramienta entienda tu arquitectura. La evaluación debe incluir casos verdaderos, falsos positivos conocidos y un pull request reciente.

Plan de adopción en 30, 60 y 90 días

Primeros 30 días: visibilidad

• seleccionar uno o dos repositorios;
• ejecutar la línea base;
• revisar reglas de mayor riesgo;
• identificar propietarios;
• documentar el flujo de triage;
• mantener el pipeline en modo informativo.

Días 31 a 60: calibración

• ajustar reglas y severidades;
• separar cambios nuevos de deuda histórica;
• integrar comentarios en pull requests;
• definir excepciones con vencimiento;
• corregir una primera tanda de hallazgos;
• medir precisión y tiempos.

Días 61 a 90: control

• bloquear hallazgos nuevos, graves y confirmados;
• ejecutar análisis profundos programados;
• revisar excepciones;
• conectar SAST con SCA, pruebas y revisión manual;
• presentar métricas de remediación;
• extender el modelo a otros repositorios sólo cuando el flujo sea sostenible.

Este orden favorece adopción y aprendizaje antes de convertir la herramienta en una puerta obligatoria.

Cuándo combinar SAST con otras pruebas

Combina SAST con SCA para revisar dependencias y componentes. Agrega DAST cuando exista un entorno ejecutable y necesites observar autenticación, sesiones, encabezados o comportamiento externo.

Usa revisión manual y modelado de amenazas cuando el cambio afecta:

• autorización y roles;
• aislamiento entre clientes;
• pagos y movimientos sensibles;
• cifrado y gestión de llaves;
• integraciones con terceros;
• flujos donde una decisión de negocio puede abusarse.

Considera un pentest antes de una liberación importante, después de cambios de alto impacto o cuando necesitas validar encadenamiento e impacto en un alcance autorizado.

Ninguna de estas técnicas reemplaza a las demás. La cobertura mejora cuando cada una responde una pregunta concreta.

Cómo puede ayudarte Syscore

Syscore puede revisar el contexto del proyecto, seleccionar un alcance inicial y ayudarte a integrar criterios de desarrollo seguro sin prometer que una herramienta eliminará todo el riesgo.

El trabajo puede incluir:

• revisión de repositorios, lenguajes y pipeline;
• definición de reglas y umbrales;
• línea base y triage inicial;
• criterios para pull requests;
• integración con SCA, pruebas y revisión manual;
• seguimiento de remediaciones;
• evidencia para una liberación o revisión técnica.

Puedes comenzar por desarrollo de software, revisar nuestras buenas prácticas de desarrollo seguro o compartir el contexto del proyecto desde contacto.

Preguntas frecuentes

¿Qué significa SAST?

SAST significa Static Application Security Testing. Analiza código fuente, bytecode o binarios sin ejecutar la aplicación para identificar patrones que pueden representar vulnerabilidades.

¿SAST reemplaza un pentest?

No. SAST encuentra ciertos patrones dentro del código. Un pentest valida escenarios de ataque e impacto sobre una aplicación y un alcance definidos. También conviene combinar SAST con revisión manual, SCA y DAST.

¿Cuál es la diferencia entre SAST y SCA?

SAST analiza el código propio y sus flujos. SCA identifica componentes y dependencias de terceros, sus versiones, licencias y vulnerabilidades conocidas. Son controles complementarios.

¿Cada cuánto debe ejecutarse SAST?

Conviene ejecutar un análisis rápido en pull requests o cambios relevantes y otro más profundo de forma programada. La frecuencia depende del tamaño del proyecto, el tiempo del escaneo y la criticidad del software.

¿SAST debe bloquear el pipeline?

Puede bloquear hallazgos nuevos, graves y confirmados en componentes sensibles. No conviene bloquear de inmediato toda la deuda histórica ni alertas sin contexto; primero necesitas una línea base, calibración y un proceso de excepción.

Fuentes consultadas

• OWASP: Source Code Analysis Tools, descripción de SAST, fortalezas, debilidades e integración durante desarrollo.
• OWASP DevSecOps Guideline: Static Application Security Testing, contexto de análisis estático dentro de un flujo DevSecOps.
• NIST Secure Software Development Framework, prácticas para integrar seguridad, verificación y respuesta a vulnerabilidades dentro del desarrollo.

Enlaces útiles

• SAST vs DAST: diferencias
• 12 buenas prácticas de desarrollo seguro
• OWASP para reducir riesgos de software
• Desarrollo seguro con IA
• Desarrollo de software
• Pruebas de penetración