Actualidad empresarial BlackHold News
Buscar en BlackHold News
Código fuente abierto en un portátil de desarrollo

GitHub actualiza CodeQL con nuevas consultas y soporte para Kotlin 2.4.20

GitHub publicó el 25 de septiembre CodeQL 2.27.1, una actualización de su motor de análisis estático que incorpora nuevas consultas de seguridad para C/C++ y C#, compatibilidad con Kotlin 2.4.20 y mejoras en modelos y precisión. La versión afecta a organizaciones que utilizan GitHub code scanning o ejecutan CodeQL en entornos propios, según la nota oficial de GitHub.

Qué incorpora CodeQL 2.27.1

La versión añade nuevas consultas para detectar problemas en C/C++ y C#, amplía el soporte del analizador de Java/Kotlin a Kotlin 2.4.20 y mejora modelos utilizados para comprender bibliotecas y flujos de datos. El objetivo es aumentar cobertura y precisión sin que el desarrollador tenga que escribir reglas desde cero.

Para una empresa que mantiene aplicaciones en varios lenguajes, estas actualizaciones pueden modificar el conjunto de alertas que aparece en los análisis. Una nueva versión del motor puede revelar problemas que una anterior no detectaba o reducir falsos positivos gracias a modelos más precisos.

Qué ocurre en GitHub.com y Enterprise Server

GitHub despliega automáticamente la nueva versión para code scanning en github.com, por lo que los clientes del servicio alojado no necesitan instalar el motor manualmente. GitHub Enterprise Server 3.24 la incluye, mientras que organizaciones con versiones anteriores de GHES pueden actualizar CodeQL de forma manual cuando necesiten estas mejoras.

Qué debería hacer un equipo que usa Kotlin

Los proyectos que hayan adoptado Kotlin 2.4.20 deberían verificar que sus flujos de análisis utilizan una versión compatible. En GitHub.com el cambio llega gestionado por la plataforma; en instalaciones Enterprise Server más antiguas conviene revisar la versión del bundle de CodeQL.

Después de la actualización también es recomendable comparar el número y tipo de alertas con ejecuciones anteriores. Un aumento no significa necesariamente que el código haya empeorado: puede reflejar mayor cobertura del analizador.

En repositorios donde la seguridad forma parte del proceso de entrega, conviene registrar la versión del analizador utilizada en cada ejecución. Eso permite distinguir una vulnerabilidad introducida por un cambio de código de una alerta que aparece porque CodeQL ha mejorado su capacidad de detección. También facilita justificar por qué una incidencia surge ahora aunque la línea afectada lleve meses en producción.

Impacto para pymes de software

Las empresas pequeñas suelen tener menos capacidad para mantener reglas propias de análisis. Las mejoras incorporadas al motor reducen esa carga, pero no sustituyen las pruebas, revisión de dependencias ni control de secretos. CodeQL debe formar parte de un proceso de seguridad más amplio y no funcionar como único filtro.

Para mantener el contexto de seguridad, también son relevantes el parche crítico de GitLab, los fallos de StockAgile, la adopción de passkeys, el nuevo Microsoft Defender, la remediación automática de Cloudflare CASB y las capacidades agénticas de Workspace.

Fotografía: Lukas Blazek / Pexels.

Scroll al inicio