GitHub permite desde ahora aplicar una configuración propia al análisis de código predeterminado de CodeQL mediante una propiedad de repositorio. El cambio busca resolver un problema de escala: mantener criterios comunes de seguridad en decenas o cientos de proyectos sin tener que escribir y actualizar un flujo de GitHub Actions distinto en cada uno. Una organización puede centralizar las reglas y propagarlas automáticamente.
La novedad no sustituye al análisis de código ni amplía por sí sola los lenguajes compatibles. Cambia la forma de administrar su configuración. Encaja en una tendencia más amplia hacia controles de seguridad automatizados, como Project Perception de Microsoft para detectar y corregir riesgos, aunque aquí el objetivo concreto es gobernar cómo CodeQL examina repositorios de una misma organización.
¿Qué se configura exactamente?
La nueva propiedad se llama github-codeql-config-file y apunta a un archivo de configuración de CodeQL. Al activarla, GitHub combina ese archivo con los valores integrados del modo predeterminado. Es posible añadir consultas, excluir rutas que no deban analizarse o seleccionar modelos de amenazas. Los modelos y paquetes elegidos previamente en la interfaz se conservan al fusionar la configuración.
Esto aproxima el modo predeterminado a parte del control que ofrecía la configuración avanzada, pero evita mantener un archivo de flujo en cada repositorio. Los propietarios de la organización pueden definir un valor común y decidir si los equipos tienen permiso para reemplazarlo localmente. También pueden probar la propiedad en un único proyecto antes de extenderla al resto.
¿Dónde puede vivir el archivo común?
El archivo puede almacenarse en un repositorio central y referenciarse desde otros proyectos con una sintaxis simplificada. Si se omiten la referencia y la ruta, GitHub busca la ubicación predeterminada en la rama principal de un repositorio perteneciente a la misma organización. Un solo archivo puede actuar así como política base para muchos repositorios, sin impedir excepciones cuando la organización las autorice.
Cuando el repositorio central es privado, GitHub permite conceder acceso al modo predeterminado mediante un registro privado de tipo Git Source. La ventaja operativa es evitar un token administrado dentro de cada flujo. Aun así, el acceso al repositorio de configuración merece el mismo control que cualquier política de seguridad: una modificación errónea podría alterar simultáneamente la cobertura de numerosos proyectos.
Qué aporta y qué no resuelve
Para un equipo pequeño con pocos repositorios, la diferencia puede ser modesta. En organizaciones grandes, reduce la deriva entre configuraciones y facilita auditar una política común. No elimina la necesidad de revisar alertas, ajustar falsos positivos o comprobar que las exclusiones no oculten código relevante; simplifica el despliegue coherente de esas decisiones.
La función está disponible de forma general en GitHub.com. GitHub también ha confirmado que llegará con GitHub Enterprise Server 3.23. Antes de implantarla a escala conviene validar la configuración en un repositorio representativo, revisar los permisos para sobrescribirla y documentar quién puede modificar el archivo central.
