Análisis estático vs dinámico
El análisis estático lee código; el análisis dinámico lo ejecuta. Un analizador estático convierte un archivo en un árbol de sintaxis abstracta (AST) y comprueba esa estructura contra reglas — sin servidor, sin datos de prueba, sin entorno de ejecución necesario, por lo que puede ejecutarse en segundos contra un código que nunca se ha desplegado. El análisis dinámico (pruebas, fuzzers, escáneres DAST) observa el comportamiento real en runtime — qué devuelve una función para una entrada dada, cómo responde un servidor en marcha a una petición fabricada — algo que el análisis estático no puede ver por definición, ya que nada se ejecuta. Ninguno reemplaza al otro; responden preguntas distintas.
Qué comprueba realmente el análisis estático — más allá de la seguridad
La seguridad domina el marketing, pero el análisis estático es una técnica general para comprobar cualquier propiedad estructural del código. Las 708 reglas de StaticCodeAudit abarcan estas categorías:
Seguridad
Inyección SQL, XSS, SSRF, path traversal, secretos hardcodeados, deserialización insegura, criptografía débil, inyección de comandos, inyección LDAP, cookies inseguras, patrones de cumplimiento RGPD.
Arquitectura
Protección de rutas de administración, lógica de base de datos incrustada en routers, consultas directas sin parametrizar, patrones de consulta N+1, archivos sobredimensionados.
Interfaz / UI
Estilos inline, uso manual de createElement, fugas de event listeners, manipulación del DOM dentro de bucles.
Accesibilidad / UX
Etiquetas ARIA faltantes, texto alternativo faltante, gestión del foco, mal uso del autoplay, problemas de i18n, patrones toast/notificación, llamadas console.log residuales.
Mantenimiento
Marcadores TODO/FIXME/HACK/XXX sin resolver, APIs obsoletas, manejo de excepciones genérico, sentencias de depuración, supresores de errores.
Dependencias
Escaneo de CVEs conocidas contra paquetes instalados (equivalentes a pip-audit, npm audit), rangos de versión sin fijar, cumplimiento de licencias.
CI/CD
Configuración incorrecta de GitHub Actions y GitLab CI, inyección de expresiones, permisos de workflow excesivos, actions de terceros sin fijar.
Cómo se mapean los hallazgos a estándares publicados
Un hallazgo sin referencia a un estándar es solo una opinión. StaticCodeAudit etiqueta cada regla con al menos un identificador CWE (la taxonomía de debilidades de MITRE) o un criterio de éxito WCAG 2.1, y superpone mapeos OWASP Top 10, ISO/IEC 27001 Anexo A, OWASP ASVS v5.0 y NIST CSF 2.0 donde aplica — para que un hallazgo sea trazable a una referencia externa y auditable en lugar de una etiqueta de severidad inventada por el proveedor.
Ver la cobertura completa de estándares →Preguntas frecuentes
¿El análisis estático de código es lo mismo que SAST?
SAST (Static Application Security Testing) es análisis estático limitado específicamente a vulnerabilidades de seguridad. El análisis estático de código es la técnica más amplia — el mismo mecanismo de parsing y coincidencia de reglas se aplica a arquitectura, accesibilidad, mantenibilidad y comprobaciones de dependencias, no solo a vulnerabilidades explotables. Vea la guía dedicada a SAST para el caso de uso específico de seguridad.
¿Puede el análisis estático detectar bugs que solo aparecen en runtime?
No directamente — cualquier cosa que dependa de valores de entrada reales, timing, o estado del entorno en runtime está fuera de lo que el análisis estático puede observar por definición. El análisis de taint reduce esta brecha rastreando cómo podrían fluir datos no confiables a través del código sin ejecutarlo, pero es inferencia, no observación. Para eso están las pruebas dinámicas.
¿Por qué StaticCodeAudit cubre UI y accesibilidad, no solo seguridad?
Porque la técnica subyacente — analizar el código, comprobar la estructura contra reglas — se aplica igual de bien a una etiqueta ARIA faltante o un estilo inline que a un patrón de inyección SQL. La accesibilidad específicamente también tiene un peso regulatorio creciente (la European Accessibility Act 2025, por ejemplo), por lo que el mapeo WCAG 2.1 va junto al mapeo CWE en lugar de ser un producto separado.
¿Cómo evita el análisis estático los falsos positivos?
No los evita del todo — ningún analizador estático lo hace, ya que razona sobre la estructura del código sin contexto de runtime completo. Lo que varía enormemente entre herramientas es la tasa de falsos positivos, que depende del diseño de las reglas (las reglas solo de patrón son más ruidosas que las de taint tracking) y de lo conservadora que sea la definición de una regla. Pida un benchmark publicado y reproducible en lugar de una cifra autoinformada por el proveedor — vea benchmarks reales de precisión/recall.
¿El análisis estático necesita que el código compile?
Depende de la herramienta. Algunos motores requieren una compilación completa para construir una base de datos consultable (común para análisis semántico profundo de lenguajes compilados). StaticCodeAudit no — analiza los archivos fuente directamente sin paso de compilación, para cualquiera de sus 8 lenguajes soportados, incluidos los compilados como Java y C#.
Vea cómo luce un análisis estático de espectro completo
Abra el informe demo en vivo — hallazgos de seguridad, arquitectura, UI, accesibilidad, mantenimiento, dependencias y CI/CD, todo en un solo archivo HTML.
Abrir el informe en vivo Ver el mapeo a estándares