Auditoría de seguridad
Qué está bien, qué no, y cómo se demostró.
Una auditoría de seguridad sirve para dos cosas: dormir tranquilo y firmar con la conciencia limpia. Revisamos el código, los datos, la infraestructura y el aislamiento entre clientes de un sistema que ya existe, y entregamos un informe donde cada afirmación trae su evidencia. Sin hallazgos inflados para justificar la factura, y sin un "todo bien" que nadie pueda sostener después.
Para quién
- Sistemas que firman contratos de operación largos y tienen que demostrar un programa de ciberseguridad, no un parche.
- Plataformas multi-tenant que guardan datos de varios clientes en la misma base y necesitan probar que no se ven entre sí.
- Equipos que van a licitar o a pasar una revisión del cliente y quieren llegar con el informe hecho, no con promesas.
- Sistemas con IA adentro: qué datos salen hacia un modelo externo, con qué candados y con qué registro.
Qué se revisa
- 01
Aplicación y código
Inyección, autenticación y sesiones, autorización ruta por ruta, manejo de secretos, dependencias y la superficie de administración. Línea a línea donde importa, no por muestreo.
- 02
Datos y aislamiento entre clientes
Políticas de Row Level Security y lo que las políticas no cubren: canales laterales por índices únicos, claves foráneas, secuencias compartidas, mensajes de error y tiempos de respuesta.
- 03
Infraestructura y despliegue
TLS y cabeceras, CORS, puertos expuestos, usuarios y privilegios del sistema, respaldo con restauración probada, registros y quién puede leerlos.
- 04
Trazabilidad y cumplimiento
Bitácoras que no se pueden editar, auditoría por transición, y el encaje de todo lo anterior con lo que exige el contrato, el pliego o la ley de datos personales que aplique.
- 05
IA dentro del sistema
Qué sale hacia modelos externos y qué no, anonimización antes de salir, candados para encenderlo y registro de lo que efectivamente se envió.
- 06
Operación sostenida
Parches, respuesta a incidentes, pruebas periódicas: lo que un contrato largo exige como programa y que casi nunca existe cuando llega la auditoría.
Cómo se hace
- 01
Alcance y acceso
Se define qué entra y qué no, y se recibe acceso de lectura al repositorio, a la configuración real y a un entorno de pruebas. Producción no se toca.
- 02
Revisión con evidencia
Código, configuración y pruebas controladas. Cada hallazgo se reproduce antes de escribirse; si una hipótesis no se pudo demostrar, el informe lo dice tal cual.
- 03
Informe
Veredicto, lo que está bien con su evidencia, hallazgos por severidad con ubicación y reproducción, y lo que falta como programa. Se presenta y se discute; no se manda por correo y listo.
- 04
Cierre
Segunda pasada sobre las correcciones. Lo que se arregló queda marcado como verificado; lo que se decidió no arreglar, documentado con su razón.
El entregable
Informe de auditoría de seguridad
Estructura real del informe · sin datos del cliente: conclusiones y ubicaciones
-
1. Veredicto
Una frase que un directorio entiende: qué tan sólido está el sistema y qué separa lo que hay de lo que exige el contrato.
-
2. Lo que está bien, verificado
Tabla por área con estado y evidencia concreta (archivo, migración, prueba). Lo que está bien también se documenta: es lo que evita volver a auditarlo.
-
3. Hallazgos por severidad
Crítica, alta, media, baja. Cada uno con ubicación, cómo reproducirlo, riesgo real hoy, y si bloquea o no el despliegue.
-
4. Lo que falta como programa
Respaldo probado, endurecimiento, respuesta a incidentes, pruebas periódicas: lo que no es un parche sino una práctica, con quién y cada cuánto.
-
5. Anexo técnico
Comandos, consultas y configuraciones usadas para verificar, para que el propio equipo pueda repetirlo.
La investigación detrás
El criterio no viene de una lista de verificación: viene de buscar fallas en el software de base que usan nuestros propios clientes. Sobre PostgreSQL mantenemos infraestructura de fuzzing y de pruebas lógicas, y reportamos lo que encontramos al proyecto.
- 674 M
- ejecuciones de fuzzing
- sobre los analizadores de tipos del núcleo de PostgreSQL, con AFL++ y ASan en once carriles
- 15 M
- casos sobre pgvector
- protocolo binario de vectores con arnés propio; cero fallas, que es el resultado esperado de un proyecto sano
- 10+
- bugs reportados
- a pgsql-bugs con reproducción; varios confirmados por committers del proyecto
El hallazgo que define el servicio
Row Level Security oculta las filas de otro cliente en un SELECT, pero un índice único es físico y global: un INSERT de sondeo con el correo de otro cliente falla con "clave duplicada" y confirma que ese dato existe. Explotable con privilegios bajos, sin ninguna configuración incorrecta y sin superusuario. No es una falla de PostgreSQL (está en su documentación), pero sí de casi toda plataforma multi-tenant que use RLS con índices únicos globales. Lo encontramos atacando nuestra propia plataforma; es lo primero que buscamos en la de un cliente.
Para el análisis asistido usamos Claude dentro del Cyber Verification Program de Anthropic (investigación y divulgación de vulnerabilidades, desarrollo de herramientas de seguridad), aprobado en septiembre de 2026. Es un ajuste de acceso, no un aval: los hallazgos los sostiene la evidencia, no el modelo.
Preguntas
¿Cuánto dura y cuánto cuesta?
Entre dos y cuatro semanas según el tamaño del sistema, con alcance y precio fijos acordados antes de empezar. Si durante la revisión aparece algo fuera del alcance, se avisa y se decide juntos.
¿Necesitan acceso a producción?
No. Se trabaja sobre el repositorio, la configuración real y un entorno de pruebas. Si hace falta mirar producción, es sólo lectura, acordado por escrito y registrado.
¿Qué pasa con lo que encuentran?
Se le informa primero al cliente, con el tiempo necesario para corregir. Si la falla está en software de terceros, se reporta al proyecto con divulgación responsable, como hacemos con PostgreSQL.
¿Sirve para una licitación o un contrato?
Es el caso típico. El informe se estructura contra las exigencias del pliego o del contrato, con la ubicación de cada evidencia por documento, sección y página, para que el evaluador la encuentre.
¿Auditan sistemas que no construyeron ustedes?
Sí, y es lo habitual. Lo único que pedimos es acceso al código y a la configuración: una auditoría sin código es una encuesta.
Contacto
¿Tienes un proceso que se te está cayendo a pedazos?
Cuéntanos qué operación quieres ordenar. Si podemos ayudar, lo decimos con un plan y un plazo; si no es lo nuestro, también lo decimos.
Escríbenos a contacto@betrivasystems.com · Respondemos dentro de un día hábil.