CLIGitHub ActionMCP

CI/CD y migraciones: el SQL se revisa en el pull request

Una migración destructiva pasa la revisión de código porque nadie lee cada línea de SQL. La CLI de Vericto y la GitHub Action vericto/check-sql revisan cada migración y archivo .sql del pull request contra las reglas de tu workspace, anotan los hallazgos en el PR y fallan el job ante un bloqueo. El SQL se analiza, nunca se ejecuta.

Empezar gratis La CLI en CI/CD
Diagrama: CI/CD y migraciones con VerictoUn desarrollador, con el hook de pre-commit, hace push de un pull request con migraciones y archivos .sql. La GitHub Action vericto/check-sql instala la CLI, que envía el SQL a la API de validación en Vericto Cloud y recibe el veredicto. Si pasa, el merge y el deploy aplican la migración a la base de producción; si hay un bloqueo, la CLI sale con exit 1 y el job falla.pushveredictopasaexit 1: el job fallamigrarDesarrolladorhook de pre-commitPull requestmigracionesvericto/check-sqlGitHub Action · CLIAPI de validaciónen Vericto CloudEvalúa aquíMerge y deployaplica la migraciónBase de datosproducciónDiagrama: CI/CD y migraciones con VerictoUn desarrollador, con el hook de pre-commit, hace push de un pull request con migraciones y archivos .sql. La GitHub Action vericto/check-sql instala la CLI, que envía el SQL a la API de validación en Vericto Cloud y recibe el veredicto. Si pasa, el merge y el deploy aplican la migración a la base de producción; si hay un bloqueo, la CLI sale con exit 1 y el job falla.pushveredictomigrarDesarrolladorhook de pre-commitPull requestmigracionesvericto/check-sqlGitHub Action · CLIAPI de validaciónen Vericto CloudEvalúa aquíMerge y deployaplica la migraciónBase de datosproducción
  • Ruta de la sentencia SQL
  • Sentencia bloqueada: vuelve un error
  • Donde Vericto evalúa
  • Componente de Vericto que no evalúa
La Action instala la CLI, que envía el SQL del PR a la API de validación; el veredicto vuelve como anotaciones y como código de salida. Solo lo que pasa llega al deploy.

Qué protege

  • DML destructivo, con la acción de tu workspace: VERICTO-001 (DELETE sin WHERE), 042 (UPDATE sin WHERE) y 033 (DELETE sin WHERE en una subquery o CTE).
  • Esquema y DDL, VERICTO-010 a 019 (DROP, TRUNCATE, DROP COLUMN, RENAME, ALTER COLUMN TYPE): en CI y MCP se limitan a FLAG, porque una migración versionada los contiene con razón. El pipeline los reporta y no falla; en runtime, el proxy y la API los bloquean.
  • Reglas de seguridad como VERICTO-080 (COPY … PROGRAM) y 082 (GRANT y REVOKE), con su acción completa.
  • Reglas custom en YAML (desde Builder) para lo propio de tu equipo, por ejemplo prohibir borrados físicos en una tabla.

Latencia y disponibilidad

El check corre en el pipeline, fuera del runtime: no añade latencia a tu aplicación. Con --changed, la CLI revisa solo los .sql modificados respecto al merge base, para que los PRs sigan rápidos.

Cada statement analizado cuenta como una validación: 1K al mes en Free, 10K en Builder, ilimitadas en Team y Enterprise. Un lote que no cabe en lo que queda se rechaza entero con 429.

La API de runtime, la API de validación y MCP corren en Vericto Cloud, con un SLA de 99,5% en Builder y de 99,9% en Team y Enterprise (99,95% y 99,99% con despliegue dedicado). El estado del servicio, en la página de estado.

Cómo implementarlo

  1. Crea una API key con el scope ci_dryrun:execute y guárdala como secreto del repositorio, o usa OIDC para no guardar una key estática.
  2. Agrega la Action: uses: vericto/check-sql@v1 con api-key. Instala una versión fija de la CLI, verifica su SHA-256 y sube los hallazgos como SARIF a Code Scanning: CI/CD.
  3. En GitLab CI, CircleCI o Jenkins, usa la CLI: vericto init genera la plantilla de GitHub Actions y de GitLab CI.
  4. En un repo con SQL existente, registra un baseline (vericto baseline) para que solo fallen los hallazgos nuevos: baseline.
  5. Opcional: vericto init --hook instala el hook de pre-commit, y el servidor MCP deja que tu agente de código valide la migración mientras la escribe.
  6. Si cambias reglas desde CI, simula el cambio contra el tráfico de producción con una key rules:simulate (Builder, Team y Enterprise).

Cuándo no usar esta opción

  • SQL que se genera en runtime (un ORM, un agente, una consola): CI nunca lo ve. Para eso está el proxy TCP o la API de runtime: ver aplicación web.
  • Migraciones que no están en archivos .sql, como las migraciones en código de un ORM: genera primero el SQL, o envía las sentencias a la API de validación.

Disponibilidad por plan

FunciónFreeBuilderTeamEnterprise
CLI y GitHub ActionSíSíSíSí
Validaciones de CLI y MCP1K al mes10K al mesIlimitadasIlimitadas
Reglas custom (YAML)—520Ilimitadas
Simulador de reglas—Hasta 30 díasHasta 90 díasSegún contrato (hasta 180 días)
MCP (check_sql)SíSíSíSí

Precios y todos los límites en Precios.

Pruébalo con tu propio SQL

El plan Free incluye 500K queries al mes y 1.000 validaciones de CLI y MCP, sin tarjeta de crédito. Para despliegues en tu VPC, SSO y SLA dedicados, habla con ventas.

Empezar gratis Hablar con ventas