¿Qué es el análisis estático?

¿Qué es el análisis estático?

El análisis estático es el análisis automatizado del código fuente sin ejecutar la aplicación.

Cuando el análisis se realiza durante la ejecución del programa, se denomina análisis dinámico.

El análisis estático se utiliza a menudo para detectar:

• Vulnerabilidades de seguridad.
• Problemas de rendimiento.
• Incumplimiento de estándares.
• Uso de construcciones de programación obsoletas.

¿Cómo funciona una herramienta de análisis estático?

El concepto básico común a todas las herramientas de análisis estático es buscar en el código fuente para identificar patrones de codificación específicos que tengan algún tipo de advertencia o información asociada.

Esto puede ser tan sencillo como "las clases de prueba JUnit 5 no necesitan ser 'public'". O algo complejo de identificar como "entrada de cadena no confiable utilizada en una sentencia de ejecución SQL".

Las herramientas de análisis estático varían en la forma en que implementan esta funcionalidad.

• tecnología de análisis de código fuente para crear un árbol de sintaxis abstracta (AST),
• coincidencia de texto mediante expresiones regulares,
• una combinación de ambos.

La coincidencia de texto mediante expresiones regulares es muy flexible y fácil de escribir, pero a menudo puede generar muchos falsos positivos y las reglas de coincidencia ignoran el contexto del código circundante.

La coincidencia mediante AST trata el código fuente como código de programación y no solo como archivos llenos de texto; esto permite una coincidencia más específica y contextual, y puede reducir el número de falsos positivos reportados en el código.

Análisis estático en integración continua

El análisis estático se realiza a menudo durante el proceso de integración continua (CI) para generar un informe de problemas de cumplimiento que puede revisarse para obtener una visión objetiva de la base de código a lo largo del tiempo.

Algunas personas utilizan el análisis estático como una medida objetiva de la calidad de su código configurando la herramienta para que solo mida partes específicas del código y solo informe sobre un subconjunto de reglas.

La objetividad la proporcionan las reglas utilizadas, ya que estas no varían en su evaluación del código con el paso del tiempo. Claramente, la combinación de reglas utilizadas y su configuración es una decisión subjetiva, y los diferentes equipos eligen usar reglas distintas en momentos diferentes.

Realizar el análisis estático en CI es útil, pero puede retrasar la retroalimentación para el programador. Los programadores no reciben comentarios mientras codifican, sino más tarde, cuando el código pasa por la herramienta de análisis estático. Otro efecto secundario de ejecutar el análisis estático en CI es que los resultados son más fáciles de ignorar.

Para lograr que los equipos presten más atención a los resultados del análisis estático, suele ser posible configurar una métrica de umbral en el proceso de compilación que provoque un error si se supera dicha métrica, por ejemplo, al alcanzar un número determinado de reglas infringidas.

Análisis estático en el IDE

Para recibir comentarios más rápidos, existen muchos complementos para IDE que ejecutan las reglas de análisis estático bajo demanda o periódicamente a medida que se modifica el código.

Las infracciones de las reglas pueden visualizarse en el IDE mientras el programador escribe el código y, para que sean más difíciles de ignorar, a menudo se pueden configurar para que aparezcan subrayadas en el editor.

Personalmente, me parece una forma útil de mejorar mi programación, especialmente al trabajar con una nueva biblioteca cubierta por la herramienta de análisis estático. Aunque puede resultar "ruidosa" debido a falsos positivos o reglas que no interesan, esto se soluciona dedicando un momento a configurar la herramienta para ignorar ciertas reglas.

Corrección de código basada en reglas de análisis estático

En la mayoría de las herramientas de análisis estático, la corrección de la regla queda en manos del programador, quien debe comprender la causa de la infracción y cómo solucionarla.

Muy pocas herramientas de análisis estático incluyen la capacidad de corregir las infracciones automáticamente, ya que la solución suele depender del contexto del equipo, la tecnología utilizada y los estilos de codificación acordados.

Reglas predeterminadas

Puede surgir una falsa confianza en la calidad de las reglas cuando las herramientas de análisis estático vienen con configuraciones predeterminadas; es tentador creer que cubren todos los problemas que un programador podría encontrar y todas las circunstancias en las que se debe aplicar una regla. A veces, las condiciones en las que una regla debe aplicarse pueden ser sutiles y no fáciles de detectar.

La esperanza es que, al utilizar una herramienta de análisis estático e investigar las reglas y las infracciones con mayor detalle, los programadores desarrollen la habilidad de detectar y evitar problemas dentro del contexto de su dominio específico.

Cuando el dominio requiere reglas contextuales, es posible que las herramientas de análisis estático no cuenten con reglas que se ajusten a su dominio o biblioteca; además, estas herramientas suelen ser difíciles de configurar y ampliar.

Inconvenientes

Ninguno de estos "inconvenientes" es insuperable:

• falsos positivos
• falta de correcciones automáticas
• configuración para ignorar reglas
• añadir reglas específicas del contexto

Sin embargo, a menudo se utilizan como excusas para evitar el uso de herramientas de análisis estático desde el principio, lo cual es una lástima, ya que su uso puede ser enormemente beneficioso para:

• destacar mejores enfoques a los desarrolladores junior
• obtener retroalimentación rápida sobre infracciones de código claras
• identificar problemas complejos que el programador no ha encontrado antes
• reforzar que el programador ha adoptado un buen enfoque de codificación (cuando no se reportan infracciones)

Herramientas de análisis estático basadas en IDE

Como colaborador individual en un proyecto, prefiero usar herramientas de análisis estático que se ejecuten desde el IDE para recibir comentarios rápidos sobre mi código.

Esto complementa cualquier proceso de revisión de solicitudes de extracción (pull requests) y la integración de CI que pueda tener el proyecto.

Intento identificar herramientas que me den ventaja y mejoren mi flujo de trabajo individual.

Cuando las herramientas se ejecutan en el IDE, dado que suelen compartir la misma interfaz gráfica y enfoque de configuración, puede resultar tentador verlas como intercambiables.

Puede que las herramientas tengan funciones o conjuntos de reglas que se solapen, pero para obtener la máxima ventaja, instalo varias de ellas y así aprovecho sus puntos fuertes.

A continuación, enumero las herramientas de análisis estático para IDE que utilizo activamente mientras programo:

• las inspecciones integradas de IntelliJ: patrones de codificación comunes
• SpotBugs: errores comunes
• SonarLint: patrones de uso comunes
• CheckStyle: patrones de estilo comunes
• Sensei de Secure Code Warrior: creación de reglas personalizadas

Las uso todas porque funcionan bien juntas, complementándose y reforzándose entre sí.

Inspecciones de IntelliJ

Si utilizas IntelliJ, ya estás usando sus inspecciones.

Se trata de reglas de análisis estático que se marcan en el IDE. Algunas de ellas también ofrecen opciones de corrección rápida (QuickFix) para reescribir el código y solucionar el problema.

Las reglas se pueden activar o desactivar, y es posible elegir el nivel de error con el que se resaltan en el IDE.

Hay muchas inspecciones de IntelliJ útiles. Lo sé porque las he revisado mientras escribía esto. Utilizo las inspecciones de IntelliJ con la configuración predeterminada y no las he modificado, pero para sacarles el máximo partido, deberías revisarlas, identificar las que sean relevantes para tu estilo de programación y configurar el nivel de advertencia para que las detectes en el código.

Lo mejor de las inspecciones de IntelliJ es que vienen incluidas gratis con el IDE y ayudan a desarrollar la memoria muscular para:

• detectar advertencias y errores en el código fuente mientras escribes
• pasar el ratón sobre el código marcado para conocer las infracciones de las reglas
• usar alt+enter para aplicar una corrección rápida al problema

SpotBugs

El plugin de SpotBugs para IntelliJ utiliza análisis estático para intentar alertarte de errores en tu código.

SpotBugs se puede configurar desde las preferencias de IntelliJ para analizar tu código; las reglas específicas que utiliza se encuentran en la pestaña Detector.

Suelo usar SpotBugs después de haber escrito y revisado mi código; entonces ejecuto la opción 'Analyze Project Files Including Test Sources'.

Esto me ayuda a identificar errores, código muerto y optimizaciones evidentes. También me obliga a investigar algunas de las infracciones marcadas para decidir qué hacer al respecto.

SpotBugs detecta problemas, pero no ofrece ninguna acción de corrección rápida para intentar resolverlos.

SpotBugs es fácil de configurar y me parece una segunda opinión objetiva muy útil para consultar dentro de mi IDE.

SonarLint

El plugin SonarLint.

SonarLint puede configurarse desde las preferencias de IntelliJ para seleccionar las reglas con las que se valida el código.

Por defecto, SonarLint se ejecuta en tiempo real y muestra los problemas del código que estás editando en ese momento.

SonarLint no ofrece correcciones rápidas, pero la documentación asociada a los informes de infracciones suele ser clara y completa.

En el pasado, SonarLint me ha resultado útil para avisarme de nuevas funciones de Java que desconocía en las versiones más recientes.

CheckStyle

El plugin CheckStyle ofrece una combinación de reglas de formato y de calidad de código.

El plugin CheckStyle viene con los conjuntos 'Sun Checks' y 'Google Checks' integrados.

Las definiciones de estos pueden encontrarse fácilmente en línea.

CheckStyle aporta el mayor valor cuando un proyecto ha dedicado tiempo a crear su propio conjunto de reglas. Entonces, el plugin del IDE puede configurarse para usar ese conjunto y los programadores pueden realizar un análisis antes de enviar el código a CI.

CheckStyle se utiliza muy a menudo como plugin para interrumpir la compilación en procesos de CI cuando el número de infracciones supera un límite determinado.

Sensei

Sensei utiliza análisis estático basado en un árbol de sintaxis abstracta (AST) para buscar coincidencias en el código y crear correcciones rápidas, lo que permite identificar problemas de forma muy específica.

El AST permite que las correcciones rápidas asociadas a una receta comprendan el código circundante; por ejemplo, al añadir una nueva clase al código, cualquier importación para esa clase se añadirá al archivo fuente una sola vez, y no en cada reemplazo.

Sensei se creó para facilitar la elaboración de reglas de coincidencia personalizadas que quizás no existan o que serían difíciles de configurar en otras herramientas.

En lugar de modificar un archivo de configuración, toda la configuración puede realizarse desde la interfaz gráfica. Al crear nuevas recetas, la interfaz facilita ver qué código coincide con la receta. Y al definir las correcciones rápidas, se puede comparar inmediatamente el estado del código antes y después. Esto facilita la creación de recetas muy contextuales, es decir, únicas para equipos, tecnologías o incluso programadores individuales.

Utilizo Sensei en combinación con otras herramientas de análisis estático; por ejemplo, la mayoría de estas herramientas encuentran problemas, pero no los solucionan. Un caso de uso común para Sensei es replicar la búsqueda de coincidencias de otra herramienta en Sensei y ampliarla con una corrección rápida. Esto tiene la ventaja de que la corrección personalizada aplicada ya cumple con los estándares de codificación de tu proyecto.

Periódicamente me encuentro creando recetas de Sensei que ya existen en el conjunto de intenciones de IntelliJ, porque el informe de intención no coincide exactamente con el contexto que he creado o porque la corrección rápida proporcionada por IntelliJ no se ajusta al patrón de código que quiero utilizar.

Complemento las herramientas existentes en lugar de intentar sustituirlas por completo.

Sensei también resulta muy útil cuando identificas una variante contextual de una regla común; por ejemplo, si utilizas una biblioteca SQL no compatible con la herramienta de análisis estático, pero las reglas SQL generales del motor de análisis siguen siendo aplicables, puedes crear variantes específicas de esas reglas para dicha biblioteca usando Sensei.

Sensei no incluye de serie una gran cantidad de recetas genéricas como las herramientas de análisis estático mencionadas; su fortaleza reside en facilitar la creación de nuevas recetas, completas con QuickFixes configurados para adaptarse a tu estilo de programación y casos de uso específicos.

NOTA: estamos trabajando en un repositorio público de recetas para cubrir casos de uso genéricos, y puedes encontrarlo aquí.

Resumen

Suelo elegir herramientas que funcionan bien juntas, son configurables y fáciles de ampliar para adaptarse a mi contexto. He utilizado herramientas de análisis estático en el IDE durante años para identificar problemas y aprender más sobre los lenguajes de programación y las bibliotecas que utilizo.

Utilizo todas las herramientas mencionadas de forma combinada:

• IntelliJ Intentions ayuda a señalar problemas comunes de código desde el primer momento, a menudo con QuickFixes asociados.
• SpotBugs detecta errores simples que podría haber pasado por alto y me alerta sobre problemas de rendimiento.
• SonarLint identifica funciones de Java que desconocía y me sugiere formas adicionales de modelar mi código.
• CheckStyle me ayuda a cumplir con un estilo de codificación acordado que también se aplica durante la integración continua (CI).
• Sensei me ayuda a crear QuickFixes para mejorar los escenarios comunes detectados por las herramientas de análisis estático y a crear recetas específicas para proyectos o tecnologías que pueden ser difíciles de configurar en otras herramientas.

---

Instala Sensei desde IntelliJ usando "Preferences \ Plugins" (Mac) o "Settings \ Plugins" (Windows) y simplemente busca "sensei secure code".

Puedes encontrar un repositorio de código de ejemplo y recetas para casos de uso comunes en la cuenta de GitHub de Secure Code Warrior, dentro del proyecto `sensei-blog-examples`.

https://github.com/securecodewarrior/sensei-blog-examples

Más información sobre Sensei