Guía de integración
Protege tus bases de datos en menos de 5 minutos, de tres formas: el proxy TCP transparente para el tráfico en tiempo de ejecución, la CLI vericto para pre-commit y CI/CD, y una API REST directa. Cero credenciales almacenadas.
Requisitos previos
- Una cuenta de Vericto (regístrate gratis)
- Una API key (crea una en Dashboard → API Keys)
- Para el proxy TCP (protección en tiempo de ejecución): Docker o cualquier runtime de contenedores para desplegar el proxy en tu infraestructura
- Para la CLI (pre-commit y CI/CD): una shell, o un runner de CI con Node/Docker
- Para la API HTTP (REST directo): capacidad de hacer solicitudes HTTP desde tu pipeline o aplicación
Vericto ofrece tres modos de integración. Elige según el entorno; se combinan entre sí:
| Modo | Cuándo usarlo | Aplicación |
|---|---|---|
| Proxy TCP | Runtime: cada consulta que tu aplicación (o un agente LLM) envía a Postgres/MySQL | Bloquea en tiempo real, antes de que la consulta llegue a la base de datos |
CLI (vericto) | Shift-left: hooks de pre-commit y CI/CD, los cuatro dialectos | Hace fallar el build; el SQL se analiza, nunca se ejecuta |
| API HTTP | Integraciones a medida: llama al endpoint REST directamente desde tus propias herramientas | Devuelve un veredicto sobre el que actúas |
Cero credenciales: Vericto nunca almacena las credenciales de tu base de datos. El proxy TCP se ejecuta en tu infraestructura y reenvía la autenticación de forma transparente. Tus credenciales nunca salen de tu red.
Paso 1: crear workspace y base de datos
- Ve a /register y crea tu cuenta
- Navega a Dashboard → Databases → Add Database
- Introduce un nombre (p. ej.
prod-users-db) y selecciona el dialecto. PostgreSQL y MySQL pueden pasar por el proxy TCP transparente; Oracle y SQL Server se evalúan únicamente vía la API HTTP. - Copia el Database ID. Lo necesitarás para la configuración
- Ve a Dashboard → API Keys y crea una key con los scopes
rules:readytelemetry:write(son los únicos que el proxy necesita: descarga su ruleset y reporta telemetría). El proxy evalúa el SQL localmente, así que no requiere el scope de evaluación AST. Cópiala de forma segura.
Eso es todo lo que necesitas del dashboard de Vericto. Sin cadenas de conexión, sin credenciales.
Proxy TCP: protección de bases de datos en producción
El proxy TCP intercepta cada consulta SQL a nivel del protocolo de cable, tanto de PostgreSQL como de MySQL (elige con VERICTO_WIRE_PROTOCOL). Despliégalo como sidecar o como contenedor independiente en tu infraestructura. Tu aplicación se conecta al proxy con las mismas credenciales que usa directamente con la base de datos.
# docker-compose.yml
services:
vericto-proxy:
image: ghcr.io/vericto/vericto-proxy:latest
ports:
- "5433:5433"
environment:
VERICTO_API_URL: "https://api.vericto.com"
VERICTO_API_KEY: "${VERICTO_API_KEY}"
VERICTO_DATABASE_ID: "${VERICTO_DATABASE_ID}"
VERICTO_WIRE_PROTOCOL: "postgres" # or "mysql"
UPSTREAM_HOST: "your-db-host.rds.amazonaws.com"
UPSTREAM_PORT: "5432"
PROXY_LISTEN_PORT: "5433"
# Remote DB (RDS): encrypt the proxy → database hop.
UPSTREAM_SSLMODE: "require" # or "verify-full" + UPSTREAM_SSLROOTCERT
app:
environment:
# Point your app to the proxy — same user:pass as before
DATABASE_URL: "postgres://user:pass@vericto-proxy:5433/mydb"
depends_on:
- vericto-proxy
Referencia de configuración
Toda la configuración del proxy se pasa por variables de entorno. Solo UPSTREAM_HOST es obligatoria; el enlace con el plano de control se activa en cuanto defines VERICTO_API_URL y VERICTO_API_KEY. Si las omites, el proxy sigue evaluando con su ruleset local por defecto (útil en dev o entornos air-gapped).
| Variable | Por defecto | Descripción |
|---|---|---|
| Upstream (proxy → base de datos) | ||
UPSTREAM_HOST | obligatoria | Host de tu base de datos. Es la única variable imprescindible. |
UPSTREAM_PORT | 5432 / 3306 | Puerto de la base de datos. El default depende del protocolo (Postgres 5432, MySQL 3306). |
VERICTO_WIRE_PROTOCOL | postgres | postgres o mysql. Determina el parser del protocolo y los puertos por defecto. |
PROXY_LISTEN_PORT | 5433 / 3307 | Puerto en el que el proxy escucha a tu aplicación. Default según protocolo (Postgres 5433, MySQL 3307). |
| Plano de control (proxy → API de Vericto) | ||
VERICTO_API_URL | — | URL de la API de Vericto. Usa https://api.vericto.com. Definirla (junto con la key) activa telemetría y sync de reglas. |
VERICTO_API_KEY | — | API key del workspace (vtro_…) con scopes rules:read + telemetry:write. Guárdala como secreto. |
VERICTO_DATABASE_ID | — | El Database ID que este proxy protege. Etiqueta la telemetría y selecciona las reglas de esa base. Sin él, el proxy no reporta telemetría. |
VERICTO_RULES_SYNC_INTERVAL_SECS | 300 | Cada cuánto el proxy consulta cambios en el ruleset. Mínimo 30 s (valores menores se ajustan a 30). |
| Evaluación y salud | ||
VERICTO_MAX_QUERY_BYTES | 10485760 | Tamaño máximo de una consulta que el proxy evalúa (10 MiB). Por encima se rechaza sin analizar, con el código VERICTO-QUERY-TOO-LARGE. Súbela si tus cargas legítimas (inserts por lotes, listas IN largas) superan el límite; el techo real es el del protocolo (64 MiB en Postgres, 16 MiB en MySQL). En modo monitor la consulta se reenvía sin evaluar en lugar de rechazarse. |
VERICTO_HEALTHZ_PORT | — | Puerto TCP dedicado a health checks del balanceador. Responde sin tocar la base de datos, y no acepta conexiones hasta que el proxy terminó su warm-up. Si se omite, no se abre. |
| TLS (ver sección siguiente) | ||
UPSTREAM_SSLMODE | disable | disable, require o verify-full. Cifra el salto proxy → base de datos. |
UPSTREAM_SSLROOTCERT | — | CA para verify-full. Si se omite, usa las CA públicas del sistema. |
UPSTREAM_SSLCERT / UPSTREAM_SSLKEY | — | Certificado cliente para mTLS upstream (auth cert). Solo se aplica en el hop de PostgreSQL. |
PROXY_TLS_MODE | disable | disable o require. Termina TLS en el salto app → proxy. |
PROXY_TLS_CERT / PROXY_TLS_KEY | — | Certificado y clave de servidor (PEM) cuando PROXY_TLS_MODE=require. |
| Telemetría (ver sección siguiente) | ||
VERICTO_TELEMETRY_BUFFER | memory | memory o disk. Estrategia de buffering antes de la entrega. |
VERICTO_TELEMETRY_DISK_PATH | /var/lib/vericto/spool | Directorio del spool cuando el buffer es disk. |
VERICTO_TELEMETRY_MEMORY_CAPACITY | 10000 | Máximo de eventos en el ring buffer en memoria antes de descartar los más antiguos. |
VERICTO_TELEMETRY_BATCH_SIZE | 100 | Máximo de eventos enviados en cada POST /ingest/events. |
VERICTO_TELEMETRY_FLUSH_SECS | 5 | Cada cuántos segundos el reporter vacía el buffer hacia la API. |
Cifrar conexiones (TLS)
Proxy → base de datos. Cuando tu base de datos es remota (p. ej. una instancia gestionada de RDS/Cloud SQL), cifra el salto proxy → base de datos con UPSTREAM_SSLMODE. El proxy realiza la negociación SSLRequest de PostgreSQL y tuneliza la sesión a través de TLS:
# Encryption only (does not verify the server certificate)
UPSTREAM_SSLMODE=require
# Encryption + verify the certificate chain and hostname
UPSTREAM_SSLMODE=verify-full
UPSTREAM_SSLROOTCERT=/etc/vericto/rds-ca.pem # omit to use public CA roots
# Optional: mutual TLS — present a client cert so the proxy authenticates to a
# database configured with `cert` auth (one service identity for the proxy)
UPSTREAM_SSLCERT=/etc/vericto/proxy-client.crt
UPSTREAM_SSLKEY=/etc/vericto/proxy-client.key
Cliente → proxy. Por defecto el proxy rechaza el TLS del cliente, porque está pensado para ejecutarse dentro del mismo perímetro de confianza que tu aplicación (sidecar, mismo host o subred privada), donde ese salto nunca sale de tu red. Para cifrarlo de forma nativa, configura PROXY_TLS_MODE=require con un certificado y una clave de servidor. El proxy responde al SSLRequest con 'S' y termina el TLS como servidor:
PROXY_TLS_MODE=require
PROXY_TLS_CERT=/etc/vericto/server.crt
PROXY_TLS_KEY=/etc/vericto/server.key
Vericto recomienda terminar el TLS del cliente en el proxy cuando:
- El salto app → proxy cruza una red no confiable (distinto host, VPC o AZ) en lugar de un sidecar o subred privada.
- Tu driver exige
sslmode=requirey no quieres poner delante un balanceador de carga que termine TLS (AWS NLB, HAProxy). - Una línea base de cumplimiento obliga a cifrar en tránsito en cada salto.
Si el proxy ya se ejecuta como sidecar o en la misma subred privada, déjalo deshabilitado. No es necesario. Esto es TLS del lado del servidor (el cliente autentica al proxy); el proxy retransmite la autenticación de extremo a extremo, así que scram-sha-256, md5 y la autenticación por token en la nube (IAM / Entra) funcionan sin cambios. El channel binding de SCRAM (SCRAM-SHA-256-PLUS) y la autenticación cert por cliente final no se admiten a través de un proxy que termina el TLS, por diseño. Ambos existen para detectar un proxy intermedio. Inspeccionar el SQL requiere descifrar en el proxy, así que un TLS opaco de extremo a extremo es incompatible con la aplicación de reglas.
Buffering de telemetría: memoria vs. disco
El proxy almacena en buffer los eventos de evaluación antes de enviarlos a la API de Vericto. Hay dos estrategias disponibles:
| Modo | Comportamiento | Ideal para |
|---|---|---|
memory (por defecto) |
Los eventos se mantienen en un ring buffer de tamaño fijo (por defecto: 10.000 eventos). Si la API no está accesible, los eventos más antiguos se descartan cuando el buffer se llena. Se pierden al reiniciar el contenedor. | Entornos de baja latencia donde es aceptable perder algún evento durante caídas de la API. Cero sobrecarga de E/S de disco. |
disk |
Los eventos se escriben en un spool de solo anexado en disco. Sobrevive a reinicios del contenedor y a caídas prolongadas de la API. El reporter lee y elimina del spool tras una entrega exitosa. | Entornos críticos de cumplimiento (SOC2, ISO 27001) donde no se debe perder ningún evento. Requiere montar un volumen persistente. |
Configuración vía variables de entorno:
VERICTO_TELEMETRY_BUFFER=memory|disk # default: memory
VERICTO_TELEMETRY_DISK_PATH=/var/lib/vericto/spool
VERICTO_TELEMETRY_MEMORY_CAPACITY=10000
Importante: la telemetría es siempre no bloqueante. Independientemente del modo de buffer, la ruta de evaluación del SQL nunca se retrasa por la E/S de telemetría. Los eventos se envían al buffer de forma asíncrona después de tomar la decisión.
Recomendaciones de recursos
El proxy está diseñado para ser ligero. El motor AST se compila a código nativo y evalúa las consultas en el proceso, sin llamadas de red en la ruta crítica.
| Carga de trabajo | CPU | Memoria | Disco | Consultas/seg |
|---|---|---|---|---|
| Pequeña (dev, staging) | 0.25 vCPU |
64 MB |
Ninguno (buffer en memoria) | Hasta 1.000 q/s |
| Mediana (producción) | 0.5 vCPU |
128 MB |
100 MB (si buffer en disco) | Hasta 10.000 q/s |
| Alta (alto rendimiento) | 1 vCPU |
256 MB |
500 MB (buffer en disco) | 50.000+ q/s |
Factores clave: la CPU escala con la complejidad de la consulta (las consultas con múltiples JOIN requieren analizar más nodos AST). La memoria escala con el número de conexiones (cada sesión TCP mantiene ~4 KB de estado). El disco solo se necesita para el buffering de telemetría en modo disco.
Objetivo de latencia: P99 < 2ms para la evaluación de reglas. El proxy añade una sobrecarga insignificante comparada con el round-trip de red a tu base de datos.
Frameworks y ORMs
Una vez que el proxy está en marcha, apunta tu aplicación hacia él. El único cambio es el host; las mismas credenciales, el mismo nombre de base de datos:
| ORM / Driver | Configuración | Ejemplo |
|---|---|---|
| Prisma | DATABASE_URL en .env |
postgres://user:pass@vericto-proxy:5433/mydb |
| SQLAlchemy | create_engine(url) |
postgresql+psycopg2://user:pass@proxy:5433/mydb |
| Drizzle ORM | connectionString |
postgres://user:pass@proxy:5433/mydb |
| TypeORM | host + port en el DataSource |
host: 'vericto-proxy', port: 5433 |
| ActiveRecord | DATABASE_URL |
postgres://user:pass@proxy:5433/mydb |
| Go (pgx/lib-pq) | sql.Open("postgres", url) |
postgres://user:pass@proxy:5433/mydb |
| Java (JDBC) | jdbc:postgresql://host:port/db |
jdbc:postgresql://vericto-proxy:5433/mydb |
| .NET (Npgsql) | Host=;Port=;Database= |
Host=vericto-proxy;Port=5433;Database=mydb |
CLI: shift-left en pre-commit y CI/CD
La CLI vericto valida el SQL contra las reglas de tu workspace antes de que llegue a ejecutarse, en hooks de pre-commit y pipelines de CI. Es un cliente ligero: envía el SQL a tu workspace (POST /api/v1/ci/check-key) y refleja el veredicto como código de salida del proceso. El SQL se analiza, nunca se ejecuta. Funciona con los cuatro dialectos (PostgreSQL, MySQL, Oracle, SQL Server) y está disponible en todos los planes, medido por una cuota mensual de CLI.
Proxy TCP vs. CLI: el proxy protege el tráfico en tiempo de ejecución (las consultas que tu aplicación o un agente LLM envían realmente). La CLI protege el tiempo de escritura (migraciones y SQL en la revisión de código), de modo que las consultas inseguras nunca se fusionan. La mayoría de los equipos usan ambos.
Instalar y autenticar
# Shell installer (Linux / macOS)
curl -fsSL https://github.com/vericto/vericto-cli/releases/latest/download/vericto-cli-installer.sh | sh
Autentícate una vez. En un portátil, vericto login abre tu navegador y emite una key con alcance limitado de 30 días. No se pega nada. En CI, proporciona una API key mediante la variable de entorno VERICTO_API_KEY (o usa OIDC, más abajo):
vericto login # browser login (developer at a keyboard)
vericto doctor # verify config, connectivity, auth & plan quota
# Check migrations locally — exit 1 if anything is blocked
VERICTO_API_KEY=vtro_... vericto check migrations/*.sql --dialect postgres
Pipelines de CI/CD
La CLI es un cliente ligero que refleja el veredicto como código de salida del proceso, así que funciona en cualquier CI que pueda ejecutar un comando. vericto init genera una plantilla lista para commitear en GitHub Actions y GitLab CI; en CircleCI, Jenkins u otros se configura a mano (mismo comando, gateado por el exit code). --changed comprueba solo los archivos *.sql modificados respecto al merge base, así los PRs se mantienen rápidos:
# GitHub Actions — .github/workflows/vericto.yml
name: Vericto SQL Check
on: pull_request
permissions:
contents: read
security-events: write # required to upload SARIF to the Security tab
jobs:
sql-check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with: { fetch-depth: 0 } # --changed needs history for the merge base
- run: npm install -g @vericto/vericto-cli
- run: vericto check --changed --format sarif --output vericto.sarif
env:
VERICTO_API_KEY: ${{ secrets.VERICTO_API_KEY }}
- uses: github/codeql-action/upload-sarif@v4 # inline PR annotations
if: always() # upload findings even when the check step exits non-zero
with:
sarif_file: vericto.sarif
Los códigos de salida permiten a CI distinguir un bloqueo real de una caída: 0 limpio · 1 un hallazgo igual o superior a --fail-on (por defecto block) · 2 error de uso · 3 error de autenticación/configuración · 4 error de backend/red. Usa --monitor para reportar hallazgos pero salir siempre con 0 durante el despliegue inicial.
Autenticación CI sin keys (OIDC): en lugar de almacenar una key estática vtro_..., un pipeline puede autenticarse con un token efímero por ejecución vía OIDC / workload identity, la misma federación que GitHub Actions y GitLab CI ya proporcionan. Crea una política de confianza para el workspace en el dashboard y luego ejecuta vericto check --changed --oidc --workspace ws_123. La key se mantiene solo en memoria, nunca se escribe en disco.
Hook de pre-commit y baseline
Detecta SQL inseguro antes incluso de commitearlo. vericto init --hook instala el hook; adoptar la CLI en un repo con SQL preexistente no pondrá el build en rojo el primer día. Registra un baseline para que solo fallen los hallazgos nuevos:
vericto init --hook # install the pre-commit hook
# Baseline existing findings, then fail only on new ones
vericto baseline migrations/*.sql # writes .vericto-baseline.json
vericto check migrations/*.sql --baseline .vericto-baseline.json
Suprime un hallazgo puntual en línea. Se requiere un motivo, para que quede trazable:
DELETE FROM users; -- vericto:ignore[VERICTO-001] one-off backfill, tracked in JIRA-42
API HTTP: integración REST directa
¿Prefieres llamar a Vericto desde tus propias herramientas en lugar de la CLI? Evalúa SQL vía REST en POST /api/v1/ci/check-key, autenticado con una API key (scope ci_dryrun:execute). Las consultas se analizan pero nunca se ejecutan. Es el mismo endpoint que usa la CLI. Recurre a él solo cuando la CLI no encaje en tu flujo de trabajo.
Envía un lote de hasta 500 consultas, cada una etiquetada con su línea de origen. La respuesta devuelve un veredicto por consulta y un exit_code (1 si algo fue bloqueado):
Ejemplos de código
# curl — evaluate one or more queries
curl -s -X POST https://api.vericto.com/api/v1/ci/check-key \
-H "X-API-Key: $VERICTO_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"dialect": "postgres",
"file_name": "0001_init.sql",
"queries": [
{ "line": 1, "sql": "ALTER TABLE users DROP COLUMN email;" }
]
}'
# Response:
# {
# "summary": { "total": 1, "blocked": 1, "allowed": 0, "ruleset_version": "…" },
# "queries": [
# { "line": 1, "status": "BLOCKED", "rule_code": "VERICTO-014",
# "severity": "high", "ast_node_path": "…", "suggested_fix": "…" }
# ],
# "exit_code": 1
# }
Para la mayoría de los pipelines, la CLI vericto es más simple. Se encarga por ti del batching, la detección --changed, los baselines y la salida SARIF/Code-Quality.
Verificar y monitorear
Una vez integrado, verifica que la configuración funciona:
- Proxy TCP: ve a Dashboard → Databases y haz clic en "Verify connection". El proxy reportará su estado en cuestión de segundos.
- CLI: ejecuta
vericto doctorpara confirmar la configuración, la conectividad, la autenticación y tu cuota mensual restante en un solo comando. - API HTTP: envía un lote de prueba y revisa la respuesta. Un
200con"exit_code": 0y"status": "ALLOWED"confirma que la integración funciona. - Dashboard: navega a la página Queries para ver los eventos de evaluación en tiempo real, y a la página CI Runs para el historial de comprobaciones de CLI/API.
Activa el Modo Observación durante el despliegue inicial. Registra todas las decisiones sin bloquear nada, para que puedas validar tu conjunto de reglas antes de aplicarlo.