Análisis Estático con SonarQube

¿Qué Es el Análisis Estático? #

El análisis estático es la examinación automatizada del código fuente sin ejecutarlo. Las herramientas escanean el código buscando patrones que indican bugs, vulnerabilidades de seguridad, violaciones de estilo y problemas de complejidad.

Mientras las revisiones manuales (cubiertas en la Lección 2.29) dependen del juicio humano, las herramientas de análisis estático aplican miles de reglas consistentemente en cada línea de código en segundos. Nunca se cansan, nunca omiten un patrón conocido y se ejecutan igual cada vez.

Piensa en el análisis estático como el corrector ortográfico del código. El corrector no puede decir si tu ensayo presenta un buen argumento (eso requiere un revisor humano), pero detecta errores tipográficos, gramaticales y de formato instantáneamente.

Análisis Estático vs. Revisiones Manuales #

Mejor práctica: usa ambos. El análisis estático atrapa los issues rutinarios para que los revisores humanos se enfoquen en diseño y lógica.

Herramientas Populares de Análisis Estático #

Vista General de SonarQube #

SonarQube es el estándar de la industria para inspección continua de calidad de código. Proporciona un dashboard centralizado donde los equipos monitorean calidad, rastrean deuda técnica y aplican estándares.

Tipos de Issues #

Bugs — Código demostrablemente incorrecto o que probablemente cause comportamiento inesperado en ejecución. Ejemplos: dereferencia de null, índice fuera de rango, fugas de recursos.

Vulnerabilidades — Código que podría ser explotado por atacantes. Ejemplos: SQL injection, cross-site scripting (XSS), credenciales hardcodeadas.

Code Smells — Código que no es incorrecto pero dificulta el mantenimiento. Ejemplos: código duplicado, métodos demasiado complejos, variables no usadas.

Niveles de Severidad #

Quality Gates #

Un Quality Gate es un conjunto de condiciones que el código nuevo debe satisfacer. Actúa como puerta entre desarrollo y despliegue.

Quality Gate por defecto (“Sonar Way”):

• Sin bugs nuevos
• Sin vulnerabilidades nuevas
• Cobertura de código nuevo ≥ 80%
• Duplicación de código nuevo ≤ 3%

Los equipos personalizan Quality Gates según sus estándares.

Deuda Técnica #

SonarQube mide la deuda técnica como el tiempo estimado para corregir todos los code smells. Lo muestra como estimación: “5 días de deuda técnica.”

Ratio de Deuda Técnica = (costo de corregir smells) / (costo de reescribir desde cero). Un ratio bajo 5% se considera manejable.

Configuración de SonarQube #

Setup Local (Docker) #

# Iniciar SonarQube
docker run -d --name sonarqube -p 9000:9000 sonarqube:community

# Acceder en http://localhost:9000 (login: admin/admin)

Escaneando un Proyecto #

sonar-scanner \
  -Dsonar.projectKey=mi-proyecto \
  -Dsonar.sources=src \
  -Dsonar.host.url=http://localhost:9000 \
  -Dsonar.token=tu-token

Integración CI/CD #

# Ejemplo GitHub Actions
- name: SonarQube Scan
  uses: sonarqube/sonarcloud-github-action@v2
  env:
    SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
    SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}

El pipeline falla si el Quality Gate no se satisface, previniendo que código de baja calidad se integre.

Interpretando Reportes de SonarQube #

Al revisar un reporte, sigue este orden de prioridad:

1. Estado del Quality Gate — ¿Pasa o falla?
2. Bugs y vulnerabilidades nuevos — Máxima prioridad. Corregir todos los blockers y criticals.
3. Security hotspots — Código marcado como potencialmente vulnerable que necesita revisión humana.
4. Cobertura en código nuevo — ¿Está adecuadamente probado? Bajo 80% indica gaps.
5. Code smells en código nuevo — Baja prioridad pero rastrear la tendencia.
6. Métricas generales — ¿El proyecto mejora o empeora con el tiempo?

Ejercicio: Interpreta un Reporte de SonarQube #

Eres el QA lead revisando un reporte de SonarQube para un PR que agrega registro de usuarios:

Análisis de Código Nuevo:

• Bugs: 2 (1 Critical, 1 Major)
• Vulnerabilidades: 1 (Critical)
• Code Smells: 8 (2 Major, 6 Minor)
• Cobertura: 65%
• Duplicación: 1.2%

Detalles de Bugs:

• CRITICAL: Dereferencia de null en UserService.register()
• MAJOR: UserController.handleRegistration() captura Exception genérica

Detalle de Vulnerabilidad:

• CRITICAL: SQL injection en UserRepository.findByEmail() — email concatenado directamente en la consulta SQL

Quality Gate: FALLIDO (cobertura < 80%, vulnerabilidad crítica)

Parte 1: Prioriza los hallazgos. ¿Cuáles deben corregirse antes del merge?

Parte 2: Para la vulnerabilidad de SQL injection, describe la corrección y los test cases a agregar.

Parte 3: El desarrollador argumenta que 65% de cobertura es “suficiente”. Escribe tu respuesta.

Parte 4: ¿Qué mejoras de proceso recomendarías para prevenir estos issues?

String query = "SELECT * FROM users WHERE email = '" + email + "'";

@Query("SELECT u FROM User u WHERE u.email = :email")
Optional<User> findByEmail(@Param("email") String email);

Puntos Clave #

• El análisis estático automatiza la inspección de código, detectando bugs, vulnerabilidades y code smells sin ejecutar el código
• SonarQube clasifica issues en bugs (confiabilidad), vulnerabilidades (seguridad) y code smells (mantenibilidad)
• Los Quality Gates establecen condiciones umbral que el código nuevo debe cumplir
• La deuda técnica se mide como el tiempo estimado para corregir todos los code smells
• El análisis estático complementa las revisiones manuales — las herramientas detectan patrones, los humanos detectan lógica y diseño
• La integración CI/CD asegura que cada cambio sea analizado
• El mayor valor viene de corregir issues en código nuevo (shift-left) en vez de remediar código legacy