El pentest encontró 40 vulnerabilidades — ¿cómo nos organizamos para arreglarlas sin ahogarnos?

No os fiéis a ciegas de las puntuaciones CVSS. Por ejemplo, una vulnerabilidad con puntuación alta en un endpoint de una API interna, si está detrás de una autenticación, tiene un riesgo real bajo. En cambio, una fuga de información de nivel medio en un parámetro expuesto a la internet pública os puede golpear más rápido. Tened siempre en cuenta el contexto de explotabilidad.

El año pasado pasamos por un proceso similar con un informe de 38 hallazgos. Al principio, el equipo pensó que no podría programar nuevas funcionalidades durante semanas. Cuando analizamos, vimos que 14 de las 38 vulnerabilidades se cerraron solas simplemente actualizando dos dependencias de paquetes antiguos. Las actualizaciones de paquetes redujeron un tercio de la carga de trabajo en 3 horas.

Preguntad de inmediato a la empresa del test el plazo de vuestro derecho a re-test según el contrato. Los contratos suelen incluir un periodo de verificación gratuito de 30 o 45 días para las correcciones. Si ese plazo vence antes de solucionar las críticas y altas y obtener el informe de aprobación, tendréis que pagar un coste adicional a la empresa.

Regla de capacidad en el sprint para mantener el flujo de trabajo: 1) Dediquen el treinta por ciento del próximo sprint únicamente a vulnerabilidades críticas. 2) Continúen con sus tareas principales comprometidas con los clientes en el setenta por ciento restante. 3) Muevan las vulnerabilidades de baja prioridad al backlog de deuda técnica y resuélvanlas en los siguientes ciclos.

En nuestra primera prueba de penetración, cuando llegó un informe de 50 páginas, nuestros desarrolladores se lo tomaron como algo personal y se pusieron a la defensiva, como si la gente de seguridad estuviera exagerando. Lo más crítico aquí es mantener la moral del equipo. Tienen que presentar el informe a los devs no como una libreta de notas, sino como una lista estándar de deuda técnica detectada por un ojo externo. Si no, empieza una fricción absurda entre los desarrolladores y el equipo de seguridad.

De esos 11 hallazgos bajos, lo más probable es que al menos 5 sean cosas típicas de plantilla como soporte TLS, flags de cookies o números de versión del servidor. Esas cosas no le hacen daño a un atacante, no pierdan tiempo con eso y enfóquense directamente en las vulnerabilidades de gestión de sesiones y autorización.

¿Su cliente corporativo les dio un plazo oficial (SLA) fijado por contrato para la corrección? Por ejemplo si no hay una cláusula vinculante como 14 días para vulnerabilidades críticas o 30 días para las altas pueden ajustar el calendario totalmente a su propio ritmo de desarrollo.

El plan resumido está claro: hagan las actualizaciones de librerías de inmediato para quitarse bulto de encima, metan las críticas y altas en la ventana de re-test de la empresa, y envíenle al cliente un calendario de corrección de una sola página con fechas claras.

Resumen breve para nuevos usuarios: No confíes en una sola medida; ve capa por capa.

Por supuesto, cambia si tu situación es diferente.

El año pasado nos pasó casi exactamente lo mismo. Empezad con una pequeña prueba no lo integréis todo de golpe.

No confíes en una sola medida; ve capa por capa.

Exacto, y encima no es tan conocido. Todos los que se apresuran con proceso de remediación de vulnerabilidades se atascan en el mismo punto.

Yo pasé por esto, déjenme contarlo. Si el permiso y el alcance no están por escrito, que no empiece la prueba.

Si escribís el resultado aquí, también servirá de ayuda a otros.

Voy a contar mi experiencia. La mayoría de los incidentes no empiezan por una vulnerabilidad, sino por una contraseña filtrada.

Creo que este consejo no sirve para todos. Tomar notas durante dos semanas da mejores resultados que estimar seis meses.

Esta es mi opinión, no lo escribo como una verdad absoluta.

no saabía eso.

Le agradecería que compartiera el resultado.

Yo también tengo curiosidad.

voy a resumir el tema, porque se han dado varias respuestas diferentes. lo que más tiempo nos hacía perdeer era no saber quién tomaba las decisiones.

los cambios en los datos de pago nunca se verifican por el mismo canal por el que llegan y la verdad esta es mi opinión no lo escribo como una verdad absoluta.