SAST: Análisis Estático con SonarQube

Resumen Ejecutivo

SonarQube analiza el código fuente en cada push para detectar vulnerabilidades antes de que lleguen a producción.

• Valor: Detecta SQL Injection, XSS, hardcoded secrets y 500+ patrones de vulnerabilidad en Java, Node.js, Python, PHP y .NET.
• Eficiencia: Quality Gate automático — si el código no pasa, el pipeline se detiene sin intervención humana.
• Riesgo sin esto: Las vulnerabilidades en código fuente son la causa #1 de brechas de seguridad en aplicaciones web (OWASP Top 10).

SAST (Static Application Security Testing) es el proceso automatizado de analizar el código fuente para encontrar fallos de seguridad. En HERA, nuestra herramienta principal y obligatoria para SAST es SonarQube.

URL de SonarQube: https://sonarcloud.io/

¿Qué busca SonarQube?

SonarQube actúa como un revisor de código automatizado y experto en seguridad, buscando principalmente:

• Vulnerabilidades: Patrones de código que pueden ser explotados por atacantes (ej. SQL Injection, XSS).
• Security Hotspots: Áreas del código que son sensibles desde el punto de vista de la seguridad y que requieren una revisión manual por parte de un desarrollador.
• Bugs: Errores en el código que podrían llevar a un comportamiento inesperado.
• Code Smells: Problemas en el código que, aunque no son errores, indican un diseño pobre y dificultan el mantenimiento.

Integración en el Pipeline

El análisis de SonarQube es un job mandatorio del Golden Pipeline y corre en la etapa security. El equipo de producto no escribe este job en su .gitlab-ci.yml — se hereda del template vía include:.

Contrato del job sast-sonarqube

Atributo	Valor
Stage	security
Imagen base	Sonar Scanner CLI oficial
Variables inyectadas	SONAR_HOST_URL, SONAR_TOKEN (CI/CD variables a nivel de grupo root)
sonar.projectKey	Derivado automáticamente por el Golden Pipeline a partir del product-manifest.yml / service-manifest.yml; formato canónico grupoherdez_<dominio>_<producto>_<implementacion>_<repo-name> (ver Aside abajo)
Fuentes analizadas	Directorio src/ del repositorio
Espera activa al Quality Gate	Sí — sonar.qualitygate.wait=true. Si el código no pasa el Gate, el job falla y el pipeline entero se detiene
allow_failure	false — bloqueante
Trigger	Automático en cada MR y en cada push a develop / main

El parámetro de espera activa al Quality Gate es el que convierte el análisis en un bloqueo real del pipeline: sin él, el job completaría verde incluso con el código rechazado por Sonar.

Implementación canónica en el Golden Pipeline

La definición exacta del job (imagen con versión pineada, flags de sonar-scanner, rules:, artifacts:) vive en grupo-herdez/platform/pipelines/gitlab-ci/ bajo el stage security. El portal documenta el contrato observable; el código canónico vive en el template para evitar drift.

Naming del Project Key de SonarQube

El sonar.projectKey sigue el formato canónico:

grupoherdez_<dominio>_<producto>_<implementacion>_<repo-name>

Se deriva automáticamente de los atributos declarados en el product-manifest.yml (dominio, producto, implementación, Sonar_Org) y el nombre del repo — el equipo de producto no lo escribe a mano en su pipeline.

Ver Estructura de Repositorios — Convención de Project Key en SonarQube para formato detallado, componentes, ejemplos completos y reglas de derivación desde los manifiestos.

El Quality Gate de HERA

Un “Quality Gate” (Puerta de Calidad) es un conjunto de condiciones que tu código debe cumplir para ser considerado apto para producción.

Condiciones de Falla del Quality Gate

El pipeline fallará si en el nuevo código se detecta:

• 1 o más Nuevas Vulnerabilidades Críticas o Blocker.
• 1 o más Nuevos Bugs.
• Menos de un 80% de Cobertura de Pruebas (Coverage).
• Más de un 3% de Código Duplicado (Duplication).

Flujo de Trabajo del Desarrollador

1. Push de Código: Al crear un Merge Request o hacer push a develop, el pipeline ejecuta el job sast-sonarqube.
2. Análisis: SonarQube analiza el código.
3. Resultado:
   • Pasa: El pipeline continúa a la siguiente etapa.
   • Falla: El pipeline se detiene. El desarrollador recibe una notificación.
4. Revisión: El desarrollador debe ir al dashboard de SonarQube (el enlace aparece en el log del pipeline) para ver los detalles del fallo.
5. Corrección: El desarrollador corrige el código, hace un nuevo commit y push, lo que dispara un nuevo análisis. El ciclo se repite hasta que el Quality Gate pase.

Ejemplo de Remediación (SQL Injection)

SonarQube resalta una vulnerabilidad como la siguiente:

// ❌ CÓDIGO VULNERABLE - Detectado por SonarQube
String query = "SELECT * FROM users WHERE id = " + userId; // userId viene de un request
Statement stmt = connection.createStatement();
ResultSet rs = stmt.executeQuery(query);

Recomendación de SonarQube: “Use a prepared statement to prevent SQL Injection.”

Corrección del Desarrollador:

// ✅ CÓDIGO CORREGIDO
String query = "SELECT * FROM users WHERE id = ?";
PreparedStatement pstmt = connection.prepareStatement(query);
pstmt.setString(1, userId);
ResultSet rs = pstmt.executeQuery();

Tras subir este cambio, el re-análisis de SonarQube pasará la validación para esta vulnerabilidad.

Ejemplo de Remediación (XSS — Cross-Site Scripting)

// ❌ CÓDIGO VULNERABLE - Detectado por SonarQube
app.get('/search', (req, res) => {
  const query = req.query.q;
  res.send(`<h1>Resultados para: ${query}</h1>`);
});

Corrección del Desarrollador:

// ✅ CÓDIGO CORREGIDO - Sanitización de output
const escapeHtml = require('escape-html');

app.get('/search', (req, res) => {
  const query = escapeHtml(req.query.q);
  res.send(`<h1>Resultados para: ${query}</h1>`);
});

Security Hotspots

Los Security Hotspots no son vulnerabilidades confirmadas — son áreas del código que SonarQube identifica como potencialmente sensibles y que requieren revisión manual. Ejemplos comunes:

• Uso de algoritmos criptográficos (verificar que no sea MD5/SHA1 para passwords)
• Configuración de CORS (verificar que no esté abierto a *)
• Logging de datos de usuario (verificar que no se registren datos personales)

El desarrollador debe revisar cada Hotspot en el dashboard de SonarQube y marcarlo como Safe, Fixed o To Fix con justificación.

---

Lista de Verificación para Desarrolladores

Antes de solicitar merge de un MR que haya fallado por SonarQube:

• Todas las vulnerabilidades Critical y Blocker están corregidas
• Los Security Hotspots han sido revisados y marcados con justificación
• La cobertura de pruebas es mayor o igual al 80%
• La duplicación de código es menor al 3%
• El Quality Gate muestra estado verde en el dashboard de SonarQube