¿Qué es el análisis de código estático?

También conocido como análisis de código fuente, el análisis de código estático identifica errores lógicos y fugas de memoria antes de que se ejecuten las aplicaciones, lo que reduce el tiempo de depuración. Busca automáticamente errores de sintaxis y vulnerabilidades de seguridad ocultas que los humanos podrían pasar por alto. Refuerza los estándares de programación y ayuda a garantizar el cumplimiento normativo en equipos grandes y, en general, acelera el desarrollo en general.

El análisis de código estático, a diferencia del análisis de código dinámico, ocurre antes de que se ejecute el código. El análisis dinámico implica ejecutar la aplicación y observar su comportamiento. Por el contrario, el análisis estático trata el código fuente como un conjunto de datos estructurales, que escanea para identificar problemas antes de que la aplicación se compile, empaquete o despliegue. Este enfoque modela cómo se comportará el programa en función de su estructura. Ambas técnicas son importantes para una práctica general de aseguramiento de la calidad dentro de un marco devops o devsecops.

Hay tres etapas principales involucradas en el análisis de código estático.

El analizador lee el código fuente y lo descompone en tokens. Estos se introducen en un analizador que los evalúa con respecto a las reglas gramaticales de un lenguaje de programación específico y los reestructura en un árbol de sintaxis abstracta jerárquica (AST). El AST mapea la estructura del software en un formato legible por máquina.

El analizador construye un gráfico de flujo de control (CFG) para mapear rutas de ejecución, combinado con análisis de flujo de datos para rastrear cómo las variables cambian los valores desde la inicialización hasta el uso. Esta es la etapa en la que el analizador puede descubrir errores como código muerto (código que nunca se puede ejecutar).

Mediante los modelos AST y de flujo, la herramienta compara el código con las pautas de programación y la heurística. Estas van desde simples convenciones de nomenclatura hasta comprobaciones de seguridad más sofisticadas, como el análisis de contaminación, que rastrea las entradas de usuario contaminadas que podrían conducir a inyecciones SQL.

En los primeros días de la informática, la ejecución del código era costosa y los desarrolladores no podían permitirse desperdiciar la depuración informática. La verificación fue totalmente impulsada por la inteligencia humana, con revisiones lentas y manuales del código.

La creación de Lint en 1978 por Stephen C. Johnson en Bell Labs marca el comienzo del análisis de código estático moderno. Lint se desarrolló para el sistema operativo Unix y se diseñó para escanear el código fuente y marcar construcciones sospechosas antes de la compilación.

Lint identificó el código problemático para eliminarlo sin cambiar la lógica del programa, lo que ahorró un cálculo valioso. Johnson le puso Lint por la pelusa atrapada en la trampa de una secadora de ropa porque su herramienta eliminó el código problemático no deseado (pelusa) sin cambiar la lógica (la estructura de la ropa).


A medida que Internet creció a lo largo de las décadas de 1990 y 2000, también lo hizo la necesidad de mitigar las fallas de seguridad. Surgieron nuevas herramientas para satisfacer esta demanda, al igual que formas de análisis más complejas que compilaban código en modelos matemáticos para rastrear cómo se movían las variables. Para contrarrestar estas amenazas, surgieron nuevos marcos de trabajo, como las pruebas de seguridad de aplicaciones estáticas (SAST), mientras que métodos como las pruebas de seguridad de aplicaciones dinámicas (DAST) permitieron la evaluación en tiempo de ejecución.

Si bien eran matemáticamente precisas, estas técnicas tenían altas tasas de falsos positivos debido a su incapacidad para comprender el contexto. El auge del machine learning y los modelos de lenguaje grande (LLM) en la década de 2020 desencadenó una nueva era de análisis de código, donde los modelos podrían entrenarse con miles de millones de líneas de código. Este entrenamiento les dio la capacidad de inferir la intención del desarrollador y el contexto semántico.

Tradicionalmente, el análisis de código estático era un proceso de gatekeeper que se ejecutaba antes del lanzamiento, pero hoy en día, este análisis se realiza a lo largo del ciclo de vida del desarrollo de software (SDLC). Esta filosofía de “shift left” implica mover las pruebas “hacia la izquierda”, más cerca de la creación del código.

Hoy en día, las herramientas de análisis de código como SonarQube, ESLint y GitHub Advanced Security son una parte integral del flujo de trabajo del desarrollador. Se ejecutan dentro de entornos de desarrollo integrados (IDE) para marcar errores en tiempo real según los tipos de desarrolladores. También actúan como puntos de control automatizados dentro de la integración continua y el despliegue continuo, o pipelines de CI/CD.

Los asistentes de codificación modernos impulsados por el machine learning han permitido el análisis de código descentralizado que es rápido y en gran medida invisible, lo que permite a los desarrolladores detectar errores temprano y mejorar la calidad del código en tiempo real. IBM Bob, por ejemplo, tiene un flujo de trabajo de “Revisión” que se ejecuta en un panel separado y busca automáticamente code smells y marca violaciones de estándares de programación, que los usuarios pueden descartar o hacer que Bob resuelva automáticamente.

El análisis también se puede realizar de forma proactiva a través de instrucciones estratégicas. Por ejemplo, en lugar de pedirle a un asistente de codificación que “encuentre bugs”, un desarrollador puede pedirle que revise los repositorios con objetivos específicos en mente. Para la revisión de la arquitectura, se puede pedir que revise la organización del directorio, los puntos de entrada, las relaciones de los componentes y la pila tecnológica general, todo lo cual genera documentación detallada. Un diseño de base de datos de análisis rápido puede identificar los objetivos de modernización. Los temas especializados pueden revisar el diseño de bases de datos, el análisis de migración y realizar una revisión exhaustiva de la deuda técnica, con recomendaciones sobre cómo corregir los problemas de la forma más estratégica.