Corgea vs. Snyk: Comparamos SAST en un repositorio deliberadamente vulnerable

Comparamos Corgea y Snyk con latiotech/insecure-kubernetes-deployments, un repositorio deliberadamente vulnerable con debilidades de aplicaciones, API, JavaScript, Java, Kubernetes y configuración. Usamos la misma base de benchmark fija que nuestra comparación de Corgea vs. Aikido, por lo que los resultados son directamente comparables.

Corgea obtuvo el mejor resultado global. De 47 problemas confirmados en el código fuente, Corgea encontró 42 y Snyk encontró 26. Corgea alcanzó un 89,36% de recall y un 85,71% de F1, y también superó a Snyk en precisión: 82,35% frente a 78,79%. Snyk alcanzó un 55,32% de recall y un 65,00% de F1.

Winner by F1 and recall Corgea

1,6 veces el recall de Snyk, 1,3 veces su F1, 16 vulnerabilidades confirmadas más encontradas y mayor precisión con la misma base de benchmark.

47 source-confirmed issues

Confirmed findings

42 vs 26

False negatives

5 vs 21

F1 score

85.71% vs 65.00%

Recall Confirmed vulnerabilities caught

Corgea 89.36%

Snyk 55.32%

F1 score Balance of precision and recall

Corgea 85.71%

Snyk 65.00%

Precision Reported findings that were confirmed

Corgea 82.35%

Snyk 78.79%

Tool	Findings reviewed	TP	FP	FN	Precision	Recall	F1
Corgea	51	42	9	5	82.35%	89.36%	85.71%
Snyk	33	26	7	21	78.79%	55.32%	65.00%

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.

Corgea 82.35% precision 89.36% recall 42 true positives

Snyk 78.79% precision 55.32% recall 26 true positives

Bubble area: confirmed true positives. The shaded upper-right zone represents 75%+ precision and 75%+ recall. Takeaway: Snyk se mantuvo por debajo del 80% de precisión y no detectó casi la mitad de los problemas confirmados; Corgea entró en la zona de alto recall manteniendo una precisión superior al 80%.

Precision and recall use the same July 2, 2026 scoring set of 47 source-confirmed issues.

Snyk encontró varios problemas relevantes que Corgea no detectó, pero no detectó una mayor parte del conjunto fijo de benchmark confirmado en el código fuente. La historia operativa es la cobertura: una vulnerabilidad que un escáner nunca informa no entra en el backlog, no se asigna y no se corrige.

Configuración del benchmark

Comparamos la exportación de Corgea corgea_682cea3f-1429-450e-9449-1f2469ce8778.csv con los hallazgos de Snyk proporcionados para este repositorio, ambos del 2 de julio de 2026.

Cada hallazgo se revisó frente al código fuente local 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 una segunda clase de hallazgo sin añadir cobertura, o apunta a código donde el riesgo indicado no aplica.
Falso negativo	Un problema de benchmark confirmado en el código fuente que la herramienta no informó.

El conjunto de puntuación contenía los mismos 47 problemas de seguridad de aplicaciones y configuración confirmados en el código fuente usados en el informe limpio de Corgea vs. Aikido. Para mantener una comparación equivalente, los hallazgos suplementarios solo de Snyk no se añadieron al denominador del benchmark. Snyk proporcionó 43 filas: 33 se reflejan en la tabla de métricas de alcance fijo, mientras que 10 filas solo de Snyk confirmadas en el código fuente se analizan a continuación como observaciones suplementarias y no se contabilizan como falsos positivos. La precisión, el recall y F1 usaron definiciones estándar:

• Precisión: TP / (TP + FP)
• Recall: TP / (TP + FN)
• F1: 2 × Precisión × Recall / (Precisión + Recall)

Por qué Corgea quedó por delante

A diferencia de la ejecución de Aikido, donde las dos herramientas intercambiaron una ventaja en precisión por una brecha en recall, Corgea lideró a Snyk en cada métrica principal. El factor decisivo siguió siendo la cobertura: Corgea encontró 42 de los 47 problemas confirmados; Snyk encontró 26.

Corgea 42 found · 5 missed

42 5

Snyk 26 found · 21 missed

26 21

16 more true positives 16 fewer false negatives 1.6x recall

Ejemplos que Corgea encontró y que no figuraban en los resultados de Snyk:

• Missing authorization on data-modifying FastAPI routes
• XML external entity processing in the Flask app
• Prototype pollution risk around JSON5 parsing
• Sensitive API data exposure without authorization
• Credential exposure in deployment and test configuration

Each stacked bar totals 47 source-confirmed issues. Found percentages: Corgea 89%, Snyk 55%.

Corgea obtuvo mejores resultados porque cubrió más clases de vulnerabilidades en una mayor parte del repositorio:

• Problemas de control de acceso en rutas FastAPI, incluida la falta de autorización para modificar datos y la exposición de usuarios/tokens.
• Problemas de JavaScript más allá de la inyección SQL, incluida la contaminación de prototipos y la inyección de código de plantillas.
• Configuración incorrecta del analizador XML en la aplicación Flask.
• Exposición de credenciales en la configuración de despliegue y pruebas.
• Redirección abierta, SSRF, inyección de comandos, inyección SQL y XSS en varios servicios.

Las áreas más sólidas de Snyk fueron los hallazgos de flujo de contaminación en controladores de solicitudes, credenciales codificadas, deserialización de Java, construcción insegura de rutas de carga, verificación de certificados TLS desactivada y receptores DOM XSS del lado del cliente.

Donde ambas herramientas coincidieron

Ambas herramientas encontraron vulnerabilidades importantes en el repositorio de benchmark.

Para la inyección SQL en el endpoint de búsqueda FastAPI, una entrada controlada por la solicitud llegaba directamente a una cadena de consulta:

# insecure-api/main.py
sql_query = f"SELECT * FROM video_games WHERE title = '{query}'"
cursor.execute(sql_query)

Para la inyección de comandos del sistema operativo en la aplicación Flask, la entrada de la solicitud llegaba a un comando de shell con shell=True:

# insecure-app/app.py
cmd = request.form["command"]
process = subprocess.Popen(
    cmd, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE
)

Para SSRF, un endpoint obtenía del lado del servidor una URL controlada por el llamador sin validar el host ni el esquema:

# insecure-api/main.py
@app.get("/fetch_url")
def retrieve_content(url: str):
    response = requests.get(url)
    return {"content": response.text}

Y ambas identificaron la redirección abierta en el servicio FastAPI:

# insecure-api/main.py
@app.get("/redirect")
def navigate_to(next: str):
    return RedirectResponse(url=next)

Estos son hallazgos reales y Snyk merece reconocimiento por detectarlos.

Lo que Corgea encontró y Snyk 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:

# insecure-api/main.py
@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"}

Marcó una configuración insegura de analizador XML sobre XML controlado por la solicitud, con carga de DTD y resolución de entidades habilitadas:

# insecure-app/app.py
xml_data = request.form["xml"]
parser = etree.XMLParser(load_dtd=True, resolve_entities=True)
tree = etree.fromstring(xml_data.encode(), parser)

En JavaScript, Corgea identificó riesgo de contaminación de prototipos al analizar JSON5 controlado por el usuario:

// insecure-js/server.js
const parsedObject = JSON5.parse(postData.json5data);

Corgea también informó exposición de datos API sensibles, donde una ruta devuelve registros de usuario sin autorización:

# insecure-api/main.py
@app.get("/users")
def list_users():
    return users

Y encontró exposición de credenciales en la configuración de despliegue y pruebas, fuera del código fuente principal de la aplicación:

# insecure-chart/templates/insecure-app.yaml
- name: AWS_ACCESS_KEY_ID
  value: "<redacted>"
- name: AWS_SECRET_ACCESS_KEY
  value: "<redacted>"

Estas áreas no estaban representadas en los hallazgos de Snyk proporcionados.

Lo que Snyk encontró y Corgea no detectó

No fue una goleada. Snyk informó correctamente varios hallazgos relevantes que faltaban o eran menos específicos en los resultados de Corgea.

Identificó deserialización de Java controlada por la solicitud:

// insecure-java/src/main/java/com/example/insecurejava/UnsafeDeserializationController.java
ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(data));
Object deserializedObject = ois.readObject();

Informó verificación de certificados TLS desactivada en solicitudes salientes:

# insecure-app/app.py
response = requests.post(url, headers=headers, data=data, verify=False)

Marcó construcción insegura de ruta de carga, donde un nombre de archivo controlado por la solicitud se une a una ruta del sistema de archivos antes de guardarse:

# insecure-app/app.py
uploaded_file = request.files["file"]
uploaded_file.save(os.path.join(UPLOADS_DIR, uploaded_file.filename))

Identificó receptores DOM XSS del lado del cliente, con contenido devuelto por el servidor asignado directamente a innerHTML:

// insecure-ai/templates/index.html
if (data.status === "error") {
    resultContent.innerHTML = `<div class="text-red-600">Error: ${data.result}</div>`;
} else {
    resultContent.innerHTML = marked.parse(data.result);
}

Encontró divulgación de detalles de errores orientados al usuario, donde los detalles de excepciones y los seguimientos de pila se devuelven a los llamadores:

# insecure-ai/app.py
error_msg = f"Error processing code: {str(e)}\n{traceback.format_exc()}"
return jsonify({"error": error_msg}), 500

Y encontró credenciales de semilla y base de datos codificadas que no estaban representadas en la exportación de Corgea:

// insecure-java/src/main/java/com/example/catapp/config/DataInitializer.java
createUser("admin", "<redacted>")

// insecure-js/server.js
const connection = mysql.createConnection({
  host: "localhost",
  user: "root",
  password: "<redacted>",
});

Estos son errores reales de Corgea. La diferencia está en la escala: Snyk no detectó 21 problemas confirmados; Corgea no detectó 5.

El perfil de falsos positivos

Snyk tuvo siete falsos positivos en esta revisión. Los patrones principales fueron:

• Un hallazgo de XSS en la respuesta de deserialización Java, donde la respuesta es un cuerpo de cadena y el problema principal admitido es la deserialización insegura, no el renderizado HTML.
• Un hallazgo por vincularse a 0.0.0.0; en un servicio contenerizado esto suele ser necesario para el enrutamiento y no es, por sí solo, una vulnerabilidad.
• Un hallazgo de asignación de recursos en el punto de entrada genérico del servidor HTTP que no apuntaba a una operación costosa ilimitada claramente explotable.
• Tres hallazgos de credenciales codificadas de menor gravedad que duplicaban hallazgos de gravedad media sobre las mismas credenciales de semilla Java.
• Un hallazgo de CSRF en un endpoint REST sin evidencia de autenticación de navegador con estado, lo que deja sin respaldo el riesgo de CSRF indicado.

Los nueve falsos positivos de Corgea fueron en su mayoría clasificaciones imprecisas, encuadre duplicado o punteros de línea débiles:

• Un hallazgo de complejidad de expresiones regulares apuntaba a un valor de muestra en un formulario HTML, sin ruta de ejecución coincidente.
• Un hallazgo de mecanismo de protección apuntaba a X-XSS-Protection: 0; este encabezado de navegador heredado está obsoleto y no es una vulnerabilidad independiente sólida.
• Clasificaciones de omisión de autenticación que duplicaban problemas SSRF o de redirección abierta bajo la clase incorrecta.
• Un hallazgo de autenticación basada en referer apuntaba a un endpoint SSRF que no usaba el encabezado Referer para autenticación.
• Un hallazgo de CSRF apuntaba cerca de una ruta de estado en lugar de una acción que cambia el estado.
• Un hallazgo de información confidencial de código fuente apuntaba a una cadena estática orientada al usuario, no a un secreto.
• Un hallazgo de deserialización apuntaba a un archivo auxiliar independiente en lugar del controlador que maneja solicitudes.

Recomendación

Para este benchmark, Corgea encaja mejor cuando el objetivo es el descubrimiento amplio de vulnerabilidades y la cobertura de remediación. Encontró más problemas confirmados y produjo la puntuación F1 más alta con la misma base de benchmark usada en la comparación con Aikido.

Snyk sigue siendo valioso como señal complementaria. Encontró varios problemas importantes que Corgea no detectó, especialmente deserialización Java, verificación TLS desactivada, DOM XSS del lado del cliente, construcción insegura de rutas de carga y credenciales de aplicaciones y bases de datos codificadas.

La limitación de basarse en SAST tradicional de flujo de contaminación como capa principal es la cobertura: es bueno para patrones reconocibles de fuente a receptor, pero más débil cuando una vulnerabilidad depende del contexto de la aplicación, convenciones de frameworks, límites de autorización o razonamiento entre varios archivos. 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.

En este repositorio, Corgea ganó, gracias a un recall mayor, una precisión mayor y la puntuación F1 más alta.

Para una comparación más amplia de proveedores, consulta las mejores alternativas a Snyk y la página de comparación Corgea vs. Snyk.

Corgea no está afiliada a Snyk. Este benchmark refleja el repositorio, la exportación y los hallazgos revisados el 2 de julio de 2026.