Plantilla de informe de auditoría de código con IA: las secciones que una auditoría de pago debe entregar

Para qué sirve un informe de auditoría de código IA

Un informe de auditoría hace tres trabajos a la vez. Le dice a un comprador no técnico si el producto es seguro para lanzar, vender o levantar capital. Les dice a los ingenieros exactamente qué arreglar y en qué orden. Y deja un registro que un revisor posterior, el asesor técnico de un inversor o un auditor de SOC 2 puede contrastar.

El código generado con IA cambia el énfasis, no el formato. Los fallos que más vemos son los que el OWASP Top 10:2025 coloca arriba: control de acceso roto, configuración insegura y problemas de cadena de suministro por dependencias que nadie eligió a propósito. A eso se suma una clase de problema propia del código generado: funciones que funcionan en la demo y no hacen nada en los casos límite, y requisitos que nunca se implementaron porque el prompt que construyó la función no los mencionó.

Por eso un buen informe responde dos preguntas, no una. ¿El código es seguro? ¿Y el código hace lo que se pidió? La segunda es una auditoría de requisitos, y el cliente normalmente no sabe que debe pedirla.

Las siete secciones que esperan los clientes

La OWASP Web Security Testing Guide recomienda cuatro secciones de primer nivel para un informe de pruebas de seguridad: Introducción, Resumen ejecutivo, Hallazgos y Apéndices. La plantilla de informe de evaluación de Lenny Zeltser, muy extendida, reparte el mismo material en ocho. Nosotros usamos siete, porque una auditoría de código también debe cubrir qué hace el código, no solo cómo se puede atacar.

El orden importa. Los directivos leen la primera página y la tabla. Los ingenieros van directos a la sección 5. Si cualquiera de los dos grupos tiene que buscar, el informe ha fallado en su trabajo.

1. Resumen ejecutivo

Escríbelo al final y que no pase de media página. Indica qué se auditó en una frase, da el veredicto en otra («la aplicación no está lista para clientes de pago hasta que se corrijan los dos hallazgos críticos»), luego el recuento por severidad y después los dos o tres temas que explican la mayoría de los hallazgos. Nombra algo que la base de código hace bien; da credibilidad al resto. Aquí no van payloads, ni números de CVE, ni nombres de herramientas.

2. Alcance y exclusiones

Enumera cada repositorio con el hash del commit auditado, las ramas, los entornos a los que tuviste acceso y las fechas. Después las exclusiones, con motivos: servicios de terceros, infraestructura que no pudiste ver, apps móviles fuera de alcance, cualquier cosa que el cliente pidió no tocar. Una sección de alcance que solo enumera lo incluido se leerá como garantía sobre todo lo demás.

Para código generado con IA, añade una línea sobre procedencia: qué porcentaje de la base de código cree el cliente que fue generado, con qué herramientas, y si un humano lo revisó antes de fusionar. No podrás verificarlo con precisión, así que escríbelo como declaración del cliente.

3. Método

Nombra las herramientas y sus versiones (el escáner SAST, la auditoría de dependencias, el escáner de secretos), la lista de verificación manual que seguiste y el modelo de severidad. Si usaste un asistente de IA durante la revisión, dilo y di qué se le permitió hacer. Cita los estándares en los que te apoyaste: el OWASP Top 10:2025 para los nombres de categoría, la escala cualitativa de CVSS v4.0 para la severidad y OWASP ASVS 5.0.0 si el cliente necesita un nivel de verificación con nombre. Un cliente que más adelante contrate a otra firma debería poder comparar los dos informes.

4. Tabla de severidad

Una fila por hallazgo. Usamos las bandas cualitativas de CVSS v4.0 porque son públicas y nadie las discute: Crítico es una puntuación de 9,0 a 10,0, Alto de 7,0 a 8,9, Medio de 4,0 a 6,9, Bajo de 0,1 a 3,9. Añade un nivel Informativo para lo que no es una vulnerabilidad pero le costará al equipo más adelante, como la ausencia de pruebas o una dependencia sin mantenimiento.

Las filas anteriores son ejemplos ilustrativos de la forma, no hallazgos de un encargo real. Las categorías de la tercera columna son los nombres del OWASP Top 10:2025, para que el cliente pueda consultarlos.

5. Hallazgos con evidencia

Cada hallazgo lleva los mismos campos, en el mismo orden, siempre. La WSTG los enumera: un ID de referencia, un título, probabilidad, impacto, una calificación de riesgo, una descripción del problema y de cómo se explota, pasos de remediación y, opcionalmente, artefactos reproducibles como un comando curl para que el desarrollador confirme la corrección. Nosotros añadimos dos campos para código generado con IA:

• De dónde viene. El archivo y la línea, y si el patrón se repite en otros sitios. El código generado copia sus propios errores; un ID de tenant sin comprobar suelen ser cinco.
• Por qué ocurrió probablemente. No para repartir culpas, sino porque la solución suele estar en el prompt o la plantilla, no solo en el código. «El handler de la ruta se generó sin ámbito de workspace porque la instrucción no mencionaba la multitenencia» le dice al equipo cómo dejar de producir el mismo error.

Evidencia significa algo que el ingeniero del cliente puede ejecutar. Una captura de pantalla de un escáner no es evidencia; la petición que devolvió los datos de otro tenant sí lo es.

6. Plan de remediación

Convierte los hallazgos en trabajo. Ordénalos por severidad y luego por cuántos otros hallazgos cierra cada corrección. Asigna a cada uno un responsable del lado del cliente, una fecha objetivo y un paso de verificación («volver a probar F-01 con el script de dos tenants del Apéndice B»). Distingue entre corregir ahora, corregir antes del lanzamiento y corregir dentro del trimestre. Un plan sin fechas es una lista.

7. Firma

Quién realizó la auditoría y sus cualificaciones, quién del lado del cliente aceptó el informe y cuándo, qué re-test incluye la tarifa, hasta cuándo es válido el informe (nosotros decimos el commit, no una fecha) y las condiciones de confidencialidad. Si el cliente va a mostrar el informe a un tercero, indica qué versión: la mayoría de los compradores solo necesitan el resumen ejecutivo y la tabla de severidad, no los pasos de reproducción.

Un esqueleto en Markdown para copiar

Pégalo en tu herramienta de documentos y rellénalo. Las etiquetas de sección van en negrita para que no choquen con los encabezados de la página donde lo pegues.

**Informe de auditoría: <nombre del producto>**
Versión 1.0 · <fecha> · Preparado por <firma> para <cliente> · Confidencial

**1. Resumen ejecutivo**
Alcance en una frase. Veredicto en una frase.
Hallazgos: <n> críticos, <n> altos, <n> medios, <n> bajos, <n> informativos.
Temas: (1) ... (2) ... (3) ...
Lo que funciona bien: ...

**2. Alcance y exclusiones**
Repositorios y commits: <repo>@<sha>
Entornos: ...
Fechas: <inicio> a <fin>
Procedencia (declaración del cliente): ~<x>% generado con <herramientas>, revisado por ...
Fuera de alcance: ... (motivo)

**3. Método**
Herramientas y versiones: ...
Lista de verificación: <enlace>
Modelo de severidad: escala cualitativa CVSS v4.0 + Informativo
Asistencia de IA durante la revisión: sí/no, para ...

**4. Tabla de severidad**
| ID | Hallazgo | Categoría (OWASP Top 10:2025) | Severidad | Estado |

**5. Hallazgos**
F-01 <título>
Severidad: ... Probabilidad: ... Impacto: ...
Ubicación: <archivo:línea>, también en ...
Descripción: ...
Evidencia (reproducible): ...
Por qué ocurrió probablemente: ...
Corrección: paso 1, paso 2 ...
Referencias: ...

**6. Plan de remediación**
| Orden | Hallazgo | Responsable | Fecha objetivo | Verificación |

**7. Firma**
Auditado por: ... Aceptado por: ... Fecha: ...
Re-test incluido: ... Válido para el commit: ...

La plantilla de lista de verificación para auditoría de código alojada es el complemento del lado de la revisión: es la lista que recorres antes de tener algo que poner en la sección 5.

Cómo producir el informe en cinco pasos

1. Fija el alcance por escrito antes de empezar. Hashes de commit, entornos, exclusiones. Envíaselo al cliente y espera respuesta. Todo lo que diga el informe remite a esto.
2. Ejecuta primero las pasadas automáticas y haz triaje. SAST, auditoría de dependencias, escaneo de secretos. La mayor parte de lo que devuelven es ruido; el informe solo debe contener lo que confirmaste a mano, con la salida de los escáneres en un apéndice.
3. Haz la revisión manual con una lista de verificación. Autenticación, autorización en cada ruta, manejo de entradas, pagos y webhooks, exportación y borrado de datos, trabajos en segundo plano. Para código generado con IA, lee también los prompts, plantillas y archivos de reglas si el cliente los tiene; explican los patrones que vas a encontrar.
4. Audita los requisitos, no solo el código. Toma el PRD o el brief original, enumera cada requisito y márcalo como implementado, parcial o ausente. Las bases de código generadas suelen estar completas para el camino feliz y vacías para todo lo que el prompt no mencionó. Lleva las brechas a la tabla de severidad como Informativo o superior, según lo que el cliente haya prometido a sus clientes.
5. Escribe los hallazgos, luego el plan, luego el resumen. En ese orden. El resumen es una compresión de los hallazgos; escribirlo primero produce un resumen de tus suposiciones.

Cómo lo hacemos en Atrix

Escribimos el informe como una página en Atrix, no como un archivo de Word, porque el informe y el trabajo de remediación tienen que vivir uno junto al otro. La página contiene las siete secciones; cada fila del plan de remediación es un issue dentro de un ciclo, con responsable, fecha de vencimiento y el paso de verificación en su descripción. Cuando un ingeniero cierra F-01, el plan se actualiza, y el re-test es un segundo issue, no un recordatorio en la bandeja de alguien.

El cliente recibe un enlace compartido a la página, así lee la versión actual y los comentarios quedan en un solo hilo. El historial de versiones muestra qué cambió entre el borrador y el informe aceptado. Al cerrar el encargo, la exportación a Markdown le da al cliente un archivo que le pertenece.

Un límite que conviene dejar claro: el agente de IA de Atrix no escanea código. Su función de auditoría es una auditoría de requisitos, que compara lo construido con una línea base de requisitos congelada e informa de cobertura y desviaciones. Eso es el paso 4 de arriba, y es útil. Los pasos 2 y 3, los escáneres y la lectura humana de las rutas de autenticación y pagos, ocurren en tus herramientas SAST y en la cabeza de tus revisores. Si un cliente quiere una auditoría de código humana hecha por nosotros y no por el software, ese es trabajo de la agencia, no del producto; en cómo abordamos las auditorías de código con IA explicamos dónde ayuda la IA en la revisión y dónde confunde.

Preguntas frecuentes

¿Qué debe incluir un informe de auditoría de código IA?

Siete secciones: un resumen ejecutivo, alcance y exclusiones, método, una tabla de severidad, una entrada por hallazgo con evidencia reproducible y corrección, un plan de remediación con responsables y fechas, y una firma. Para código generado con IA, añade la procedencia al alcance y una comprobación de cobertura de requisitos a los hallazgos.

¿Qué escala de severidad debe usar un informe de auditoría de código?

Una pública, para que los clientes puedan comparar informes. La escala cualitativa de CVSS v4.0, publicada por FIRST, califica de 9,0 a 10,0 como Crítico, de 7,0 a 8,9 como Alto, de 4,0 a 6,9 como Medio y de 0,1 a 3,9 como Bajo. Añade un nivel Informativo para hallazgos que no son vulnerabilidades, como pruebas ausentes o requisitos sin implementar.

¿Cuánto debe ocupar un informe de auditoría de código?

Lo que necesiten los hallazgos y nada más. Una auditoría de dos semanas de un SaaS pequeño suele producir un resumen ejecutivo de media página, una tabla de severidad de una página y entre cinco y veinte entradas de hallazgo de media página cada una. La salida de los escáneres y los logs van en apéndices, no en el cuerpo.

¿El cliente debe recibir el informe completo o solo un resumen?

Ambos, como documentos separados. El informe completo va al líder de ingeniería del cliente. Una versión corta con el resumen ejecutivo y la tabla de severidad, sin pasos de reproducción, es lo que puede reenviar a un comprador, inversor o auditor.

¿Una auditoría de código IA sustituye a un test de penetración?

No. Una auditoría de código lee el código fuente; un test de penetración ataca el sistema en ejecución. Encuentran cosas que se solapan pero son distintas. La mayoría de los compradores de SOC 2 piden un test de penetración de los últimos doce meses; la auditoría de código es lo que haces antes, para que el test encuentre menos.

¿En qué se diferencia una auditoría de código IA de una auditoría normal?

El formato es el mismo. El énfasis se desplaza hacia controles de acceso ausentes en lugar de erróneos, dependencias que nadie eligió, patrones repetidos en muchos archivos y requisitos nunca implementados porque el prompt no los mencionó. El informe debe indicar qué parte del código fue generada y revisar los requisitos además de la seguridad.

Siguiente paso

Recorre la lista de verificación para auditoría de código antes de escribir la sección 5, y mira cómo las agencias gestionan el trabajo con clientes en Atrix con el informe como página, las correcciones como issues y el cliente en un enlace compartido. Páginas y pizarras cubre la coedición, el historial de versiones y la exportación a Markdown.

Fuentes

Estructura del informe y campos de los hallazgos: OWASP Web Security Testing Guide, Reporting Structure y plantilla de informe de evaluación de seguridad de Lenny Zeltser. Bandas de severidad: especificación CVSS v4.0, FIRST, tabla 22. Nombres de categoría: OWASP Top 10:2025. Niveles de verificación: OWASP ASVS 5.0.0, publicado el 30 de mayo de 2025. Todo comprobado en octubre de 2026.