Hay equipos que hacen una prueba de penetración, leen el informe con atención, corrigen lo urgente y a los seis meses descubren los mismos tipos de falla en otra parte del producto. El pentest mide un momento. Lo que cambia el resultado es lo que pasa después, y ahí es donde la mayoría se queda corta.
Triage y backlog
Lo primero es convertir el informe en trabajo. Cada hallazgo (o mejor, cada grupo de hallazgos con la misma causa) se vuelve una tarea en el mismo lugar donde el equipo ya gestiona el resto: el gestor de incidencias, no un PDF en una carpeta compartida. Cada tarea lleva descripción, gravedad ajustada a tu contexto, responsable, fecha objetivo y criterio de aceptación.
El triage tiene tres salidas posibles: corregir ahora, planificar, o aceptar el riesgo con una decisión explícita y fechada. Lo que está expuesto a internet y es explotable sin credenciales va primero. Lo que requiere condiciones raras puede esperar un ciclo, pero no desaparecer. Y las correcciones baratas conviene hacerlas de inmediato, aunque sean de gravedad baja, porque despejan la lista.
Corregir la causa, no el síntoma
Imaginá que el informe señala que un endpoint devuelve datos de otro usuario al cambiar un identificador. La corrección rápida es agregar la verificación en ese endpoint. La corrección útil es preguntarse por qué fue posible: ¿falta una capa común que aplique el control de pertenencia?, ¿cada controlador lo resuelve a su manera? Si solo parchás el punto señalado, el próximo endpoint que alguien escriba repetirá el error.
Pasa igual con los filtros. Bloquear la cadena exacta que usó quien probó es corregir el síntoma; la atacante siguiente usará otra variante. Una consulta parametrizada elimina la categoría completa. Cuando una recomendación del informe parece un parche puntual, preguntale a quien la escribió si hay una solución estructural, y si la hay, planificala aunque lleve más tiempo.
Verificar que funcionó
Que una tarea figure como "hecha" no demuestra nada. Falta comprobar que la falla ya no se reproduce, y que la corrección no introdujo otra. Lo habitual es pedir un re-test: quien hizo la prueba original repite los casos de los hallazgos corregidos, con los mismos pasos, y confirma por escrito el resultado. Muchos servicios lo incluyen dentro de un plazo después de la entrega, así que conviene acordarlo desde el principio.
Entre medio, vos también podés verificar. Reproducí los pasos del informe en un entorno de pruebas propio, antes y después del cambio. Es la manera más directa de saber si el arreglo toca el problema real.
Convertir hallazgos en pruebas automáticas
Cada falla corregida es una oportunidad de no volver a tenerla. Escribí una prueba automática que reproduzca el caso: pedir con un usuario el recurso de otro y esperar un rechazo, mandar una entrada con caracteres problemáticos y comprobar que se trata como dato. Esas pruebas se ejecutan en cada cambio y avisan si alguien rompe la protección sin querer.
Sumá, donde tenga sentido, controles automáticos más generales en la integración continua: análisis estático del código, revisión de dependencias vulnerables, detección de secretos. No reemplazan a una prueba hecha por una persona, pero atrapan lo repetitivo.
Mirar el proceso
Si aparecieron varias fallas del mismo tipo, el problema no está solo en el código. Conviene revisar cómo se trabaja: si las revisiones de cambios incluyen una lista de puntos de seguridad, si el equipo conoce las prácticas básicas, si los requisitos contemplan quién puede hacer qué antes de empezar a programar, si hay una plantilla de proyecto con los controles ya resueltos. Un hallazgo repetido es un dato sobre el proceso, y arreglarlo ahí rinde más que corregirlo cada vez.
Periodicidad
Una prueba al año sirve de poco si el producto cambia todos los meses. No hay una frecuencia universal: depende de cuán seguido publicás cambios importantes, de la sensibilidad de los datos y de lo que te exijan tus clientes. Un criterio práctico es repetir una prueba ante cambios grandes (una funcionalidad nueva de autenticación, un cambio de arquitectura) y mantener una revisión periódica más liviana para el resto.
Contarlo con honestidad
Si tus clientes preguntan, y cada vez preguntan más, contá lo que pasó con precisión: que se hizo una prueba, qué tipo de problemas aparecieron en términos generales, qué se corrigió y qué está en curso. Evitá afirmar que el sistema "es seguro" o que "pasó el pentest": ninguna prueba demuestra ausencia de fallas, solo reporta las que encontró dentro de un alcance. Un cliente suele valorar más un proceso ordenado y transparente que un certificado que promete de más. Si hubo una exposición real de datos de terceros, consultá con un profesional del derecho qué obligaciones de aviso te corresponden.