Corrección de vulnerabilidades con IA: qué pueden hacer las pull requests de corrección

Qué es la corrección con IA

La corrección de vulnerabilidades con IA utiliza un modelo de lenguaje para producir la corrección de una vulnerabilidad conocida. Se presenta de tres formas:

• Sugerencias de corrección de código. Un modelo propone un parche junto a una alerta de análisis estático. GitHub Copilot Autofix, por ejemplo, «genera automáticamente sugerencias de cambios de código para las alertas de CodeQL encontradas en pull requests y en la rama predeterminada».
• Actualizaciones de dependencias que adaptan el código. Subir de versión es fácil. Lo difícil es la función renombrada o el valor predeterminado modificado que trae la nueva versión. Un modelo puede hacer esos cambios derivados en la misma pull request.
• Corrección agéntica. Un agente lleva la corrección por varios pasos por sí mismo: cambiar el código, ejecutar el build y los tests, leer los fallos, volver a intentarlo y abrir una pull request solo cuando las comprobaciones pasan.

Dónde las correcciones con IA demuestran su valor

Los bots de actualización basados en reglas ya abren pull requests que suben un paquete vulnerable a una versión corregida. Se atascan cuando la actualización rompe algo, porque adaptar el código que lo llama no es una regla. Ahí es donde se acumula el trabajo pendiente: la actualización de seguridad que lleva meses abierta porque nadie tiene tiempo de abordar el cambio de versión mayor.

Leer un changelog, encontrar los puntos de llamada y reescribirlos es el tipo de trabajo que los modelos de lenguaje hacen bien. Una corrección con IA que llega con la actualización y los cambios de código, ya compilada y probada, convierte una semana de atención de alguien en una revisión.

Dónde fallan las correcciones con IA

Las descripciones más claras de sus límites vienen de los propios proveedores. Sobre Copilot Autofix, GitHub escribe:

• «Utiliza un modelo generativo que no es determinista. Incluso con la misma alerta y el mismo código, puede no producir una sugerencia viable, o la sugerencia puede variar entre intentos».
• «El sistema no sabe qué versiones de las dependencias son compatibles o seguras, y puede sugerir dependencias inventadas publicadas con nombres estadísticamente probables».

El segundo punto no es hipotético. La investigación sobre modelos que generan código ha medido con qué frecuencia recomiendan paquetes que no existen, nombres que un atacante puede registrar y llenar de malware. Una corrección que instala un paquete inventado sustituye una vulnerabilidad por otra peor.

Tres salvaguardas cubren la mayor parte del riesgo:

1. Compile y pruebe cada corrección antes de que la revise una persona, para que el tiempo de revisión se dedique a correcciones que funcionan.
2. Compruebe cada paquete añadido o modificado frente al registro y la versión que espera.
3. Mantenga a una persona en la fusión. Una corrección con IA es la pull request de un colaborador, no una decisión.

Si entra basura, salen pull requests

Una herramienta de corrección con IA corrige las vulnerabilidades que se le dan. Si esa lista se reconstruye a partir de lockfiles o de una imagen escaneada, hereda cada laguna de la reconstrucción: herramientas que el build descarga y que ningún manifiesto declara, versiones distintas de las que resolvió el build, paquetes restaurados desde cachés. La herramienta abre entonces con toda confianza pull requests para algunas vulnerabilidades y nunca se entera de otras.

Algunos equipos van más allá y piden a un modelo que deduzca las propias dependencias. Eso vuelve no determinista también el inventario, que es precisamente la parte del proceso que debería dar el mismo resultado cada vez. SBOM generadas por IA explica por qué un inventario adivinado no es evidencia.

El patrón que funciona es datos deterministas debajo y criterio de IA encima: una lista registrada de lo que contiene realmente cada build, cotejada con los avisos mediante consulta, y la IA escribiendo la corrección.

Dónde encaja CRACI

CRACI es la capa determinista. Ejecuta sus jobs de GitHub Actions en sus propios runners y registra los paquetes que cada job descargó realmente, incluidas las dependencias transitivas y los paquetes restaurados desde cachés, con un estado de completitud para cada job. Reevalúa de forma continua las SBOM monitorizadas, de modo que un nuevo aviso aparece en los builds a los que afecta, y los equipos de seguridad priorizan cada hallazgo y lo envían al equipo responsable de la corrección.

Esa es la lista de la que debería partir una corrección con IA y, una vez fusionada la corrección, la SBOM del siguiente build muestra si la versión corregida es la que el build usó realmente. Consulte seguimiento de vulnerabilidades para conocer la funcionalidad completa, y IA frente a seguridad determinista para ver dónde encaja cada enfoque.

Corrección de vulnerabilidades con IA: preguntas frecuentes

¿Qué es la corrección de vulnerabilidades con IA?

La corrección de vulnerabilidades con IA utiliza un modelo de lenguaje para producir la corrección de una vulnerabilidad: un cambio de código para un hallazgo de análisis estático, o una actualización de dependencia junto con los cambios de código que esa actualización requiere. El resultado suele ser una sugerencia o una pull request que revisa una persona.

¿Qué es la corrección agéntica?

La corrección agéntica da a un agente de IA las herramientas para llevar una corrección por varios pasos por sí mismo: leer el hallazgo, cambiar el código, ejecutar el build y los tests, e iterar hasta que pasen, y después abrir una pull request. La diferencia con una sugerencia única es que el agente comprueba su propio trabajo antes de que lo vea una persona.

¿Es seguro fusionar correcciones de seguridad generadas por IA?

Trátelas como la pull request de cualquier otro colaborador. GitHub describe Copilot Autofix como no determinista y advierte de que puede sugerir dependencias inventadas, así que revise el cambio, ejecute los tests y compruebe que cada paquete que añade existe y es el que usted espera.

¿Puede la IA encontrar vulnerabilidades en las dependencias?

Para esa parte es la herramienta equivocada. Saber si una versión de un paquete está afectada por un aviso conocido es una consulta, y debería dar el mismo resultado cada vez. Deje que herramientas deterministas produzcan la lista de paquetes vulnerables a partir de una SBOM registrada, y use la IA donde el criterio ayuda: escribir y adaptar la corrección.

¿Qué necesita una herramienta de corrección con IA para funcionar bien?

Una lista precisa de lo que es realmente vulnerable, un build y un conjunto de tests con los que probar la corrección, y una persona que decida la fusión. Lo primero es lo que falta con más frecuencia: una pull request de corrección para un paquete que el producto no distribuye es ruido, y un paquete vulnerable que el inventario pasó por alto nunca recibe una.