Cómo reducir el tiempo de revisión de seguridad conectando LLM API al escaneo de vulnerabilidades de código abierto

El código abierto es conveniente, pero igualmente peligroso. Según una investigación de 2025, a medida que la IA comenzó a escribir código por nosotros, la tasa de errores se disparó un 41% en comparación con el año anterior. Para un responsable de seguridad que debe revisar decenas de miles de líneas de librerías externas por sí solo, esto es nada menos que un desastre. Como es imposible leer todo el código, debemos poner a la IA de nuestro lado. Aquí explicamos cómo crear un flujo de trabajo de seguridad que funcione de manera inteligente, tal como lo hace Project Glasswing.

Instalación de un motor de seguridad de IA en GitHub Actions

Automatizar la revisión de seguridad permite eliminar las tareas repetitivas a las que se dedicaban más de 10 horas semanales. También previene errores humanos que ocurren al revisar superficialmente con la vista. Construya un pipeline que llame a una LLM API en el entorno de GitHub Actions para escanear en tiempo real cada vez que se sube un Pull Request. La clave es una estrategia que separe la identificación de la auditoría, en lugar de simplemente hacer preguntas.

• Protección de la clave API: Registre su LLM_API_KEY en GitHub Secrets. Debe guardarse en el almacenamiento cifrado de Libsodium para evitar filtraciones accidentales de la clave al exterior.
• Configuración de directorios objetivo: No es necesario revisar todos los archivos. Use path-filter en la configuración YAML para seleccionar y escanear solo directorios sensibles donde un incidente sería catastrófico, como src/auth o lib/core.
• Validación cruzada: En la primera etapa, deje que el LLM analice la estructura del código y escriba notas; luego, en la segunda etapa, ejecute escaneos repetitivos (al menos 3 veces) basados en esas notas. Dado que la IA a veces puede alucinar, es necesario un proceso de contrastar resultados varias veces.

Una vez terminada esta configuración, el responsable de seguridad solo tendrá que revisar el informe de seguridad resumido por la IA en lugar de miles de líneas de código.

Selección de las amenazas reales mediante CVSS y EPSS

Las herramientas de IA son buenas encontrando vulnerabilidades, pero también generan muchos falsos positivos. Si se encuentran 100 y 15 son falsos, el equipo de desarrollo inevitablemente se sentirá frustrado. Para no desperdiciar recursos limitados de desarrollo, se necesita un criterio para distinguir las amenazas reales. Establezca prioridades mezclando la puntuación CVSS 4.0 con el indicador EPSS, que informa si se están produciendo ataques reales en la actualidad.

1. Verificación de la puntuación base: Primero observe la gravedad técnica con el CVSS 4.0 Base Score.
2. Ajuste de la puntuación ambiental: Reste o sume puntos dependiendo de si ese código es una función expuesta a la internet pública o si solo corre en la red interna.
3. Contraste con la probabilidad de ataque: Consulte la base de datos EPSS para verificar si esa vulnerabilidad es tendencia entre los atacantes. Si la probabilidad de ataque supera el 50%, debe dejar todo lo demás de lado y aplicar el parche de inmediato.

Concentrarse solo en las calificaciones de urgencia de 9.0 o más elevará drásticamente el nivel de seguridad. Al reducir las solicitudes de corrección innecesarias, las fricciones con el equipo de desarrollo también disminuirán de forma natural.

Validación y despliegue del código de parche en un Sandbox

Las correcciones propuestas por la IA pueden parecer perfectas, pero a veces rompen funciones que estaban bien. Empresas como Shopify también usan IA, pero no confían ciegamente en el código generado. Debe existir un procedimiento para verificar automáticamente si el código del parche es seguro en entornos aislados como Firecracker o gVisor.

• Creación de entorno aislado: Use sbx CLI para levantar una MicroVM que tenga exactamente el mismo entorno de ejecución (runtime) que el servicio actual.
• Simulación de ataque: Verifique si la vulnerabilidad es realmente explotable con un script de ataque; luego, aplique el parche sugerido por la IA y vuelva a atacar para comprobar si se detiene.
• Pruebas funcionales: Ejecute las pruebas unitarias existentes con el parche aplicado. No sirve de nada bloquear la seguridad si el inicio de sesión deja de funcionar.

Este tipo de salvaguardas evitan accidentes donde código de IA "casi correcto pero sutilmente erróneo" llegue al servidor de producción.

Redacción de informes que los mantenedores de código abierto acepten de inmediato

No debemos limitarnos a arreglar solo nuestro servicio. También es labor del responsable de seguridad reportar los defectos del propio código abierto a los proyectos originales (upstream). Los mantenedores son personas ocupadas, por lo que se deben proporcionar argumentos claros. Utilice los canales PVR de GitHub para entregar el informe de manera responsable.

En el título, especifique claramente el tipo de vulnerabilidad y su ubicación. Es fundamental adjuntar una ruta de reproducción que cualquiera pueda seguir y capturas de pantalla. Lo mejor es enviar junto con el reporte el código de corrección que validó previamente en el sandbox. Si les ahorra tiempo de revisión, la probabilidad de que se aplique el parche aumentará exponencialmente. Un informe bien elaborado demuestra la capacidad tecnológica de la empresa e incluso puede resultar en la obtención de un número CVE oficial.