Introducción.

Inicio rápido

Vericto protege tus bases de datos evaluando cada consulta SQL contra reglas de seguridad antes de que llegue a tus datos. Tres modos de integración: se combinan, elige según el entorno:

Opción A: Proxy TCP (en tiempo de ejecución, PostgreSQL y MySQL)

Despliega un contenedor ligero en tu infraestructura. Tu aplicación se conecta al proxy en lugar de conectarse directamente a la base de datos: mismas credenciales, distinto host. Bloquea consultas inseguras en tiempo real. Disponible para PostgreSQL y MySQL, cuyos protocolos de cable habla el proxy. Para Oracle y SQL Server, usa la CLI o la API HTTP (todos los dialectos).

Opción B: CLI (shift-left: pre-commit y CI/CD, todos los dialectos)

La CLI vericto valida el SQL contra las reglas de tu workspace antes de que se ejecute, en hooks de pre-commit y pipelines de CI. Es un cliente ligero que envía el SQL a tu workspace y refleja el veredicto como código de salida del proceso (el SQL se analiza, nunca se ejecuta). Funciona con los cuatro dialectos y está disponible en todos los planes.

Opción C: API HTTP (integraciones personalizadas, todos los dialectos)

Evalúa consultas vía REST desde tus propias herramientas: sin proxy, sin CLI. Funciona para todos los dialectos: PostgreSQL, MySQL, Oracle y SQL Server. Es el mismo endpoint que usa la CLI; recurre a él solo cuando la CLI no encaje en tu flujo de trabajo.

¿Listo para conectar? La Guía de integración tiene el paso a paso de los tres modos: despliegue del proxy (Docker, Kubernetes, ECS), instalación y uso de la CLI, y ejemplos de la API HTTP.

Arquitectura

Vericto usa análisis AST (árbol de sintaxis abstracta) determinístico para evaluar las consultas SQL. Sin IA, sin modelos probabilísticos, sin falsos positivos: la misma entrada siempre produce el mismo resultado.

Cómo funciona

Your App → Vericto Proxy (your infrastructure, port 5433)
               │
               ├─ Parse SQL into full AST (pg_query for Postgres, sqlparser-rs for MySQL/Oracle/SQL Server)
               ├─ Evaluate AST against active security rules
               ├─ Resolve enforcement action (BLOCK / FLAG / MONITOR)
               │
               ├── SAFE? → Forward to your real database → relay response
               └── DESTRUCTIVE? → Return SQLSTATE 42501 (query never reaches DB)

Componentes

Proxy TCP (protocolo de cable de PostgreSQL y MySQL)

El proxy TCP es una capa de interceptación transparente. Cualquier driver que use el protocolo de cable de PostgreSQL o MySQL funciona sin cambios de código. Las credenciales de tu base de datos nunca salen de tu infraestructura.

Cero credenciales almacenadas

Vericto nunca almacena las credenciales de tu base de datos ni las transmite a Vericto Cloud. El proxy se ejecuta en tu infraestructura y transmite el intercambio de autenticación de PostgreSQL —el flujo Authentication / PasswordMessage que sigue al StartupMessage— directamente a tu base de datos. Tu aplicación se conecta al proxy con el mismo usuario/contraseña que usaría para conectarse directamente, y las credenciales las verifica tu base de datos, no Vericto. Con SCRAM-SHA-256 (el valor por defecto moderno de PostgreSQL) la contraseña nunca se transmite en texto plano; el proxy solo retransmite el desafío-respuesta.

Compatibilidad de protocolo de cable

Vericto opera como una capa totalmente transparente dentro del protocolo de cable de PostgreSQL. El proxy detecta y evalúa automáticamente el SQL de ambos modos de protocolo, sin necesidad de configuración ni cambios de driver:

El proxy gestiona ambos modos de forma transparente dentro de la misma conexión. Todo el demás tráfico del protocolo (handshake de autenticación, resultados de consultas, notificaciones del servidor, operaciones COPY) pasa sin modificarse. No hay ninguna configuración necesaria para seleccionar entre modos: Vericto inspecciona el byte de tipo de cada mensaje y solo intercepta los frames que transportan SQL.

Qué evalúa Vericto (no solo los casos obvios)

Como Vericto recorre el AST completo de PostgreSQL (vía libpg_query, el mismo parser que usa la base de datos), detecta sentencias destructivas que la inspección superficial o por regex pasa por alto:

• Consultas de múltiples sentencias: cada sentencia de un lote se analiza y evalúa, y gana la violación de mayor severidad. Una cola destructiva no puede esconderse tras una cabeza benigna: SELECT 1; DROP TABLE users; se bloquea en el DROP.
• CTEs y subconsultas que modifican datos: se detectan operaciones destructivas anidadas dentro de cláusulas WITH o subconsultas, p. ej. WITH x AS (DELETE FROM users RETURNING id) SELECT * FROM x.
• Sentencias parametrizadas: las sentencias preparadas se evalúan en tiempo de Parse sobre la estructura de la consulta, por lo que la protección es determinística independientemente de los valores enlazados.
• Tautologías de inyección: los predicados siempre verdaderos como OR 1=1 en una cláusula WHERE se marcan como patrones de inyección SQL.
• Multidialecto: PostgreSQL, MySQL, Oracle y SQL Server se analizan con reglas conscientes del dialecto (p. ej. en MySQL DELETE … LIMIT es válido; Postgres no tiene esa forma). PostgreSQL y MySQL pueden pasar por el proxy transparente; Oracle y SQL Server se evalúan vía la API HTTP.

Decisiones y acciones

Vericto separa la severidad (qué tan peligroso es: Critical / High / Medium / Low / Informational) de la acción de aplicación (qué hacer: BLOCK / FLAG / MONITOR). La acción la resuelve la política de aplicación del workspace.

Política de aplicación por defecto

Telemetría de consultas y privacidad

Por cada consulta que evalúa, el proxy emite un evento de telemetría a la API de Vericto (estado, severidad, código de regla, latencia y el texto de la consulta). Esto alimenta el dashboard, las métricas y el registro de auditoría. Las credenciales de tu base de datos nunca forman parte de la telemetría, pero el texto de la consulta puede contener valores sensibles en sus literales (p. ej. WHERE email = 'alice@acme.com').

El modo de telemetría de consultas es configurable por workspace (Dashboard → Settings → Privacidad de la telemetría):

Cómo funciona la sanitización estructural sobre el AST, ejemplos y la recomendación por tipo de datos (GDPR, HIPAA, Ley 1581 de 2012) están en Privacidad de telemetría.

Autenticación e integración HTTP

El acceso programático de CI/CD a Vericto (evaluación de consultas, sync de reglas, telemetría) usa API keys. Crea una API key desde el dashboard (página API Keys) e inclúyela en cada solicitud en la cabecera X-API-Key. La API REST del dashboard (reglas custom, audit trail) usa el token de sesión con Authorization: Bearer.

X-API-Key: vtro_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Las API keys están limitadas a un workspace y heredan los límites de plan del workspace. Puedes crear varias keys con distintos nombres para distintos entornos (CI, staging, producción).

Endpoint de evaluación de consultas

La forma del request y la respuesta, ejemplos en cURL, Node.js y Python, y los códigos de respuesta están en la Guía de integración.

Reglas de seguridad

Vericto incluye un catálogo de reglas estándar (VERICTO-*) que detectan patrones destructivos y de inyección, agrupadas por severidad:

• CRITICAL Operaciones irreversibles a gran escala: DELETE/UPDATE sin WHERE, DROP, TRUNCATE y tautologías de inyección (OR 1=1). Se bloquean por defecto.
• HIGH Cambios de esquema y patrones peligrosos: ALTER TABLE DROP COLUMN, DROP INDEX, INSERT … SELECT sin filtro, SLEEP().
• MEDIUM Riesgos de rendimiento o buenas prácticas: SELECT sin LIMIT, SELECT * sin WHERE, INSERT sin columnas explícitas.

Consulta el catálogo completo, con cada regla, su severidad, los dialectos que cubre y su condición AST, en la Referencia de reglas AST. Puedes ajustar la acción de cada regla o crear reglas propias en Reglas personalizadas.

Códigos de error

Planes y límites

Vericto tiene cuatro planes. Todos incluyen las reglas estándar y los tres modos de conexión (TCP, API HTTP y CLI); se diferencian en cuotas, retención y funciones enterprise:

• Free: 500K consultas/mes, 1 base de datos, 1K validaciones CLI/mes, retención de auditoría 7 días.
• Builder: 5M consultas/mes, 3 bases de datos, reglas personalizadas (YAML), alertas Slack/webhook, retención 30 días.
• Team: consultas ilimitadas, 10 bases de datos, exportación de auditoría (CSV/JSON), retención 90 días, cumplimiento SOC2/ISO 27001.
• Enterprise: bases de datos y retención a medida, SSO (SAML/OIDC), despliegue dedicado y SLA garantizado.

Consulta la comparativa completa de funciones y los precios en la página de precios.