Informe de auditoría de seguridad informática: ejemplo

Un informe de auditoría de seguridad informática es el documento que recibes al terminar una auditoría: explica qué se revisó, qué se encontró, qué tan grave es cada cosa y cómo corregirla, en orden de prioridad. Si después de leerlo no sabes qué arreglar primero, el informe no está bien hecho. Abajo tienes la estructura típica, un ejemplo de hallazgo y las herramientas que se usan.

Estructura de un informe de auditoría

1. Resumen ejecutivo (1 página)

Para el dueño o la dirección, sin tecnicismos:

• Estado general (por ejemplo: “hay 2 fallas críticas que exponen datos de clientes”).
• Cuántos hallazgos por gravedad.
• Qué hacer esta semana.

2. Alcance y método

• Qué se revisó: dominios, apps, APIs, base de datos, repositorio.
• Qué no se revisó.
• Fechas y entorno (pruebas o producción).
• Tipo de revisión: automática, manual, código, pruebas activas.
• Cuentas y roles usados.

Esto es importante: un informe sin alcance claro no te dice qué tan seguro estás, solo qué se miró.

3. Tabla de hallazgos

ID	Hallazgo	Gravedad	Estado
H-01	Tabla clientes legible sin sesión	Crítica	Abierto
H-02	Llave secreta de pagos en el frontend	Crítica	Abierto
H-03	Sin límite de intentos en el login	Media	Abierto
H-04	Falta encabezado Strict-Transport-Security	Baja	Abierto

4. Detalle de cada hallazgo

Un bloque por hallazgo, con el mismo formato.

5. Plan de corrección

Qué corregir en qué orden, quién y cuándo, y cuándo se hará la re-revisión.

6. Anexos

Lista de herramientas, versiones, evidencias adicionales.

Ejemplo de auditoría de seguridad informática: un hallazgo

Así se ve un hallazgo bien documentado (ejemplo ilustrativo con datos inventados para mostrar el formato):

H-01. Tabla clientes legible sin iniciar sesión

Gravedad: Crítica

Descripción: La tabla public.clientes en Supabase no tiene Row Level Security activado. Cualquier persona con la URL del proyecto y la llave pública (visible en el código de la página) puede leer, modificar y borrar todos los registros.

Impacto: Exposición de nombre, teléfono y dirección de todos los clientes; posibilidad de borrar la tabla.

Evidencia: El Security Advisor de Supabase reporta rls_disabled_in_public para esta tabla. Desde una sesión anónima en el entorno de pruebas, una consulta a la tabla regresó todos los registros.

Recomendación: Activar RLS y crear políticas para que cada usuario vea solo sus registros y el personal autorizado vea los de su sucursal. Ejemplo:

alter table public.clientes enable row level security;
create policy "Personal ve clientes de su sucursal" on public.clientes
for select to authenticated
using ( sucursal_id = (select public.mi_sucursal()) );

Verificación: Repetir la consulta anónima; debe regresar cero registros.

Fíjate que se entiende qué pasa, por qué importa, cómo se comprobó, cómo se arregla y cómo saber que quedó. Si quieres entender este caso en particular, ve Supabase RLS disabled in public.

Cómo se clasifica la gravedad

Muchos informes usan una escala de cuatro o cinco niveles. Algunos usan CVSS, un estándar de puntuación. Una guía práctica:

Gravedad	Significa	Ejemplo
Crítica	Se explota fácil y expone datos o dinero	Tabla abierta, llave secreta pública
Alta	Daño serio con algo de esfuerzo	Un usuario puede ver pedidos de otros cambiando el ID
Media	Riesgo real pero limitado	Sin límite de intentos de login
Baja	Buena práctica faltante	Encabezados de seguridad incompletos
Informativa	Observación	Dependencia vieja sin falla conocida

Herramientas de auditoría de seguridad informática

Para qué	Herramientas comunes
Dependencias con fallas conocidas	npm audit, pip-audit, Dependabot, Trivy
Secretos en código e historial	gitleaks, secret scanning de GitHub
Análisis estático de código	Semgrep, CodeQL
Revisar peticiones de la app	OWASP ZAP, Burp Suite
Configuración de la plataforma	Security Advisor de Supabase, escaneos de Lovable
Certificado y encabezados	openssl, observatorios de encabezados HTTP
Referencia de riesgos	OWASP Top 10 (lista de los riesgos web más comunes)

Las herramientas producen reportes automáticos que a veces se entregan como si fueran el informe. No lo son: un reporte de herramienta trae falsos positivos y no detecta fallas de lógica. El informe de verdad filtra, confirma y explica.

Qué hacer cuando recibes el informe

1. Lee el resumen y agenda una sesión para que te expliquen los críticos.
2. Corrige los críticos y altos primero, aunque eso retrase funciones nuevas.
3. Guarda el informe como confidencial: es un mapa de tus puntos débiles.
4. Pide la re-revisión cuando termines.
5. Repite después de cambios grandes.

Si ya tienes un informe y no sabes por dónde empezar, nuestra checklist de seguridad para apps hechas con IA te ayuda a ordenar los pendientes; y para entender qué se revisa en una auditoría completa, ve auditoría de seguridad web.

Señales de un mal informe

• Solo es el PDF que exporta una herramienta, sin revisar.
• No dice qué se revisó ni qué no.
• Todo es “crítico” o todo es “bajo”.
• No dice cómo corregir.
• No se entiende sin el auditor al lado.

En resumen

Un buen informe de auditoría de seguridad tiene resumen ejecutivo, alcance, hallazgos con gravedad, evidencia y recomendación, y un plan de corrección priorizado. Las herramientas ayudan, pero el valor está en confirmar y explicar. Si recibiste un informe que no entiendes o necesitas uno para tu app, en Black Engine lo revisamos contigo por WhatsApp.