Trazabilidad y auditoría, quién hizo qué y cuándo

La trazabilidad responde a una pregunta del auditor: «¿puede probar que esta vulnerabilidad se corrigió, y que nadie lo hizo sin control?». Tiene cuatro piezas. El ticket enlaza el cambio con una petición. La aprobación separa a quien decide de quien ejecuta. Las pruebas previas reducen el riesgo de romper el servicio. El reescaneo posterior demuestra que el hallazgo desapareció.

Abre leeme.txt y retencion.txt.

La separación de funciones es una defensa simple: una sola persona que pide, aprueba y ejecuta un cambio puede equivocarse o hacer algo indebido sin que nadie lo note. Por eso la regla pide un aprobador distinto del aplicador. Compara las columnas aprobo y aplico en cambios.csv.

Un cambio aplicado antes de su aprobación no es un retraso de papel: indica que el proceso se saltó o que la aprobación se firmó después para tapar el hecho. La regla permite el mismo día, pero no un día antes. Compara aprobado_el con aplicado_el.

Un cambio sin ticket es un cambio sin dueño ni motivo registrado. Incluso si el parche era correcto, el auditor no puede reconstruir por qué se hizo. La columna de ticket tiene un guion donde falta.

Aplica las cuatro condiciones juntas: ticket, aprobador distinto, orden correcto de fechas, y pruebas más reescaneo. Cada cambio que falla en una sola condición deja de tener trazabilidad completa. Con ello se arma la cifra honesta para el auditor.