Informes de pentest con IA: de las notas en bruto al informe final

Las pruebas son la parte divertida. El informe es lo que paga el cliente, y suele escribirlo al final del encargo alguien que está cansado. Esta guía muestra cómo usar Odin v1 para convertir notas en bruto, salidas de escáneres y capturas de pantalla descritas en un informe de pentest limpio y listo para el cliente, sin delegar tu criterio ni entregar secretos del cliente.

En qué es buena la IA en un informe de pentest, y en qué no

Un modelo de lenguaje es bueno en las partes del informe que son sobre todo redacción: convertir notas escuetas en frases completas, mantener una estructura coherente a lo largo de 30 hallazgos, escribir un resumen ejecutivo que un lector no técnico pueda seguir y redactar recomendaciones de remediación que encajen con el stack que describes.

No es una fuente de verdad. No ha visto el objetivo. No puede confirmar que un hallazgo sea real, que tu severidad sea correcta ni que un paso de reproducción funcione. Trata cada borrador como la primera pasada de un pentester junior: útil, rápida y necesitada de revisión.

Los asistentes convencionales añaden un segundo problema. Pega "un usuario autenticado puede leer las facturas de otros tenants cambiando el ID" y algunos empiezan a sermonear sobre el acceso no autorizado en lugar de redactar el hallazgo. Odin v1 responde directamente cuando el contexto es un informe para un encargo autorizado, que es justo de lo que se trata. Explicamos por qué importa en nuestro artículo de lanzamiento.

Antes de que nada salga de tu máquina: anonimiza

Tus notas contienen hostnames del cliente, IP internas, nombres de usuario y, a veces, tokens de sesión o hashes de contraseñas. Elimínalos antes de enviar nada a cualquier API.

Un conjunto sencillo de reglas cubre casi todo:

• Sustituye los dominios del cliente por marcadores como client.example.com.
• Sustituye las IP internas y externas por rangos de documentación (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24) o por tokens como HOST-A.
• Sustituye los nombres de usuario reales por user1, admin1.
• Elimina los secretos por completo. Un hallazgo sobre un token expuesto necesita el tipo de token y dónde estaba, no su valor.
• Guarda un archivo de correspondencias en local para poder restaurar los valores reales en el documento final.

En InterOdin, los prompts y las respuestas de la API nunca se almacenan. Solo se guardan metadatos como el número de tokens, la latencia y el estado, para la facturación, y los servidores están en Alemania. Es una buena base, pero no sustituye a la anonimización. Tu contrato con el cliente decide qué datos pueden salir del entorno del encargo, así que revísalo primero.

La estructura de informe que buscas

La mayoría de los informes para clientes comparten el mismo esqueleto. Dale al modelo esta estructura de forma explícita para que todos los borradores salgan con la misma forma:

Cada bloque de hallazgo debería incluir: título, severidad, vector CVSS v4, activos afectados, descripción, impacto, pasos de reproducción, evidencias, remediación y referencias.

Una plantilla de prompt para un hallazgo

Aquí tienes un conjunto realista de notas en bruto de una prueba autorizada de una aplicación web (ya anonimizadas):

target: app.client.example.com (in scope per RoE section 2)GET /api/v2/invoices/{id} returns invoice JSONlogged in as user1 (tenant A), changed id 10442 -> 10443got invoice for tenant B, includes name, billing address, line itemsids sequential, tried 50 in a row, all returned 200no rate limit seenburp request saved as req-17.txtscreenshot 17: tenant B invoice in user1 session

Y un prompt que las convierte en un hallazgo:

You are writing one finding for a penetration test report for an authorizedengagement. Use only the facts in the notes. If something is missing, write[NEEDS TESTER INPUT] instead of guessing.
Output Markdown with these headings: Title, Severity, CVSS v4.0 vector,Affected assets, Description, Impact, Reproduction steps, Evidence,Remediation, References.
Rules:- Propose a CVSS v4.0 base vector and explain each metric choice in one line.- Reproduction steps must be numbered and reproducible by the client's  developers in their own test environment.- Remediation must be specific to the endpoint, then general.- Neutral, factual tone. No blame.
Notes:<paste notes>

Qué puedes esperar de vuelta: un título del estilo de "Insecure Direct Object Reference in Invoice API Exposes Other Tenants' Data", una descripción del control de autorización a nivel de objeto que falla, un párrafo de impacto sobre la divulgación entre tenants de datos personales y de facturación, pasos numerados que usan dos cuentas de prueba en tenants distintos y una remediación que indica que hay que comprobar en el servidor la pertenencia al tenant en cada consulta de objetos, con una nota de que pasar a ID aleatorios no basta como corrección. Las referencias suelen incluir el OWASP API Security Top 10 (API1, Broken Object Level Authorization) y CWE-639.

Para el vector, cuenta con algo así:

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

con una línea por métrica que explica el porqué, por ejemplo "PR:L porque hace falta una cuenta autenticada normal". Calcula siempre tú la puntuación final en la calculadora oficial CVSS v4.0 de FIRST y comprueba cada métrica frente a lo que observaste de verdad. El modelo puede razonar sobre las métricas, pero la puntuación de tu informe es responsabilidad tuya.

Un script de Python que redacta un hallazgo a partir de las notas

Este script lee un archivo de notas, aplica un pequeño mapa de anonimización, lo envía a odin-v1 y escribe un borrador en Markdown. Usa el SDK oficial de OpenAI apuntando a la URL base de InterOdin (consulta la guía del SDK de OpenAI).

import osimport reimport sysfrom pathlib import Path
from openai import OpenAI
SYSTEM = """You write findings for penetration test reports on authorizedengagements. Use only facts from the notes. Mark gaps as [NEEDS TESTER INPUT].Output Markdown with headings: Title, Severity, CVSS v4.0 vector, Affectedassets, Description, Impact, Reproduction steps, Evidence, Remediation,References. Explain each CVSS metric choice in one line."""
# Local mapping: real value -> placeholder. Keep this file out of the report.REDACTIONS = {    "portal.realclient.internal": "app.client.example.com",    "10.20.30.40": "192.0.2.10",    "j.doe": "user1",}
TOKEN_PATTERN = re.compile(r"(eyJ[\w-]+\.[\w-]+\.[\w-]+)|(Bearer\s+\S+)")

def redact(text: str) -> str:    for real, placeholder in REDACTIONS.items():        text = text.replace(real, placeholder)    return TOKEN_PATTERN.sub("[REDACTED-TOKEN]", text)

def main(notes_path: str) -> None:    notes = redact(Path(notes_path).read_text(encoding="utf-8"))
    client = OpenAI(        base_url="https://api.interodin.com/v1",        api_key=os.environ["INTERODIN_API_KEY"],    )    resp = client.chat.completions.create(        model="odin-v1",        messages=[            {"role": "system", "content": SYSTEM},            {"role": "user", "content": f"Notes:\n{notes}"},        ],    )
    out = Path(notes_path).with_suffix(".finding.md")    out.write_text(resp.choices[0].message.content, encoding="utf-8")    print(f"Draft written to {out}")

if __name__ == "__main__":    main(sys.argv[1])

Ejecútalo para cada hallazgo: python draft_finding.py notes/finding-17.txt. Antes de la primera ejecución real, imprime una vez el texto anonimizado en tu terminal para ver exactamente qué se va a enviar.

Salidas de escáneres y capturas de pantalla

Las exportaciones de los escáneres tienen mucho ruido. En lugar de pegar un informe completo, fíltralo primero (solo los plugin IDs o las plantillas que hayas confirmado a mano) y después pide al modelo que agrupe los problemas relacionados. Diez líneas de "falta una cabecera de seguridad" suelen ir en un único hallazgo de severidad baja con una lista de hosts afectados, no en diez hallazgos.

Odin solo acepta texto, así que no se pueden subir imágenes ni PDF. Para los informes funciona bien: describe cada captura en una o dos líneas en tus notas ("captura 17: factura del tenant B visible en la sesión de user1, se ven el número de factura y la dirección"). El modelo hace referencia a la evidencia por su nombre y tú colocas en el documento final las imágenes reales, ya anonimizadas.

Para encargos grandes, odin-v1 tiene una ventana de contexto de 1.000.000 tokens, así que puedes pasarle todos tus hallazgos anonimizados a la vez cuando escribas el resumen ejecutivo. Para tareas rápidas y repetitivas, como normalizar los títulos de los hallazgos o reformatear listas de referencias, odin-flash es más rápido y más barato.

Resumen ejecutivo y hoja de ruta de remediación

Cuando los hallazgos estén revisados, genera el resumen a partir de los propios hallazgos, no de tus notas en bruto:

Below are the reviewed findings from an authorized external and webapplication test. Write an executive summary for non-technical management:max 300 words, overall risk rating, the three issues that matter most and whyin business terms, and a prioritized next-steps list. Do not add findings.

Después pide una hoja de ruta de remediación que agrupe las correcciones por responsable (desarrollo, infraestructura, identidad) y por esfuerzo. Los clientes actúan mucho más a partir de hojas de ruta que de tablas de severidad.

Notas de retest

Tras el periodo de corrección, añade un breve bloque de retest por hallazgo: fecha, qué se volvió a probar, resultado (corregido, parcialmente corregido, no corregido) y evidencias. Un prompt útil es "Aquí tienes el hallazgo original y mis notas de retest. Escribe un bloque de estado del retest de 80 palabras como máximo y señala cualquier discrepancia entre los pasos de reproducción originales y lo que he vuelto a probar". Esa última parte detecta los retests que, sin que nadie se dé cuenta, probaron algo distinto.

Lista de comprobación antes de la entrega

• Cada hallazgo lo ha confirmado un pentester humano, con evidencias.
• Cada puntuación CVSS se ha calculado en la calculadora oficial.
• No queda ningún marcador [NEEDS TESTER INPUT].
• Los marcadores se han sustituido por los valores reales solo en el documento final.
• No aparece en el informe nada que esté fuera del alcance acordado.

Si automatizas más partes, por ejemplo con un script que monte el informe completo a partir de los archivos de hallazgos, nuestro artículo sobre crear herramientas de seguridad con Claude Code sobre Odin explica paso a paso ese tipo de proyecto. A quienes empiezan y están desarrollando sus habilidades en laboratorios quizá también les guste practicar CTF con un coach de IA.

Empieza ya

Crea una clave de API en la consola, configúrala como INTERODIN_API_KEY y sigue la guía de inicio rápido. Mantén cada encargo dentro de su alcance y sus reglas de enfrentamiento por escrito, y dentro de la Política de Uso Aceptable.