Calidad y seguridad en CI¶
test.yml integra cuatro plantillas de GitLab: Code Quality, Container Scanning, SAST y Secret Detection. Además añade jobs que leen los informes JSON y muestran resultados en los logs. Este diseño hace visibles los análisis dentro del flujo de GitLab.
Controles configurados¶
| Control | Configuración propia | Artefacto o evidencia |
|---|---|---|
| Calidad | ENABLE_QUALITY; resumen de cada hallazgo |
gl-code-quality-report.json |
| SAST | Inclusión de la plantilla oficial | Analizador heredado; semgrep-sast observado |
| Secretos | ENABLE_SECURITY; histórico activado |
gl-secret-detection-report.json |
| Contenedores | ENABLE_SECURITY; CS_SEVERITY_THRESHOLD: HIGH |
gl-container-scanning-report.json |
La plantilla oficial de contenedores usa por defecto $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA, que coincide con la convención del build. Verificar los valores efectivos si se añaden variables a nivel de grupo o proyecto. El umbral HIGH limita las severidades incluidas por ese análisis; no constituye por sí mismo una regla de bloqueo de despliegue.
Comportamiento de los resultados¶
La plantilla oculta .results-scanner cuenta vulnerabilidades, imprime sus campos y devuelve código 1 si detecta severidad High o Critical. Sin embargo, también declara allow_failure: true. Por ello, un fallo de ese job puede quedar permitido y no impedir la entrega.
results-code-quality sustituye el script heredado para imprimir incidencias y su número; no introduce un umbral de calidad bloqueante. No existe un job propio results-sast; el análisis SAST se incorpora a través de GitLab y conserva su informe.
Los metadatos públicos de los últimos pipelines observados confirman allow_failure: true tanto en los analizadores como en los resúmenes. Todos esos jobs figuran correctos en esas ejecuciones, pero no se han inspeccionado todos sus informes. No se deriva de ello que la aplicación esté libre de vulnerabilidades.
Pruebas automatizadas¶
La etapa llamada test contiene SAST en las ejecuciones observadas. Ambos POM declaran dependencias de test, pero no hay fuentes src/test y el build omite la ejecución con -DskipTests. No se han encontrado pruebas unitarias, de integración, de contrato ni de extremo a extremo implementadas en este snapshot.
Una evolución útil sería añadir pruebas pequeñas del contrato API y un smoke test después del rollout. Esta documentación no incorpora resultados de pruebas que no se hayan ejecutado.
Compatibilidad y mantenimiento¶
La documentación oficial de GitLab marca como deprecado el análisis CodeClimate de la plantilla Code Quality y anuncia su retirada. La continuidad de ese include debe verificarse en la versión concreta de GitLab que vaya a ejecutar el proyecto. Se propone migrar a una herramienta mantenida que exporte el formato Code Quality; no se afirma que todos los GitLab actuales hayan eliminado ya el archivo.
Las plantillas de GitLab y ref: main son dependencias cambiantes. Al reproducir una ejecución, revisar la configuración expandida en CI Lint y los jobs efectivos, además del YAML de los repositorios.
Convertir los análisis en una política de entrega¶
Si se desea una barrera bloqueante, definir primero qué hallazgos deben impedir la entrega, quién puede aceptar una excepción y por cuánto tiempo. Después ajustar allow_failure, las dependencias y las reglas de rama; añadir informes de prueba; y verificar con un caso de fallo conocido que los jobs de entrega se omiten.
Esto es una propuesta de evolución. La política versionada actual es la descrita arriba. El motivo histórico de permitir fallos debe registrarse cuando lo confirme el autor en decisiones.