Índice de contenidos
Claves de la noticia
- SonarQube Community Build 26.10 elimina el grupo Anyone: migra permisos existentes a sonar-users, pero descarta los de las plantillas.
- La validación de webhooks bloquea ahora destinos de redes privadas y puede interrumpir integraciones internas tras actualizar.
- Los tres nuevos perfiles de análisis no sustituyen automáticamente los que usan los proyectos ya instalados.
Sonar ha publicado este 14 de octubre SonarQube Community Build 26.10.0.133078, una actualización de su herramienta de revisión de código con consecuencias para administradores y equipos de desarrollo. El anuncio destaca nuevos perfiles y reglas; las notas de actualización añaden una advertencia más práctica: conservar el acceso de un proyecto existente no garantiza que los siguientes nazcan con los mismos permisos.
Los permisos actuales sobreviven; las plantillas, no
La documentación oficial distingue dos operaciones que pueden parecer equivalentes. Los permisos globales y de proyecto que tenía Anyone pasan a sonar-users al actualizar. En cambio, los permisos de Anyone incluidos en plantillas se eliminan sin migrarse. Sonar pide revisar esas plantillas y asignar los permisos necesarios a sonar-users u otro grupo.
Esta diferencia permite anticipar una comprobación concreta: probar solo un repositorio que ya estaba configurado puede ocultar un problema en la creación del siguiente. El primero conserva permisos por la migración; la plantilla que determina el acceso de nuevos proyectos puede haber perdido esas concesiones. No es una incidencia observada en una instalación propia, sino la consecuencia de aplicar conjuntamente las dos reglas documentadas.
| Ámbito | Tratamiento en 26.10 | Comprobación útil |
|---|---|---|
| Permisos globales y de proyecto de Anyone | Migran a sonar-users | Acceso de usuarios autenticados |
| Permisos de Anyone en plantillas | Se eliminan sin migrarse | Creación de un proyecto de prueba |
| Visibilidad pública del proyecto | Se conserva como mecanismo separado | Lectura pública y autenticación forzada |
Los usuarios sin autenticar pierden los permisos que recibían únicamente de Anyone, incluido Execute Analysis. Esto convierte el cambio en incompatible para quienes dependían del análisis anónimo. Sin embargo, no vuelve privados todos los proyectos: la visibilidad pública continúa permitiendo consultar y ver código sin iniciar sesión cuando la autenticación forzada está desactivada.
También cambia la automatización administrativa. Cuatro operaciones de la API para conceder o retirar permisos de grupos, tanto directamente como en plantillas, responden con un error 404 si groupName identifica a Anyone, sin importar las mayúsculas. Los scripts que siguen intentando configurar ese grupo necesitan revisión; cambiar de versión no corrige sus instrucciones.
Un webhook interno puede dejar de recibir resultados
La validación de webhooks amplía el conjunto de direcciones rechazadas. Con Enable local webhooks validation activado, que es el valor predeterminado, ya no admite destinos que resuelvan a redes privadas, direcciones de enlace local, multidifusión o metadatos de nube. Antes bloqueaba las direcciones de bucle local, comodín y del propio servidor de SonarQube.
La regla se aplica al crear o modificar un webhook y en cada entrega, incluidos los destinos de redirecciones. Por eso también puede afectar a integraciones que nadie haya editado durante la actualización. Sonar cita expresamente receptores internos de integración continua con direcciones 10.x.x.x o 192.168.x.x como casos que pueden dejar de funcionar.
La documentación ofrece desactivar esa validación si los webhooks deben llegar a destinos internos. Pero el alcance de la excepción resulta decisivo: desactivarla retira la comprobación de direcciones para todos los webhooks de la instancia, incluidos los creados por administradores de proyecto. Recuperar una integración concreta tiene, por tanto, un efecto sobre una política compartida. La decisión debe considerar quién puede configurar otros destinos, además del receptor que necesita recuperar las notificaciones.
La conexión global no acredita el acceso de cada usuario
Vincular un proyecto con repositorios de GitLab, Azure DevOps, Bitbucket Cloud o Bitbucket Data Center exige ahora que el usuario que realiza la operación tenga su propio token de acceso almacenado. Las credenciales de la integración global ya no bastan. Según Sonar, el objetivo es que cada usuario solo vincule repositorios a los que tenga acceso en la plataforma de desarrollo.
Esto introduce otra separación útil para diagnosticar fallos. La prueba Check configuration de la integración global puede funcionar y, aun así, fallar el guardado del vínculo del proyecto por falta del token personal. El primer resultado valida las credenciales globales; no demuestra que el usuario haya completado su requisito. Antes de cambiar configuraciones compartidas conviene comprobar a qué nivel corresponde el error.
Tres perfiles para decidir cuántas reglas aplicar
La versión incorpora Sonar way core, extended y comprehensive para cada lenguaje. Core activa todas las reglas de seguridad y las de fiabilidad y mantenibilidad consideradas más relevantes; extended añade más de estas dos últimas familias, mientras comprehensive activa todas las reglas recomendadas. Core es el perfil predeterminado únicamente en instalaciones nuevas.
Al actualizar una instalación existente se conservan tanto los perfiles usados por los proyectos como el predeterminado de cada lenguaje. Por eso comparar el número de avisos de una instalación nueva con otra actualizada exige comprobar primero el perfil efectivo. La versión por sí sola no acredita que estén analizando con el mismo conjunto de reglas.
La revisión previa más útil consiste así en separar proyectos existentes, proyectos nuevos e integraciones que reciben los resultados. El anuncio de Christophe Lévis confirma la publicación; las notas detallan por qué una actualización aparentemente correcta puede dejar pendientes permisos futuros, análisis anónimos o notificaciones. Ninguno de esos efectos demuestra por sí mismo una vulnerabilidad explotada: son cambios de comportamiento que conviene verificar antes de dar por terminada la migración.
Imagen: Tecnología Today, imagen conceptual generada con IA.
