El pentesting (o pentest, prueba de penetración) es un ataque simulado y autorizado contra tu aplicación, tu API, tu red o tu entorno cloud. Un tester usa las mismas herramientas y técnicas que un atacante real para encontrar vulnerabilidades, demostrar cuáles son explotables y mostrar qué podría hacer alguien con ellas. El entregable es un informe que ordena cada hallazgo por riesgo y explica cómo corregirlo.
La palabra clave es autorizado. Un pentest tiene un alcance por escrito, fechas y reglas de enfrentamiento. Sin eso, exactamente la misma actividad es un ataque.
Pentesting vs escaneo de vulnerabilidades vs red team
| Actividad | Qué hace | Resultado |
|---|---|---|
| Escaneo de vulnerabilidades | Chequeo automático de problemas conocidos y malas configuraciones | Una lista larga de posibles problemas, con falsos positivos |
| Pentest | Encuentra problemas, valida que sean explotables y los encadena | Hallazgos priorizados y probados, con impacto y solución |
| Red team | Campaña con un objetivo que además prueba detección y respuesta | Si el equipo de defensa se dio cuenta y hasta dónde llegó el atacante |
| Bug bounty | Investigadores externos que cobran por hallazgo válido | Reportes sueltos, cobertura despareja |
Un escáner de vulnerabilidades te dice que una puerta podría estar abierta. Un pentest la cruza y te cuenta a qué habitaciones lleva.
Para qué hacen pentesting las empresas
- Encontrar lo explotable antes que un atacante. Los escáneres no ven bugs de lógica como control de acceso roto, IDOR o un checkout que acepta cantidades negativas. Una persona (o una buena IA) sí.
- Cumplimiento. PCI DSS exige pentesting al menos una vez al año y después de cambios significativos. SOC 2 e ISO 27001 no siempre lo exigen de forma explícita, pero los auditores y los clientes enterprise piden un informe de pentest reciente todo el tiempo.
- Ventas. Los cuestionarios de seguridad de clientes grandes suelen preguntar la fecha de tu último pentest y un resumen de resultados.
- Antes de un cambio grande. Un producto nuevo, una API pública, un flujo de pagos o una migración de infraestructura.
Tipos de pentesting
Según cuánto sabe el tester
- Caja negra (black box): el tester arranca solo con una URL o un rango de IPs, como un atacante externo. Es realista, pero buena parte del presupuesto se va en descubrir cosas y los caminos profundos del código quedan sin tocar.
- Caja gris (grey box): el tester recibe usuarios de cada rol y algo de documentación (specs de la API, arquitectura). Es el formato más común para web y APIs porque equilibra realismo y cobertura.
- Caja blanca (white box): el tester además tiene el código fuente, la infraestructura como código y las configuraciones. Es el que más hallazgos saca por hora porque no hay que adivinar nada, incluidos bugs difíciles de alcanzar desde afuera.
Según el objetivo
- Pentesting web: autenticación, sesiones, control de acceso, inyecciones (mirá inyección SQL), XSS y lógica de negocio. Normalmente se mapea al OWASP Top 10 2025 y a la OWASP Web Security Testing Guide.
- API: autorización a nivel de objeto y de función, mass assignment, rate limits y manejo de tokens. Las APIs devuelven datos directamente, así que un chequeo de autorización que falta ahí suele terminar en una filtración.
- Red: externa (hosts y servicios expuestos a internet) e interna (a qué llega un atacante una vez adentro, por ejemplo Active Directory).
- Mobile: el binario de la app, el almacenamiento local, el certificate pinning y las APIs del backend.
- Cloud: políticas IAM, buckets públicos, servicios de metadata expuestos, Kubernetes y malas configuraciones en infraestructura como código.
- Ingeniería social: phishing y pretexting contra personas, normalmente como un proyecto aparte.
Las fases de un pentest
- Alcance y reglas de enfrentamiento. Qué entra y qué no, ventanas de prueba, producción o staging, contactos de emergencia y la autorización por escrito.
- Reconocimiento. Mapear la superficie de ataque: subdominios, endpoints, tecnologías, archivos expuestos, repos públicos, credenciales filtradas.
- Escaneo y enumeración. Descubrimiento automático y manual de servicios, parámetros, roles y vulnerabilidades candidatas.
- Explotación. Demostrar que la vulnerabilidad es real: leer datos de otro usuario, escalar privilegios, saltear la autenticación. Con cuidado para no romper datos ni disponibilidad.
- Post-explotación. ¿Qué puede hacer el atacante desde ahí? Moverse a otros sistemas, acceder a secretos, quedarse. Es lo que convierte un hallazgo medio en crítico.
- Informe. Hallazgos con severidad, evidencia, pasos para reproducir y remediación.
- Retest. Cuando corregís, el tester confirma que cada problema quedó cerrado.
Las metodologías más usadas son PTES, NIST SP 800-115 y la OWASP Web Security Testing Guide. Un buen proveedor te dice cuál sigue.
Cuánto cuesta un pentest y cuánto tarda
Los precios varían muchísimo, así que tomalos como orientación y no como cotización. Las guías de precios 2026 que publican varios proveedores de pentesting suelen citar aproximadamente entre USD 5.000 y 30.000 para un pentest de aplicación web, y más de USD 100.000 para proyectos grandes de red, cloud o red team. La mayoría de los pentests manuales se cotizan como días de tester por tarifa diaria, así que el alcance manda: cantidad de roles, endpoints, integraciones y entornos.
En tiempos, las guías publicadas por proveedores ubican la mayoría de los tests en 5 a 15 días hábiles de prueba activa, menos para apps chicas y más para plataformas SaaS complejas. De punta a punta, desde el primer contacto hasta el informe final, varias semanas es lo normal, y la demora más común no es el testing sino conseguir accesos y entornos listos.
Pentesting manual vs automatizado vs con IA
| Manual | Automatizado | Con IA | |
|---|---|---|---|
| Fortaleza | Creatividad, lógica de negocio, cadenas complejas | Velocidad, repetible, patrones conocidos | Lee código y contexto, razona sobre explotabilidad a escala |
| Debilidad | Caro, foto de un momento, horas limitadas | Superficial, ruidoso, no ve bugs de lógica | Todavía necesita criterio humano para alcances críticos y firmas |
| Frecuencia | Una o dos veces por año | En cada deploy | En cada commit, pull request o programado |
El problema del modelo clásico es el timing. Un pentest manual es una foto: la semana siguiente al informe tu equipo ya subió código nuevo que nadie probó. Por eso muchos equipos combinan un test manual anual con pruebas continuas, lo que se suele vender como penetration testing as a service (PTaaS). Las plataformas PTaaS mezclan pentesting automatizado con análisis humano o de IA bajo demanda, y entregan los hallazgos en un dashboard en lugar de un PDF.
Pentesting white box con IA sobre el código fuente
El enfoque más nuevo es apuntar un modelo de IA directamente al código. En lugar de pegarle a la app corriendo desde afuera, lee rutas, controllers, queries, chequeos de autorización y archivos de infraestructura, y razona como un tester de caja blanca: a dónde va el input del usuario, qué endpoint se saltea el chequeo de permisos, qué secreto se commiteó hace tres años. Va más allá del SAST clásico basado en patrones porque puede juzgar si una falla es alcanzable y explotable de verdad. (Para la diferencia entre análisis estático y dinámico, leé SAST vs DAST.)
Eso es lo que hace un pentest con IA en Nurbak: conectás GitHub y escaneás un repo, y el modelo de IA propio y self-hosted de Nurbak analiza el código, así que el análisis no manda tu código a OpenAI ni a Anthropic. Reporta vulnerabilidades explotables con archivo y línea, chequea las dependencias contra CVEs conocidos, marca malas configuraciones en GitHub Actions, Docker, Terraform y Kubernetes, encuentra secretos en el historial de git y le pone al repo un puntaje de seguridad de 0 a 100 con explicaciones en lenguaje simple. Con tu consentimiento explícito, puede abrir un Pull Request con el fix y un test de regresión de seguridad. El pentesting white box con IA no reemplaza al pentest humano para una auditoría PCI, pero cubre el hueco entre uno y otro.
Cada cuánto hacer pentesting
- Al menos una vez por año en cualquier sistema que maneje datos de clientes, y siempre que el cumplimiento lo pida.
- Después de cambios significativos: nuevo sistema de autenticación, nueva API pública, pagos, cambios grandes de infraestructura.
- De forma continua si deployás todas las semanas o todos los días. Probar con herramientas automáticas o con IA en cada pull request es parte de una práctica madura de DevSecOps.
Qué tiene que incluir un buen informe de pentest
- Resumen ejecutivo en lenguaje simple: riesgo general, los problemas más críticos y qué arreglar primero.
- Alcance y metodología: qué se probó exactamente, fechas, cuentas usadas y qué quedó afuera.
- Hallazgos con severidad (CVSS o una escala clara), activo afectado, evidencia (requests, capturas), pasos para reproducir, impacto de negocio y remediación concreta.
- Cadenas de ataque: cómo varios problemas de severidad baja se combinan en uno serio.
- Hallazgos positivos: qué resistió, para que sepas qué controles funcionan.
- Resultados del retest confirmando las correcciones.
Señales de alarma: un informe que es casi todo output de un escáner pegado en una plantilla, hallazgos sin prueba de explotación o una remediación que no pasa de "sanitizar el input".
Cómo prepararte para un pentest (y aprovechar la plata)
- Escribí el alcance primero. Listá dominios, APIs, apps mobile y cuentas cloud, y lo que queda explícitamente afuera. Un alcance difuso es la razón principal por la que las cotizaciones varían tanto.
- Dale cuentas reales al tester. Un usuario por rol (admin, usuario común, un usuario de otro tenant). Los hallazgos más serios suelen ser bugs de autorización entre roles y tenants, y con una sola cuenta no se pueden encontrar.
- Preferí un staging que refleje producción. Mismo código, misma configuración, datos realistas. Probá en producción solo con reglas claras sobre acciones destructivas.
- Arreglá lo fácil antes del test. Dependencias viejas con CVEs conocidos, secretos en el repo y malas configuraciones obvias son baratos de encontrar por tu cuenta. Pagarle a un tester senior para que los reporte es quemar horas que deberían ir a fallas de lógica.
- Planificá la ventana de remediación. Reservá tiempo de ingeniería para los fixes y agendá el retest. Un informe que nadie ejecuta es solo un PDF caro.
Por dónde empezar
Si nunca hiciste un pentest, empezá por tu activo más expuesto (normalmente la web app principal y su API), definí si querés caja gris o caja blanca y escribí el alcance antes de hablar con proveedores. Si antes querés una línea de base a nivel código, escaneá tu repositorio con un pentest con IA: el escaneo gratis te muestra completos los 3 hallazgos más importantes, y los planes pagos arrancan en USD 79 por mes.