Cómo migrar de Checkmarx a Corgea en menos de 2 semanas

Sustituir Checkmarx One, Checkmarx SAST o CxSAST tiene fama de ser un programa de varios trimestres. Esa reputación proviene de la arquitectura, no del trabajo en sí: una migración de SAST tradicional implica volver a conectar cada pipeline, volver a alojar motores de escaneo y volver a crear años de ajustes acumulados en un nuevo lenguaje de consultas.

Corgea elimina ambas cargas de trabajo. Se conecta al control de código fuente mediante integraciones nativas de API, por lo que no hay ingeniería de pipelines, ni agentes de escaneo que alojar, ni CxFlow que volver a desplegar. Y Auto-Discovery elimina por completo la migración de ajustes, de modo que no es necesario migrar presets, consultas CxQL personalizadas ni supresiones de falsos positivos.

Lo que queda son cinco pasos de trabajo real y concreto que caben en menos de 14 días.

Antes de empezar: reversión y cobertura

Checkmarx sigue funcionando, sin bloquear, durante toda la ventana de migración. Corgea se ejecuta en paralelo y solo se convierte en la puerta de aplicación en el paso 3.

Eso te da dos cosas que un comprador de seguridad necesita. No hay vacío de cobertura: en cada momento de los 14 días, al menos un escáner está analizando cada repositorio dentro del alcance. Y la reversión es un cambio de configuración, no un proyecto: desactiva las reglas de bloqueo de Corgea y Checkmarx sigue escaneando, informando y bloqueando exactamente como lo hacía antes. Archivas Checkmarx al final de la ventana y das de baja la licencia en la renovación, no antes.

Paso 1: comparación de referencia (días 1-2)

No empieces con un escaneo nuevo. Empieza con los resultados de Checkmarx que ya tienes, para que la comparación sea directa sobre el mismo repositorio y el mismo commit.

Corgea ingiere directamente la salida de escáneres de terceros, incluidos Checkmarx JSON, Fortify FPR y Coverity XML (documentación de carga). Genera el informe desde la CLI de Checkmarx y súbelo a Corgea con la CLI de Corgea:

# Genera un informe JSON de Checkmarx para el repositorio objetivo
cx scan create --project-name juice-shop -s . --branch master \
  --scan-types sast --report-format json --output-name report

# Sube los hallazgos de Checkmarx a Corgea
corgea upload report.json --project-name juice-shop

Después, escanea el mismo commit con el propio motor AI SAST de Corgea (corgea scan) para que ambos conjuntos de resultados queden en la misma interfaz sobre código idéntico.

Elige dos o tres repositorios que representen tu cartera real, no el más limpio: un servicio de alto tráfico, una aplicación heredada con un gran número de hallazgos abiertos y un repositorio en el que tus desarrolladores ya desconfían del escáner.

Lo que estás midiendo, por repositorio:

• Verdaderos positivos confirmados. Corgea detecta el doble de verdaderos positivos que un SAST tradicional de forma predeterminada.
• Volumen de falsos positivos. Corgea produce tres veces menos falsos positivos. Medido como tasa, la tasa de verdaderos positivos de Corgea es del 77 % frente al 35 % de Checkmarx.
• Hallazgos que cada herramienta se perdió. Ambas direcciones importan. Anota cualquier hallazgo que Checkmarx marcara y Corgea no, y llévalo a tu contacto en Corgea en lugar de asumir que hay una brecha.

Dos días son suficientes porque el lado de Checkmarx de la comparación es un informe que ya tienes.

Paso 2: conectar el control de versiones de forma nativa (días 2-4)

Este es el paso que suele consumir un trimestre entero, y es el paso que en su mayor parte desaparece.

Corgea se conecta a GitHub (mediante la app de GitHub de Corgea), GitLab, Azure DevOps, Bitbucket y Harness Code a través de la API, usando la instalación de una app o un token de acceso con alcance limitado. Corgea registra sus propios webhooks y escanea ante eventos del repositorio. Para los repositorios que no están dirigidos por eventos, los escaneos programados se ejecutan con una periodicidad delimitada por proyecto, etiqueta o equipo.

En concreto, los siguientes elementos de trabajo de Checkmarx no tienen equivalente que construir en Corgea:

• Ningún paso de escaneo que añadir, versionar y mantener en cada definición de pipeline.
• Ningún despliegue de CxFlow que alojar, configurar y mantener parcheado.
• Ningún motor de escaneo ni pool de motores que dimensionar, licenciar y encolar.
• Ninguna credencial de pipeline distribuida a cada agente de compilación.

El trabajo que queda es real pero limitado: crear la credencial de integración (se recomienda un usuario de servicio dedicado o una cuenta de servicio en GitLab, Bitbucket y Harness), decidir a qué repositorios puede acceder Corgea y confirmar la entrega del webhook en una pull request de prueba. La incorporación es por organización, no por pipeline, por eso esta tarea dura dos días en lugar de un despliegue por equipo.

Paso 3: definir reglas de aplicación y saltarse la migración de ajustes (días 4-6)

Aquí es donde suelen colapsar los planes de migración. El instinto es migrar la configuración acumulada: presets, consultas personalizadas, listas de supresión, umbrales de política. La mayor parte no debería venir contigo.

Los ajustes de Checkmarx existen para compensar un conjunto de reglas genérico que trata por igual un monolito en Django y una aplicación heredada en PHP. Auto-Discovery de Corgea hace ese trabajo antes del primer escaneo: detecta tus lenguajes, frameworks y arquitectura, hace que un agente lea el código base para identificar los controles de seguridad que tus desarrolladores ya construyeron (decoradores de autenticación, uso de ORM, validadores, middleware, configuración de WAF), valida esos patrones y los convierte en políticas de falsos positivos y de corrección específicas del proyecto. Learning convierte después el feedback de los desarrolladores, incluidos los comentarios de falso positivo hechos en las pull requests, en política revisada, de modo que la misma desestimación no vuelva a aparecer en el siguiente escaneo.

Eso cambia lo que migras:

Artefacto de Checkmarx	Equivalente en Corgea	¿Migrarlo?
Presets de escaneo (Default, OWASP Top 10, árboles de presets personalizados)	Auto-Discovery genera política por proyecto a partir de tus frameworks reales	No
Consultas CxQL personalizadas escritas para reducir el ruido	Auto-Discovery más Learning	No
Consultas CxQL personalizadas que codifican lógica de negocio genuinamente particular	Política de PolicyIQ o corgea.yaml en el repositorio, escrita en lenguaje llano	Solo estas
Supresiones “Not Exploitable” / “Proposed Not Exploitable”	Auto-Discovery más Learning; volver a triar en Corgea en lugar de importar	No
Listas de exclusión y filtros de archivos	Reglas de ignorado de archivos (pruebas, node_modules, salida de build y código generado se excluyen por defecto)	Solo rutas específicas del proyecto
Categorías de vulnerabilidad silenciadas	Filtros CWE por proyecto, opcionalmente delimitados por glob	Solo si siguen dentro del alcance
Umbrales de break-build y condiciones de fallo de política	Reglas de bloqueo por CWE y severidad, delimitadas a proyectos o etiquetas de proyecto; corgea scan --fail en CI	Sí

La política de break-build es la única fila que requiere una migración deliberada, porque codifica una decisión que tu organización ya tomó. Crea las reglas de bloqueo y déjalas inactivas mientras Checkmarx siga siendo la puerta de control. Actívalas al final de este paso y deja que Checkmarx continúe en modo solo informe.

Gracias a Auto-Discovery, la personalización de políticas suele ser innecesaria en el momento de la migración. Ejecuta dos semanas de escaneos antes de decidir que necesitas una política personalizada; la mayoría de los equipos descubre que el motivo por el que querían una ya se ha resuelto.

Paso 4: activación de desarrolladores y agentes (días 6-9)

La aplicación sin herramientas para desarrolladores produce la misma desconfianza de la que estás migrando. Despliega tres superficies en paralelo.

IDEs. Las extensiones de VS Code y Visual Studio 2022 listan los hallazgos en una barra lateral, muestran el diff propuesto con su explicación y aplican la corrección en el propio código.

Pull requests. Corgea Agent comenta los hallazgos directamente en el diff de la PR y lee las respuestas. Un desarrollador escribe @Corgea false positive con su razonamiento, o @Corgea accept risk, o @Corgea fixed, y el estado cambia, el hallazgo deja de bloquear el merge y el razonamiento alimenta Learning. La triaje ocurre en la revisión de código en lugar de en una cola independiente. El alcance de escaneo y comentario se controla mediante reglas de PR en PolicyIQ.

Agentes de codificación. El Corgea Agent Skill enseña a Cursor, Claude Code, GitHub Copilot y OpenAI Codex a manejar la CLI: escanear, listar problemas, inspeccionar un hallazgo, obtener la corrección y aplicarla. Instálalo con corgea skill install corgea --agent cursor --scope user. El servidor MCP añade acceso de lectura a escaneos, problemas, datos de dependencias y reglas de bloqueo para cualquier cliente MCP. Consulta experiencia de desarrollador para ver cómo se combina todo esto.

Paso 5: informes, gobernanza y desmantelamiento (días 9-14)

Sustituye las dependencias de informes y gobernanza que tu despliegue de Checkmarx lleva actualmente.

• Ticketing. Conecta Jira y crea tickets desde las páginas de los problemas.
• Exportación. Exportación en SARIF 2.1.0, CSV y PDF para evidencia de cumplimiento y herramientas posteriores.
• Automatización. Webhooks para scan.completed, issue.status_changed y sla.violation hacia tu SIEM o pipeline de GRC.
• Acceso. SSO SAML con exportación de grupos, además de equipos para el acceso a proyectos a escala.
• Rendición de cuentas. Gestión de SLA para ventanas de remediación y escalado por nivel de urgencia, por separado para hallazgos de SAST y SCA.
• Integridad de tendencias. Fingerprinting de problemas usa identidad basada en AST, de modo que un hallazgo sobrevive al reformateo y la refactorización, y tus recuentos de abiertos/corregidos/reabiertos siguen siendo fiables entre escaneos.

Después, cierra Checkmarx. Exporta los hallazgos históricos que estés obligado a conservar, archiva los datos del proyecto, elimina los pasos de pipeline ya sin uso y la infraestructura de CxFlow, y deja que la licencia caduque en la renovación. Haz esto al final, una vez que Corgea haya sido la puerta de aplicación durante varios días y tus informes ya no lean de Checkmarx.

Por qué esto se comprime a 14 días

Nada de esto es sin esfuerzo. Hay cinco pasos de trabajo genuino: credenciales, alcance de la integración, decisiones de aplicación, despliegue para desarrolladores y conexión de gobernanza. Lo que falta son las dos cargas de trabajo que hacen que las migraciones de Checkmarx se sientan como proyectos de plataforma: la ingeniería de pipelines y la migración de ajustes.

El flujo de trabajo de Corgea no es una reproducción función por función de Checkmarx. Tiene una forma distinta: los hallazgos llegan en la pull request en lugar de en una cola de escaneo, la triaje ocurre en la revisión en lugar de en una base de datos de supresiones, y los ajustes se descubren a partir de tu código en lugar de escribirse en un lenguaje de consultas. Ese es el argumento para migrar, y también es la razón por la que la migración es corta. La comparación de Corgea frente a Checkmarx cubre dónde coinciden las dos plataformas y dónde no, y alternativas a Checkmarx cubre la lista más amplia de opciones si todavía estás evaluando.

Ejecuta primero la comparación

No te fíes de las cifras de palabra, ni te comprometas a nada para probarlas. Sube tu informe JSON más reciente de Checkmarx a Corgea, ejecuta un escaneo de Corgea sobre el mismo commit y observa la diferencia sobre tu propio código: verdaderos positivos encontrados, falsos positivos evitados y lo que cada herramienta se perdió.

Solicita una comparación y comprueba si se mantiene en tus propios repositorios. Si no es así, has perdido dos días. Si lo es, tienes toda la transición mapeada y una fecha de renovación que aprovechar.