Orbis AppSec: una IA que abre pull requests con el arreglo ya escrito
El proyecto encadena escaneo, análisis de contexto y generación de parche para abrir un PR en GitHub. El autor admite fallos y dice que la métrica que le importa no es cuántos fallos detecta.
Orbis AppSec no se conforma con decir que hay una vulnerabilidad en el repositorio. El sistema, presentado por su propio autor y distribuido como GitHub App, encadena el escaneo, la interpretación del contexto del código, la generación de un parche y la apertura de un pull request, y deja la decisión final a quien mantiene el repositorio. La premisa es que el cuello de botella en AppSec ya no está en detectar, sino en arreglar sin romper nada.
El punto de partida es razonable y conocido por cualquiera que haya llevado un programa de seguridad: el escáner avisa del fallo, pero alguien tiene que decidir si es explotable, si es un falso positivo, cuál es la corrección correcta para ese código concreto, qué dependencias o configuración se ven afectadas y si el cambio rompe algo. El flujo propuesto intenta cubrir esos pasos y entregar un PR revisable en lugar de otro informe.
Lo que miden no son las vulnerabilidades
El autor insiste en que la cifra interesante no es cuántos fallos detecta el sistema, sino qué ocurre después de abrir el PR. Si el mantenedor lo fusiona, pide cambios, lo cierra porque el hallazgo era incorrecto o lo rechaza porque el cambio es demasiado amplio, cada respuesta es una señal sobre la utilidad real de la herramienta. Reconoce fracasos: parches demasiado agresivos, hallazgos discutibles y mantenedores que miran un PR de seguridad automático con desconfianza. Es difícil reprocharles lo último.
La dirección que dice estar tomando es conservadora: entender primero el repositorio, hacer el cambio mínimo defendible y justificar el hallazgo. Eso es una intención declarada, no un resultado medido. El proyecto se distribuye como GitHub App y el autor afirma que en su blog va publicando los PR fusionados. No da cifras de precisión, de falsos positivos ni de cuántos PRs han acabado aceptados, y ningún tercero ha verificado lo que hay publicado.
Queda la pregunta que lanza a los equipos de AppSec y DevSecOps: prefieren que un sistema abra un PR con la corrección propuesta o que solo reporte el fallo y explique cómo arreglarlo a mano. Es la discusión de fondo. Automatizar el parche mueve quién asume la responsabilidad del cambio, y en entornos con revisión obligatoria eso pesa más que la tasa de acierto de un escáner. Para saber si este enfoque aguanta, habrá que ver esos PRs fusionados y, sobre todo, cuántos vuelven rechazados.
