Pentest antes de lanzar (o antes de levantar capital): cuándo hacerlo, alcance y cómo destrabar ventas y rondas

Pentest vs escaneo: qué hace cada uno (y qué no hace)

El escáner de vulnerabilidades y el pentest resuelven problemas diferentes. Un escáner automatizado (DAST, SAST o herramientas de análisis de dependencias) coteja firmas conocidas, versiones desactualizadas y patrones inseguros contra tu aplicación. Es rápido, barato de repetir y excelente para ejecutarse de forma continua en el pipeline. Lo que no hace es razonar sobre tu negocio: no entiende que un usuario del plan gratuito no debería poder aprobar su propia transacción, ni que dos endpoints aislados pueden encadenarse para escalar privilegios.

El pentest es un trabajo humano guiado por metodología. Un profesional reproduce el comportamiento de un atacante real, combina hallazgos, prueba hipótesis de abuso y persigue fallas de lógica de negocio (business logic) que las herramientas no detectan. Referencias como el OWASP Web Security Testing Guide (WSTG), el PTES (Penetration Testing Execution Standard) y el NIST SP 800-115 estructuran esa ejecución en fases: reconocimiento, mapeo, explotación y post-explotación.

En la práctica, ambos se suman. El escaneo reduce el ruido de bajo nivel y mantiene la higiene continua entre los ciclos; el pentest entrega la profundidad que clientes enterprise e inversionistas esperan ver. Para una fintech, la diferencia es concreta: un escáner señala un header ausente, mientras que el pentest demuestra que un IDOR (Insecure Direct Object Reference) en la API permite leer el estado de cuenta de otro cliente. Presentar un escaneo y llamarlo pentest es un error común que no pasa en una due diligence seria.

Cuándo hacerlo: antes de lanzar y antes de levantar capital

El mejor momento para un pentest es cuando la arquitectura se estabilizó, pero antes de exponer el producto a clientes reales. Probar demasiado pronto, con features que cambian todos los días, genera hallazgos que se evaporan en el próximo deploy; probar demasiado tarde, ya en producción con tráfico y datos sensibles, transforma cualquier falla crítica en un incidente. El punto de equilibrio es cuando los flujos centrales (registro, autenticación, transacción, integraciones) están funcionalmente cerrados.

Hay dos disparadores que los founders y CTOs no deben ignorar. El primero es el go-live: antes de abrir el registro público, mover datos de producción o conectarte a un socio bancario, quieres saber que un atacante no puede eludir la autenticación ni manipular saldos. El segundo es la captación de capital: la due diligence técnica de inversionistas y de clientes enterprise pregunta, de forma directa, si hay un pentest reciente y cómo se trataron los hallazgos. Llegar a la mesa sin esa respuesta atrasa contratos y rondas.

El pentest no es un evento único. Lo ideal es tratarlo como un ciclo: una prueba de baseline antes del lanzamiento y reevaluaciones tras cambios relevantes de arquitectura, nuevas integraciones, cambio de proveedor de pagos o crecimiento que altere el modelo de amenazas. Para equipos pequeños, vincular el pentest a hitos (lanzamiento, nueva ronda, nuevo cliente grande, certificación) suele ser más sostenible que un calendario rígido.

Alcance: web, app, API, cloud e identidad

El alcance define qué se probará y, de igual importancia, qué queda fuera. Comienza por la superficie de exposición. La aplicación web cubre el front-end y los flujos accesibles por el navegador. La aplicación móvil (Android/iOS) exige análisis del binario, del almacenamiento local y de la comunicación con el backend, siguiendo el OWASP MASVS/MASTG. La API es, en muchas fintechs, donde reside el mayor riesgo: el OWASP API Security Top 10 lista clases como Broken Object Level Authorization (BOLA), Broken Authentication y exceso de exposición de datos que los escáneres genéricos suelen pasar por alto.

La cloud y la identidad completan el cuadro. En entornos AWS, GCP o Azure, el foco recae sobre la configuración de IAM, buckets y secrets expuestos, segregación de red y privilegios excesivos de funciones y servicios. La identidad abarca el flujo de autenticación y autorización: tokens, sesiones, recuperación de contraseña, MFA y la separación entre roles (cliente, operador, administrador). Para una fintech, conviene priorizar los flujos de dinero y los endpoints que tocan datos personales bajo la LGPD.

Define también el enfoque de conocimiento. El black-box simula a un atacante externo sin información previa; el gray-box provee credenciales de usuario común y algo de documentación, lo que normalmente entrega más cobertura por hora; el white-box incluye acceso a código y arquitectura. Para la mayoría de las startups, el gray-box es la mejor relación costo-beneficio. Documenta el entorno (de preferencia un staging fiel a producción), las ventanas de prueba, los límites (rate limit, datos sensibles, terceros) y los contactos de emergencia antes de comenzar.

Qué esperar del informe (y por qué importa el retest)

Un informe de pentest útil es un documento de ingeniería, no una planilla de alertas. Debe traer un resumen ejecutivo legible por no técnicos, la metodología aplicada (WSTG, PTES, NIST), el alcance exacto probado y, para cada hallazgo, evidencias reproducibles: pasos, solicitudes, capturas y el impacto de negocio. La severidad debe estar anclada en un criterio objetivo, idealmente el CVSS (Common Vulnerability Scoring System), que estandariza la puntuación por vector de ataque, complejidad e impacto en confidencialidad, integridad y disponibilidad.

Las buenas recomendaciones son accionables. En lugar de 'corrige el XSS', el informe debe indicar dónde, cómo reproducirlo y cuál es la corrección sugerida (por ejemplo, codificación de salida en el contexto correcto y política de CSP). Prioriza por riesgo real: una falla crítica de autorización en la API que expone datos de clientes va antes de un problema cosmético, aunque ambos aparezcan en el mismo documento. Ese encadenamiento entre hallazgo, severidad y acción es lo que transforma el informe en un backlog de corrección.

El retest cierra el ciclo. Después de que el equipo corrige, el mismo evaluador valida cada ítem y emite una versión actualizada, separando 'resuelto', 'mitigado' y 'abierto'. Sin retest, tienes una lista de problemas; con retest, tienes prueba de que fueron resueltos. Es ese atestado de retest, y no el informe inicial, el que suele anexarse a las respuestas de seguridad de clientes y a los dosieres de due diligence.

Cómo el pentest destraba ventas y rondas

Para una startup B2B y una fintech, la seguridad se volvió un criterio de compra. Las áreas de procurement y los equipos de seguridad de clientes enterprise envían cuestionarios (security questionnaires), piden evidencia de pruebas de intrusión y preguntan sobre el tratamiento de los hallazgos. Un informe reciente con retest concluido responde buena parte de esas preguntas de una sola vez y acorta el ciclo de ventas, en lugar de trabar el contrato en una ronda de correos sobre controles que no logras comprobar.

En la captación de capital, la lógica es la misma. La due diligence técnica de inversionistas evalúa la madurez de ingeniería y el riesgo. Demostrar un proceso de seguridad ofensiva, en lugar de una respuesta vaga, señala que el equipo entiende su propio modelo de amenazas y sabe corregir lo que encuentra. Esto reduce la percepción de riesgo y evita descuentos de valuación o condiciones impuestas por pendientes de seguridad descubiertos tarde en el proceso.

También está el efecto interno. El ciclo de pentest, corrección y retest crea disciplina: el equipo aprende las clases de falla que más lo afectan, ajusta prácticas de desarrollo y pasa a tratar la seguridad como parte del producto. Para un founder, esto significa transformar un costo puntual en un activo reutilizable: el informe y el atestado que abren puertas comerciales y de inversión.

Checklist práctico

1. 1

   1. Mapea tu superficie de exposición

   Lista lo que está expuesto: dominios y aplicaciones web, apps móviles, APIs públicas e internas, cuentas de cloud y proveedores de identidad. Marca dónde transitan dinero y datos personales. Ese inventario es la base del alcance y evita probar lo que no importa.

2. 2

   2. Define alcance, enfoque y entorno

   Elige las superficies a probar, el enfoque (black, gray o white-box) y el entorno (idealmente un staging fiel a producción). Documenta lo que queda fuera del alcance, los terceros involucrados y los flujos críticos que requieren atención especial.

3. 3

   3. Prepara credenciales, datos y accesos

   Crea usuarios de prueba con distintos roles (cliente, operador, admin), datos de ejemplo y acceso al entorno. Acuerda ventanas de prueba, límites de rate limit y un canal de contacto para detener la prueba en caso de impacto inesperado.

4. 4

   4. Alinea metodología y criterios de severidad

   Confirma que el proveedor use metodología reconocida (OWASP WSTG/MASTG, API Top 10, PTES, NIST SP 800-115) y puntúe los hallazgos con CVSS. Acuerda el formato del informe y qué se entregará como evidencia antes de comenzar.

5. 5

   5. Acompaña la ejecución y los hallazgos críticos

   Mantén un punto de contacto técnico disponible durante la prueba. Para los hallazgos críticos, pide notificación inmediata, sin esperar el informe final, para que las fallas que expongan datos o dinero puedan contenerse en paralelo.

6. 6

   6. Trata el informe como un backlog priorizado

   Convierte cada hallazgo en una tarea con responsable, plazo y corrección definida, priorizando por severidad e impacto de negocio. Resuelve primero autorización, autenticación y exposición de datos antes de los ítems cosméticos.

7. 7

   7. Solicita el retest y archiva el atestado

   Tras corregir, pide el retest para validar cada ítem y emitir el informe final con estado actualizado. Guarda ese atestado para responder cuestionarios de clientes y componer el dosier de due diligence en las rondas.

Preguntas frecuentes