Alguien del equipo corre una herramienta contra el sitio, sale un informe de cuarenta páginas con alertas en colores y se dice "ya hicimos el pentest". Es una confusión muy común, y deja a la gente con una sensación de seguridad que no se corresponde con lo que se midió. Conviene separar las dos cosas.
Qué es una prueba de penetración
Un pentest es un ejercicio autorizado en el que una persona con conocimientos de seguridad intenta vulnerar un sistema usando las mismas ideas que usaría un atacante real, pero con reglas acordadas de antemano. El objetivo no es listar defectos sino demostrar qué se puede lograr con ellos: leer datos de otros usuarios, saltar una pantalla de login, escalar privilegios, llegar a un servidor interno.
Esa palabra, demostrar, es lo que lo distingue. Un defecto aislado puede parecer menor. Encadenado con otros, puede terminar en acceso a información sensible. El trabajo del pentester es encontrar esas cadenas y mostrarlas con evidencia que el equipo pueda reproducir y corregir.
Lo autorizado no es un detalle de forma. Sin permiso escrito del responsable del sistema, lo mismo que se hace en un pentest pasa a ser un acceso indebido. Probar solo sistemas propios o con autorización explícita es la regla de base de toda la disciplina.
Escáner automático y prueba manual
Un escáner de vulnerabilidades recorre un sistema, compara lo que encuentra con una base de problemas conocidos y avisa. Detecta bien cosas como componentes desactualizados, configuraciones por defecto, certificados vencidos o cabeceras de seguridad ausentes. Es rápido, barato de repetir y útil para correr seguido, incluso en cada despliegue.
Lo que no hace bien es entender el negocio. Un escáner no sabe que en tu aplicación un usuario puede ver la factura de otro cambiando un número en la URL, porque la respuesta es perfectamente válida desde el punto de vista técnico. Tampoco sabe que el flujo de recuperación de contraseña permite tomar una cuenta si se combinan dos pasos en un orden raro. Esas fallas de lógica y de autorización requieren que alguien piense cómo está pensado el sistema y cómo se lo puede forzar.
Además, los escáneres producen falsos positivos, alertas que no son reales, y alguien tiene que revisarlas. Un buen pentest hace esa validación: cada hallazgo que llega al informe fue confirmado.
En la práctica, los dos se complementan. El escáner cubre ancho y repetición; la prueba manual cubre profundidad y lógica.
Cajas negra, gris y blanca
Estos nombres describen cuánta información recibe quien prueba.
- Caja negra: parte sin conocimiento previo, como lo haría alguien externo. Mide lo que se ve desde afuera, pero gasta tiempo en descubrir cosas que el equipo ya sabe.
- Caja gris: recibe información parcial, por ejemplo cuentas de prueba con distintos roles y documentación básica de la API. Suele ser el mejor equilibrio entre costo y cobertura, porque permite llegar rápido a las funciones autenticadas, donde viven muchos de los problemas serios.
- Caja blanca: tiene acceso al código fuente y a la arquitectura. Es la más profunda y se acerca más a una revisión de código con intención ofensiva.
No hay una mejor en abstracto. Depende de qué querés saber: qué ve un extraño, qué puede hacer un usuario común malicioso, o qué se esconde en el diseño.
Qué debería entregarte
El producto final es un informe, y su calidad importa tanto como la prueba. Debería incluir el alcance y el período en que se probó, una descripción de cada hallazgo con pasos para reproducirlo, la evidencia, una valoración de gravedad con su justificación y recomendaciones concretas de corrección. También es razonable que haya un resumen para quien decide y no es técnico, y una instancia posterior para verificar que lo corregido quedó bien corregido.
Desconfiá de un informe que sea una copia de la salida de una herramienta, sin contexto sobre tu aplicación.
Lo que un pentest no es
No es una certificación de que el sistema es seguro. Es una fotografía de un momento, limitada por el tiempo y el alcance acordados. Que no se haya encontrado algo significa que no se encontró en esas condiciones, no que no exista.
Tampoco reemplaza las prácticas cotidianas: revisión de código, dependencias actualizadas, gestión de secretos, registros útiles. Un pentest sobre un sistema desordenado se convierte en una larga lista de problemas evitables, y el dinero se va en encontrar lo que una revisión interna habría detectado.
Lo más valioso que deja una prueba bien hecha no es el informe, sino lo que el equipo aprende sobre cómo piensa un atacante y que después se refleja en el próximo desarrollo.