Qué hace realmente SAST
Un motor SAST analiza los archivos fuente en un árbol de sintaxis abstracta (AST), y luego aplica reglas sobre ese árbol: coincidencias de patrones para llamadas a funciones conocidas como peligrosas, taint tracking que sigue un valor desde una fuente no confiable (un parámetro de petición, un campo de formulario) hasta un sink peligroso (una consulta SQL, un comando de shell, una ruta de archivo), y en motores más avanzados, dataflow cross-file que conecta una fuente en un archivo con un sink en otro. Nada se ejecuta. Esto es lo que hace utilizable el SAST antes de que exista un solo entorno de pruebas — funciona en un portátil, en un job de CI, o contra un código que nunca se ha desplegado.
SAST vs DAST vs IAST vs SCA
Estos cuatro acrónimos se usan indistintamente en el marketing de los proveedores. Prueban cosas distintas, en momentos distintos, y ninguno sustituye a los demás.
| Categoría | Cuándo se ejecuta | Qué encuentra |
|---|---|---|
| SAST | Antes de compilar — sobre el código fuente | Patrones de vulnerabilidad en el código: inyección, secretos hardcodeados, criptografía insegura, deserialización insegura. |
| DAST | Contra una aplicación en ejecución | Comportamiento en runtime: cómo responde realmente la app a peticiones HTTP fabricadas, bypass de autenticación, cabeceras mal configuradas. |
| IAST | Durante la ejecución de pruebas, instrumentado | Un híbrido — observa rutas de código reales mientras se ejecutan las pruebas, combinando visibilidad del código fuente con confirmación en runtime. |
| SCA | Contra el árbol de dependencias | CVEs conocidas en bibliotecas de terceros — no su código, código que importó. |
Un programa de seguridad maduro combina más de una de estas capas. SAST suele ser la primera porque se ejecuta más pronto — antes de que haya nada que desplegar o atacar.
Qué debería cubrir realmente una herramienta SAST
No todos los escáneres que se llaman «SAST» cubren el mismo terreno. Una checklist corta y concreta:
- ✅ Mapeo a estándares — hallazgos etiquetados con CWE como mínimo; mapeo OWASP Top 10, ISO 27001, ASVS o NIST CSF si necesita evidencia de cumplimiento, no solo una etiqueta de severidad.
- ✅ Cobertura de lenguajes que coincide con su stack — una herramienta que cubre 30 lenguajes pero no el que usted realmente usa cubre cero de su código.
- ✅ Una tasa de falsos positivos suficientemente baja para ser utilizable — un escáner que inunda el triaje de ruido termina ignorado en menos de un mes, sea cual sea su número bruto de hallazgos.
- ✅ Un informe que alguien fuera del equipo de seguridad pueda leer — un volcado JSON sirve para el gating de CI, inútil para entregar a un auditor o a un cliente.
- ✅ Integración CI/CD — exportación SARIF, códigos de salida, o una Action/paso de pipeline nativo, para que el escaneo no sea un paso manual que alguien olvida.
- ✅ Una respuesta clara a «adónde va mi código» — SAST con subida a la nube y SAST sin conexión son perfiles de riesgo distintos, no una nota a pie de página. Vea qué significa realmente el SAST sin conexión.
Dónde encaja StaticCodeAudit
StaticCodeAudit es un SAST curado y sin conexión: un binario independiente que escanea 8 lenguajes (Python, JavaScript/TypeScript, HTML, Java, C#, PHP, YAML, Dockerfile) con 708 reglas, todas mapeadas al menos a CWE, con matrices ISO 27001 Anexo A, OWASP ASVS v5.0, WCAG 2.1 y NIST CSF 2.0 integradas — no ensambladas después. Nunca sube el código fuente a ningún sitio; todo el escaneo se ejecuta en la máquina que ejecuta el binario.
Preguntas frecuentes
¿SAST reemplaza la revisión manual de código o el pentesting?
No. SAST es rápido, repetible, y detecta clases de patrones conocidos a gran escala — no detectará un fallo de lógica de negocio que un revisor humano vería ("esta API permite a cualquier usuario cancelar el pedido de otro"), y no confirma la explotabilidad como sí lo hace un pentest contra un sistema en marcha. Es una capa, normalmente la primera y la más barata de implementar.
¿Cuántos falsos positivos debo esperar?
Depende enteramente del motor y del diseño de las reglas — no hay un número universal, y cualquier proveedor que cite uno sin un benchmark nombrado está adivinando. Pida un benchmark publicado y reproducible (OWASP Benchmark, NIST Juliet, o similar) con precisión/recall/F1 por categoría, no una cifra agregada única de «precisión». Vea cómo se mide esto en la página de benchmarks de lenguajes.
¿Un linter es lo mismo que SAST?
No, aunque se solapan en el mecanismo. Un linter (ESLint, Pylint, RuboCop) principalmente comprueba estilo y bugs básicos de corrección. Las reglas SAST apuntan específicamente a clases de vulnerabilidades explotables — inyección, deserialización, secretos hardcodeados, debilidades criptográficas — y generalmente se mapean a CWE para que los hallazgos sean trazables a una taxonomía de debilidades conocida.
¿SAST necesita acceso a internet para funcionar?
No inherentemente — es una decisión de despliegue del proveedor, no un requisito del análisis estático en sí. Los productos SAST en la nube suben su código fuente para ejecutar el análisis remotamente; los productos SAST sin conexión ejecutan todo el análisis, incluida la evaluación de reglas, en su propia máquina. Vea qué significa realmente el SAST sin conexión y cómo verificarlo.
¿Qué significa realmente «708 reglas» en la práctica?
Significa 708 patrones de detección mantenidos individualmente, cada uno mapeado a al menos un CWE, abarcando categorías como seguridad (inyección, secretos, criptografía), arquitectura, dependencias, configuración de pipeline CI/CD, y más. La cifra por sí sola dice poco sin conocer el mapeo y la tasa de detección medida por regla — por eso StaticCodeAudit publica tanto el mapeo completo a estándares como benchmarks reales de precisión/recall en lugar de solo el recuento.
Vea un informe SAST real, no una maqueta
Abra el informe demo en vivo — generado sobre un código real, todos los gráficos interactivos, mapeo CWE/ISO/ASVS/WCAG completo incluido.
Abrir el informe en vivo Leer la guía de SAST sin conexión