CodeQL 2.27.4: compara resultados con contexto
Revisa las mejoras de precisión, metadata CWE y seguridad de query packs en CodeQL 2.27.4 sin confundir CLI, Action, GitHub.com y GHES.
5 de noviembre de 2026 · Leopoldo Benavente Cadena · 5 min de lectura
Actualizar CodeQL no significa que exista un único ejecutable detrás de todos los análisis. Puede intervenir la CLI local, un bundle descargado por CodeQL Action, el servicio gestionado de GitHub.com o una instancia de GitHub Enterprise Server (GHES). Antes de comparar alertas, identifica esa capa y conserva el contexto del análisis.
GitHub anunció CodeQL 2.27.4 el 4 de noviembre de 2026; el changelog técnico fecha la release el 2 de noviembre. Es una actualización del motor, las bibliotecas y los query packs, no una promesa de cero falsos positivos ni una certificación de que una aplicación esté libre de vulnerabilidades.
Qué cambia en 2.27.4
Hay mejoras concretas de precisión. Java y Kotlin reconocen más sanitizadores y guards de log injection y path injection. En Rust se reducen falsos positivos en rust/uncontrolled-allocation-size, rust/log-injection y rust/cleartext-logging. En C/C++, cpp/suspicious-pointer-scaling deja de informar cierta aritmética intencionada sobre buffers std::byte*, y las consultas de variables no reportan símbolos marcados con [[maybe_unused]]. JavaScript/TypeScript deja de informar propiedades calculadas __proto__ intencionadas en object literals.
Son cambios de consultas: el resultado depende también del extractor, la base CodeQL, la suite, el build y las consultas personalizadas. Que una alerta deje de aparecer en un caso no significa que todas las variantes de ese patrón sean seguras.
La release elimina external/cwe/cwe-730 de consultas de ReDoS y regex injection en C#, Java/Kotlin, JavaScript/TypeScript, Python, Ruby y Swift porque MITRE marcó CWE-730 como prohibida para mapeo. Esto es un cambio de metadata. No retira las consultas, no elimina la detección de ReDoS y no convierte los tags restantes en una evaluación completa del riesgo.
CLI, Action y servicios gestionados
| Capa | Qué versión o despliegue comprobar | Qué significa |
|---|---|---|
| CodeQL CLI | codeql version y el bundle local |
Ejecuta la base y los packs que le indiques |
| CodeQL Action | github/codeql-action/init@v4 y analyze@v4; registra la versión de Action y del bundle |
4.39.2 actualiza el bundle predeterminado a 2.27.4; 4.39.3 corrige un filtro diff-informed |
| GitHub.com | Configuración y logs del repositorio | GitHub despliega automáticamente nuevas versiones del bundle para code scanning |
| GHES | Versión de la instancia y método de actualización | La funcionalidad se incluirá en GHES 3.24; una versión anterior puede requerir actualización manual del CodeQL usado |
No escribas “el repositorio usa CodeQL 2.27.4” sin saber qué capa ejecutó el análisis. En Advanced setup, init@v4 y analyze@v4 son referencias de la Action; no son una forma de fijar manualmente un bundle inventando una versión en YAML. Captura en el log la versión efectiva y las opciones de la ejecución.
Query packs y salida reproducible
La CLI ahora envía a stderr los warnings y errores de inicialización de la JVM. Eso evita que contaminen JSON u otra salida machine-readable, pero no corrige un resultado incompleto: conserva stderr junto al log del análisis.
Al ejecutar codeql pack bundle o codeql pack publish, CodeQL resuelve los enlaces simbólicos y comprueba que cada archivo siga dentro de la raíz del pack. Si un enlace apunta fuera, omite el archivo y muestra una advertencia. Es una barrera de integridad del paquete; no sustituye la revisión de dependencias, el control de acceso ni el aislamiento del runner.
Las cifras de la release declaran 498 consultas de seguridad en la suite Default, que cubren 169 CWE, y 131 consultas adicionales en Extended, con 32 CWE adicionales. Son cifras de las suites, no cobertura de todos los bugs, frameworks o lenguajes de tu aplicación. Un pack personalizado puede ampliar, cambiar o limitar ese conjunto.
Comparar dos análisis sin engañarte
La comparación útil mantiene constante el commit, la matriz de lenguajes, el build que genera la base, la suite (Default o Extended), los packs, las consultas propias y el modo incremental o diff-informed. Registra la versión de CLI o bundle, la versión de Action, la configuración y el entorno del runner.
Con una base ya creada y el CLI instalado, la forma documentada de producir SARIF es:
codeql database analyze <database> --format=sarif-latest --output=results.sarif <query-specifier>Los marcadores se sustituyen por la base, el destino y la suite o pack que realmente quieras ejecutar. Si analizas más de una base para el mismo commit, asigna una categoría SARIF distinta a cada conjunto antes de subirlo; de lo contrario, una carga puede sobrescribir otra.
Compara ruleId, ubicación, severidad, tags/CWE y estado de cada alerta. Un aumento puede deberse a una consulta nueva, un extractor diferente o una base mejor construida; una disminución puede ser una mejora de precisión, un cambio de metadata o una configuración que dejó fuera consultas. Sin conservar los SARIF equivalentes no hay una tabla “antes/después” reproducible.
Para consultas propias, revisa @id, @kind, tags y documentación. database analyze necesita metadata estricta para interpretar resultados como alertas; query run y database run-queries sirven para desarrollo y producen resultados intermedios con requisitos distintos. No mezcles esos usos al comparar el code scanning que verá el equipo.
La actualización merece una rama de prueba y una revisión pequeña: identifica el ejecutor, fija las entradas, genera ambos SARIF y lee los cambios de metadata antes de cerrar el análisis. CodeQL 2.27.4 puede reducir falsos positivos concretos y mejorar la seguridad del empaquetado, pero el contexto de ejecución sigue siendo parte del resultado.
Comentarios