Reviso un incidente con el equipo técnico y pregunto si el problema está solucionado. La respuesta llega rápida: «Sí, ya hemos parcheado.» Repito la pregunta de otra forma: «¿Sabemos qué ha pasado antes de parchear?» Ahí cambia la conversación. En las últimas semanas varias herramientas que sostienen el ciclo de vida del software —control de versiones, repositorios de artefactos, acceso remoto— han sufrido vulnerabilidades serias. Cada vez que ocurre, el reflejo es el mismo: actualizar, cerrar la alerta, dar el asunto por cerrado. Pero un parche resuelve la puerta de entrada, no lo que ha ocurrido mientras estaba abierta. Si tu empresa depende de dos o tres plataformas para construir y distribuir lo que ejecuta, esa diferencia no es un matiz técnico. Es la pregunta que decide si sigues confiando en tu propio software.
Después del parche: cómo saber si un incidente de seguridad está realmente cerrado
El riesgo real después de un incidente de seguridad no es parchear la vulnerabilidad, ese es el «menor» problema. La confianza no verificada en todo lo que ha podido pasar mientras la vulnerabilidad estaba abierta es donde está el problema. Una empresa puede tener el parche instalado y, al mismo tiempo, no tener ni idea de si alguien ha estado dentro.
Esto lo puedes reconoder en el proceso:
- El ticket se cierra el mismo día del parche, sin registro de qué se ha revisado antes de cerrarlo.
- No hay un procedimiento escrito para rotar credenciales tras un incidente en herramientas de desarrollo o distribución.
- La ventana de exposición —desde que el fallo existe hasta que se corrige— no queda documentada en ninguna parte.
También lo puedes reconoder en el equipo:
- El responsable de seguridad confirma la actualización, pero no puede decir si algún componente distribuido en ese periodo sigue siendo el original.
- Cuando preguntas «¿de dónde viene este paquete?», la respuesta tarda más de lo que debería.
O, directamente en tu negocio:
- El comité da el incidente por cerrado en cuanto llega el aviso de «sistema actualizado».
- Nadie ha preguntado si se puede demostrar, con evidencia, qué se ha ejecutado durante la ventana de exposición.
El fallo está en tratar el parcheo y el chequeo de la intrusión como si fueran el mismo evento.
Una vulnerabilidad en una herramienta de control de versiones puede exponer una credencial guardada en un repositorio. El parche cierra el fallo de la herramienta; no invalida esa credencial, que sigue siendo válida hasta que alguien decide rotarla.
Un fallo en un repositorio de artefactos puede permitir que alguien sustituya un paquete antes de que se corrija el acceso indebido. Corregir el acceso no confirma que los paquetes almacenados sigan siendo los que el equipo cree que son.
Y una plataforma de acceso remoto ya actualizada no garantiza que todos los agentes instalados en los equipos de la organización hayan quedado protegidos de la misma forma. En los tres casos se repite el mismo patrón: el parche trata el síntoma técnico, no la pregunta de confianza que queda abierta detrás.
Cómo impacta en el negocio
El coste real lo tienes, primero en la dependencia: cuando decenas o cientos de aplicaciones se construyen y distribuyen a través de dos o tres plataformas, comprometer una de ellas multiplica el impacto sin que nadie tenga que tocar un servidor de producción. Segundo, la rendición de cuentas: si el comité no puede exigir evidencia de qué se ha verificado tras un incidente, tampoco puede demostrar diligencia debida frente a un cliente, un auditor o un regulador el día que se lo pregunten.
Existen estos criterios para intervenir:
- ¿Existe un registro de qué credenciales han estado expuestas entre el fallo y el parche? Sí/No.
- Cada credencial expuesta —no solo las «sospechosas»— tiene que estar rotada. Se ha hecho o no.
- El equipo puede reconstruir un componente crítico desde fuente conocida y obtiene el mismo resultado, o no puede.
- Hay fecha documentada de la última verificación de actividad anómala tras el incidente, o no la hay.
Cuando un incidente de este tipo llega al comité, no basta con la confirmación de «parche instalado». Este es el one-pager que fuerza la decisión real de la intervención.
Puedes:
- Cerrar el ticket con el parche instalado, sin verificación adicional.
- Rotar credenciales expuestas y verificar actividad anómala.
- Verificación completa — rotación + actividad anómala + reconstrucción reproducible de componentes críticos.
Mi recomendación es que hagas una verificación completa de todo el sistema incluyendo una rotación de todas las contraseñas si se trata de un sistema crítico. En caso de que el sistema no sea crítico, lo imprescindible es que rotes todas las contraseñas.
Eso si, no olvides aprobar presupuesto y tiempo de equipo para realizar todas las operaciones y tareas necesarias.
Aunque sea dificil anticiparte, puedes exigir un inventario vivo de qué software ejecutas y de dónde procede, no un documento que se actualiza una vez al año. Define de antemano qué significa «incidente cerrado» en tu organización, con los mismos campos del one-pager, antes de que ocurra el siguiente. Y pide, al menos en los sistemas críticos, que el equipo pueda demostrar —no argumentar— que el software que ejecuta es el que cree que ejecuta.
Por eso, para esta semana te propongo:
- Pide el registro de credenciales expuestas en el último incidente de seguridad, no la fecha del parche.
- Verifica si alguien puede reconstruir un componente crítico desde fuente conocida y obtener el mismo resultado.
- Lleva las cuatro preguntas del criterio de intervención a la próxima reunión de comité.
Y con esto te pregunto: ¿Puedes demostrar, con evidencia, qué está ejecutando tu empresa ahora mismo?