Los escáneres de seguridad con IA hallan más problemas. GitHub ya muestra si los desarrolladores los corrigen

Hay una forma fácil de hacer que un escáner de seguridad con IA parezca un éxito: contar lo que encuentra. Más hallazgos por pull request, más repositorios cubiertos, más vulnerabilidades “detectadas”. Ninguna de esas cifras dice si el código es más seguro. Un hallazgo que nadie corrige es una notificación, y un aluvión de ellas enseña a los desarrolladores a dejar de leerlas.

La actualización de GitHub del 13 de octubre acerca la medición a lo que importa. Los administradores de organizaciones y empresas tienen ahora métricas de AI Scan en pull requests dentro del security overview: hallazgos generados y resueltos, tasa de remediación, qué repositorios generan hallazgos, tendencias en el periodo y con qué frecuencia los desarrolladores aplican las sugerencias de autofix. La página antes llamada “CodeQL pull requests” pasa a ser “Code scanning on pull requests”, con pestañas separadas para CodeQL y AI Scan. La pestaña de AI Scan muestra el total de hallazgos y cuántos llegaron con o sin sugerencia de autofix.

La función está en versión preliminar pública, en github.com, incluido GitHub Enterprise Cloud, para clientes con GitHub Code Security o GitHub Advanced Security. GitHub Enterprise Server no es compatible en esta versión.

Por qué importa separar AI Scan de CodeQL

CodeQL es un motor de análisis basado en reglas; sus hallazgos son reproducibles y sus patrones de falsos positivos se conocen bien. AI Scan usa un modelo para buscar problemas en un pull request. Mezclar ambos en un mismo dashboard difuminaría justo la comparación que necesita una empresa: ¿el escáner con IA añade hallazgos que los desarrolladores atienden, o ruido que descartan? Con pestañas separadas, el equipo de seguridad puede hacerse esa pregunta repositorio por repositorio.

Es la forma correcta de evaluar cualquier sistema de IA en el pipeline de entrega: como un componente propio con métricas propias, el enfoque que defendimos al escribir que la búsqueda debe medirse como un sistema aparte.

Lo que pueden decir las cifras

Usadas con cuidado, las nuevas métricas sirven para tres decisiones:

• Despliegue. La tasa de remediación por repositorio muestra dónde AI Scan recibe atención y dónde se ignora. Los repositorios con baja remediación necesitan ajustes o una conversación con el equipo.
• Confianza en el autofix. La frecuencia con que los desarrolladores aplican las correcciones sugeridas es una señal directa de si son lo bastante buenas para usarlas. Una tasa baja significa costo de revisión sin beneficio.
• Huecos de cobertura. Los repositorios que no generan ningún hallazgo merecen una mirada: pueden estar limpios, o el análisis puede no estar ejecutándose donde debería.

Lo que no pueden decir

Una tasa de remediación más alta no demuestra un riesgo menor, por motivos que conviene dejar escritos en cualquier informe que cite estas cifras:

• Una corrección cierra un hallazgo, no una vulnerabilidad. Aplicar un autofix resuelve la alerta. Si la corrección es correcta, completa y sin efectos secundarios es otra cuestión, que exige revisión o pruebas, sobre todo con código sugerido por IA.
• Resuelto necesita una definición. El changelog no dice si un hallazgo descartado cuenta como resuelto. Compruebe las definiciones de las métricas antes de reportar la cifra hacia arriba.
• La gravedad no aparece en la cifra principal. Un problema crítico corregido vale más que cincuenta avisos de estilo corregidos. Informe de la remediación por gravedad, no en conjunto.
• Lo no encontrado es invisible. El dashboard mide lo que el escáner encontró. No dice nada de lo que se le escapó, que solo pueden estimar pruebas independientes.

Es la misma trampa que describimos en las horas ahorradas no son valor: una métrica de actividad presentada como un resultado. Hallazgos corregidos es mejor que hallazgos encontrados. Riesgo reducido es mejor todavía, y hay que medirlo con algo distinto del propio escáner.

La conclusión práctica

Si usa AI Scan, aproveche la versión preliminar para fijar ya una línea base: tasa de remediación y aceptación del autofix por repositorio, separadas por gravedad. Complétela con una muestra periódica de autofixes aplicados, revisada por un ingeniero de seguridad, para saber si las correcciones aceptadas son correctas. La experiencia de Google con agentes en la revisión de código mostró que las herramientas de seguridad con IA se ganan su sitio cuando su resultado llega a donde los desarrolladores ya deciden. Las métricas de GitHub permiten ahora comprobar si eso está ocurriendo.