Comparamos Corgea y Aikido con latiotech/insecure-kubernetes-deployments, un repositorio deliberadamente vulnerable con debilidades de aplicaciones, API, JavaScript, Kubernetes y configuración.
El resultado no fue ajustado. Aikido produjo un conjunto de hallazgos más pequeño y limpio. Corgea encontró las vulnerabilidades.
De 47 problemas confirmados en el código fuente, Corgea encontró 42. Aikido encontró 13. Corgea alcanzó un 89,36% de recall y un 85,71% de F1. Aikido alcanzó un 27,66% de recall y un 41,94% de F1.
Corgea found 42 of 47; Aikido found 13
El mismo repositorio deliberadamente vulnerable, el mismo proceso de revisión, 47 problemas confirmados en el código fuente. Aikido fue algo más limpio por hallazgo informado, pero Corgea encontró muchas más de las vulnerabilidades que necesitaban remediación.
3,23 veces el recall de Aikido, 2,04 veces su F1 y 29 vulnerabilidades confirmadas más encontradas.
| Tool | Findings reviewed | TP | FP | FN | Precision | Recall | F1 |
|---|---|---|---|---|---|---|---|
| Corgea | 51 | 42 | 9 | 5 | 82.35% | 89.36% | 85.71% |
| Aikido | 15 | 13 | 2 | 34 | 86.67% | 27.66% | 41.94% |
Scoring set: 47 source-confirmed issues reviewed on July 2, 2026. Precision = TP / (TP + FP), recall = TP / (TP + FN), F1 = harmonic mean of precision and recall.
Aikido fue ligeramente más limpio; Corgea fue mucho más completo
Bubble position shows precision and recall. Bubble size shows confirmed true positives. The upper-right corner is the goal: high confidence and broad vulnerability discovery.
Precision and recall use the same July 2, 2026 scoring set of 47 source-confirmed issues.
Consulta este benchmark en tu repositorio
Ejecuta la misma evaluación cara a cara en un repositorio sensible para la seguridad de tu cartera y compara hallazgos confirmados, recall y flujo de correcciones.
La distinción importante es simple: Aikido tuvo una precisión ligeramente mayor, pero no detectó 34 vulnerabilidades confirmadas. En un programa de remediación real, una vulnerabilidad no detectada no entra en el backlog, no se asigna y no se corrige. La limitación es la capa de análisis estático tradicional de Aikido basada en OpenGrep: útil para patrones conocidos y reglas de fuente a receptor, pero más débil cuando el escáner necesita un contexto más amplio del repositorio, comprensión de frameworks y razonamiento sobre lógica de aplicación personalizada.
Configuración del benchmark
Comparamos los resultados de análisis de Corgea y Aikido del 2 de julio de 2026.
Cada hallazgo se revisó frente al código fuente y se clasificó como:
| Clasificación | Significado |
|---|---|
| Verdadero positivo | La vulnerabilidad informada, o una debilidad directamente equivalente, está presente en el código fuente. |
| Falso positivo | El informe no tiene respaldo, está materialmente mal clasificado, se duplica bajo la clase equivocada o apunta a código no vulnerable. |
| Falso negativo | Un problema de benchmark confirmado en el código fuente que la herramienta no informó. |
El conjunto de puntuación contenía 47 problemas de seguridad de aplicaciones y configuración confirmados en el código fuente. La precisión, el recall y F1 usaron definiciones estándar.
Como este era el repositorio de benchmark Latio de James Berthoty, el corpus de prueba era intencionalmente ruidoso y amplio. El repositorio describe claramente su propósito:
“Probar cada tipo de escáner de configuración contra un único repositorio cómicamente inseguro con problemas documentados.”
Eso es precisamente lo que lo hace útil para una comparación cara a cara: el benchmark no está optimizado para una clase estrecha de vulnerabilidades ni para la ruta preferida de un escáner.
Por qué el recall decidió el benchmark
Los equipos de seguridad sí se preocupan por los falsos positivos. Un escáner ruidoso pierde la confianza de los desarrolladores. Pero en este benchmark, la diferencia de precisión fue pequeña: Aikido obtuvo un 86,67% de precisión y Corgea un 82,35%.
La diferencia de recall fue enorme. Corgea encontró 42 problemas confirmados. Aikido encontró 13. Esa es la historia operativa.
Una pequeña ventaja de precisión no compensó 34 omisiones
La salida de Aikido tuvo menos falsos positivos, pero su análisis SAST dejó atrás la mayoría de los problemas confirmados. Para la planificación de remediación, las vulnerabilidades no detectadas son el mayor riesgo operativo.
Ejemplos que Corgea encontró y que no figuraban en los resultados de Aikido:
- Missing authorization on data-modifying FastAPI routes
- SSRF in a URL fetch endpoint
- Open redirect through an unvalidated next parameter
- Lodash template code injection
- Prototype pollution risk around JSON5 parsing
- Hardcoded AWS credentials in Kubernetes deployment templates
- Hardcoded API tokens in test code
Each stacked bar totals 47 source-confirmed issues. Found percentages: Corgea 89%, Aikido 28%.
La salida más limpia de Aikido significó menos informes incorrectos que clasificar. Pero el precio de esa salida limpia fue 34 vulnerabilidades confirmadas no detectadas, incluida la falta de autorización, SSRF, redirección abierta, inyección de código de plantillas, contaminación de prototipos y credenciales codificadas.
Por qué SAST al estilo OpenGrep no fue suficiente
OpenGrep es un motor de análisis estático útil y el SAST tradicional sigue importando. Es rápido, dirigido por reglas y bueno para detectar patrones inseguros reconocibles. Eso explica por qué Aikido encontró problemas reales como inyección SQL, inyección de comandos y XXE.
La limitación es depender de ese estilo de análisis como capa principal para la seguridad de código personalizado. Los motores de reglas y patrones al estilo OpenGrep pueden tener dificultades cuando la vulnerabilidad depende del contexto de la aplicación, convenciones de frameworks, límites de autorización o razonamiento entre varios archivos. Esas son precisamente las categorías donde Aikido no tuvo cobertura en este benchmark.
El enfoque de Corgea es distinto: Corgea AI SAST combina análisis estático con contexto de código, alcanzabilidad y razonamiento nativo de IA. La arquitectura se trata en el whitepaper de BLAST sobre SAST con IA, y el cambio más amplio de reglas a análisis nativo de IA se explica en Las tres olas de SAST. Si estás creando una rúbrica de evaluación, combina este benchmark con cómo evaluar herramientas SAST nativas de IA y cómo reducir falsos positivos en SAST.
Lo que los compradores deben preguntar tras distinguir OpenGrep de Code Audit
En una discusión reciente de Reddit sobre Aikido, el CEO de Aikido afirmó que el SAST predeterminado se basa en OpenGrep y que Code Audit es la ruta basada en IA para vulnerabilidades más complejas, como problemas de lógica de negocio o filtraciones de datos entre tenants. Esa respuesta pública es útil porque explica por qué un comprador podría obtener resultados muy distintos según la capa que probó.
La distinción importa porque los equipos no deben comparar la capa de análisis más profunda de un proveedor con el flujo SAST incluido de otro sin comprobar el empaquetado, el modelo de uso y el coste. Una PoC que solo puntúa el análisis predeterminado puede subestimar la capacidad ante problemas difíciles. Una PoC que solo puntúa Code Audit puede sobrestimar lo que se ejecuta en cada pull request.
Antes de comprar, pregunta:
- ¿Qué capa de análisis está incluida en el plan que estás cotizando?
- ¿Cuándo se ejecuta Code Audit y se activa manualmente, bajo demanda o en CI?
- ¿El análisis de IA más profundo se mide por créditos, tamaño del repositorio o frecuencia de análisis?
- ¿Cómo debería el comprador puntuar Code Audit frente a problemas conocidos sembrados en el mismo repositorio usado para el SAST predeterminado?
Estas preguntas convierten una comparación de funciones en una comparación de flujos de trabajo, que es lo que realmente operan los equipos de seguridad.
Corgea también lideró el benchmark de corrección automática de Latio
La profundidad de detección importa más cuando el escáner también puede ayudar a los desarrolladores a corregir lo que encuentra. En un benchmark independiente de corrección automática de Latio Tech, James Berthoty puntuó a los proveedores según puntuación final: cobertura x calidad. Corgea ocupó el puesto n.º 1 con una puntuación de 719. Aikido ocupó el puesto n.º 6 con 336.
Latio ranked Corgea #1 and Aikido #6 for SAST auto-fixing
James Berthoty at Latio Tech scored 7 auto-fix vendors by final score: Coverage x Quality. Corgea led with 719; Aikido ranked #6 with 336.
"pretty mindblowing in a lot of respects"
Latio highlighted Corgea for a robust LLM-based SAST scanner, simple developer experience, strong explanations, contextual policy work, and an agentic prompting approach across fixes, validation, and code context.
"fix coverage was low"
Latio noted that Aikido was rapidly improving and prioritized accuracy by rolling out fixes rule by rule, but its lower coverage limited the final score.
Source: Actually Useful Product Guide by James Berthoty at Latio Tech. Full 7-vendor benchmark shown; non-Corgea/non-Aikido rows are muted to keep the comparison focused. Read Corgea's summary of the report here.
La corrección automática debe probarse sobre comportamiento, no errores de demostración
Un profesional del hilo de Reddit informó que Aikido Autofix resolvía algunos patrones simples de inyección SQL, pero generaba preocupación en comprobaciones de lógica de negocio, mientras que la integración CI y el soporte fueron vistos positivamente. El CEO de Aikido dijo que Autofix se ha renovado desde entonces como un sistema más agéntico que puede escribir pruebas.
Ese intercambio es un recordatorio útil para cualquier comparación de proveedores, incluida esta. Las demostraciones de corrección automática suelen verse mejor en muestras de inyección estrechas. El riesgo de producción aparece cuando una corrección cambia la validación, autorización o flujo de control alrededor de la línea vulnerable.
La conclusión justa para un comprador es probar la calidad de las correcciones con preservación de comportamiento, no solo comprobar si aparece un parche. Durante una PoC, puntúa cada corrección según:
- ¿La corrección cerró la vulnerabilidad?
- ¿Las pruebas pasaron y se generaron pruebas nuevas cuando correspondía?
- ¿La corrección introdujo un riesgo nuevo, como comprobaciones omitidas o valores predeterminados inseguros?
- ¿El diff es mínimo y revisable para tus desarrolladores?
- ¿La corrección preservó la lógica de negocio y el comportamiento de autorización?
El benchmark de corrección automática de Latio anterior ofrece una vista estructurada de cobertura y calidad. Tu propio repositorio sigue siendo la prueba decisiva para saber si los desarrolladores aceptarán y fusionarán los parches.
Donde ambas herramientas coincidieron
Ambas herramientas encontraron vulnerabilidades importantes en el repositorio de benchmark.
Para la inyección SQL en insecure-js/server.js, una entrada controlada por el usuario llegaba a una cadena de consulta:
const query = `SELECT product FROM Orders WHERE orderNumber = ${postData.orderNumber};`;
const result = await sequelize.query(query, {
type: sequelize.QueryTypes.SELECT,
});Para la inyección de comandos del sistema operativo en insecure-app/app.py, la entrada de la solicitud llegaba a un comando de shell con shell=True:
cmd = request.form["command"]
process = subprocess.Popen(
cmd, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE
)Para XXE, la aplicación Flask analizaba XML controlado por el usuario con carga de DTD y resolución de entidades habilitadas:
xml_data = request.form["xml"]
parser = etree.XMLParser(load_dtd=True, resolve_entities=True)
tree = etree.fromstring(xml_data.encode(), parser)Estos son hallazgos reales. Aikido merece reconocimiento por detectarlos.
Lo que Corgea encontró y Aikido no detectó
La brecha significativa fue la cobertura del resto del repositorio.
Corgea identificó un endpoint FastAPI que modifica datos sin autenticación ni autorización:
@app.put("/games/{game_id}")
def modify_game(game_id: int, updated_game: VideoGame):
for i, game in enumerate(video_games):
if game.id == game_id:
video_games[i] = updated_game
return {"message": "Game updated"}Corgea también encontró rutas SSRF y de redirección abierta:
@app.get("/fetch_url")
def retrieve_content(url: str):
response = requests.get(url)
return {"content": response.text}
@app.get("/redirect")
def navigate_to(next: str):
return RedirectResponse(url=next)En JavaScript, Corgea informó inyección de código de plantillas lodash:
const compiled = _.template(postData.template);
const output = compiled({});Y encontró credenciales expuestas fuera del código principal de la aplicación, incluidas plantillas de despliegue de Kubernetes:
- name: AWS_ACCESS_KEY_ID
value: AKIA2JAPX77RGLB664VE
- name: AWS_SECRET_ACCESS_KEY
value: v5xpjkWYoy45fGKFSMajSn+sqs22WI2niacX9yO5Aquí es donde el benchmark pasó de «qué escáner es más ordenado» a «qué escáner proporciona a un equipo los problemas que necesita corregir».
Lo que Aikido encontró y Corgea no detectó
No fue una goleada. Aikido informó correctamente varios hallazgos relevantes que faltaban o eran menos específicos en los resultados de Corgea.
Identificó deserialización Java insegura:
ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(data));
Object deserializedObject = ois.readObject();También identificó verificación TLS desactivada:
response = requests.post(url, headers=headers, data=data, verify=False)E informó un receptor de inyección HTML del lado del cliente en la interfaz de la aplicación de IA:
resultContent.innerHTML = marked.parse(data.result);Estos son errores reales de Corgea. La diferencia está en la escala: Aikido no detectó 34 problemas confirmados; Corgea no detectó 5.
El problema de coste de AI Code Audit
Aikido tiene un producto más reciente de AI Code Audit, pero en la cuenta del benchmark se medía por separado del análisis SAST normal. La interfaz mostró la auditoría completa de AI Code Audit para este repositorio en 20 créditos. El diálogo de compra mostró créditos a 1 $ cada uno, con una compra mínima de 100 créditos.
Eso significa que esta auditoría de benchmark habría costado 20 $ por ejecución, y se invitaba a la cuenta a una compra de créditos de 100 $. El AI SAST de Corgea está incluido en el paquete para desarrolladores.
Esto importa porque la auditoría de IA se consideraba precisamente donde el resultado SAST de base de Aikido era más débil. Pagar por uso por el análisis más profundo es una disyuntiva difícil cuando el análisis SAST normal encontró solo 13 de 47 problemas confirmados.
Aikido's AI Code Audit was metered separately in this run
The benchmark account showed a 20-credit AI Code Audit for this repository. At $1 per credit, that is $20 for the audit, with a 100-credit minimum purchase shown in the checkout dialog.
Cost notes are based on the Aikido in-product screens captured during the July 2, 2026 benchmark run.
Evidencia de capturas de pantalla de la ejecución
Las capturas proporcionadas se organizan a continuación en salida de análisis y evidencia de coste de auditoría. La cuestión no es que una interfaz se vea mejor. La cuestión es que el resultado del benchmark y el modelo de costes deben evaluarse juntos.
Side-by-side scan output from the benchmark
The screenshots below are organized around the benchmark narrative: Aikido's SAST issue list, then Corgea's scanner category view for the same deliberately vulnerable repository.
Recomendación
Para este benchmark, Corgea es el competidor SAST más sólido. Encontró muchas más vulnerabilidades confirmadas, logró un recall mucho mayor y obtuvo la mejor puntuación F1.
La salida de Aikido fue más limpia y tuvo una precisión ligeramente superior, por lo que puede requerir menos triaje por hallazgo informado. Pero esa ventaja no compensó el riesgo de vulnerabilidades no detectadas. Un escáner que informa menos problemas incorrectos pero pierde la mayoría de los problemas confirmados deja al equipo de seguridad con una falsa sensación de progreso.
Si estás evaluando Aikido porque buscas cobertura AppSec amplia y todo en uno, prueba su profundidad SAST por separado. Si tu prioridad es encontrar y corregir riesgos reales de código personalizado, ejecuta Corgea y Aikido en los mismos repositorios, etiqueta los resultados frente al código fuente y puntúa verdaderos positivos, falsos positivos, falsos negativos, recall y F1.
Si ya estás realizando una PoC de Aikido, invita a Corgea a la misma evaluación y puntúa ambas herramientas según hallazgos confirmados, problemas conocidos no detectados, falsos positivos, calidad de las correcciones y coste total de uso.
En este repositorio, Corgea ganó.
Consulta este benchmark en tu repositorio
Realiza un piloto con tu propio código y mide hallazgos confirmados, problemas no detectados, calidad de las correcciones y coste total.
Para una comparación más amplia de proveedores, consulta las mejores alternativas a Aikido y la página de comparación Corgea vs. Aikido.
Corgea no está afiliada a Aikido. Este benchmark refleja el repositorio, los resultados de análisis y las pantallas de producto revisadas el 2 de julio de 2026.