Un gestor central de vulnerabilidades

Un gestor central no reemplaza a los escáneres: no analiza nada. Importa sus resultados (idealmente en SARIF), los normaliza a una sola escala, los deduplica, les asigna estado y dueño, y ofrece una vista única. Si el trabajo de un escáner es encontrar, el del gestor es que lo encontrado se atienda.

Puede ser un producto comercial, uno de código abierto o, en una empresa pequeña, una hoja de cálculo o una base de datos con disciplina. Lo que lo define es la función: una sola fuente de verdad para los hallazgos.

El eslabón más frágil de un gestor es la entrada. Una herramienta que no habla SARIF necesita un conversor, y una que cambia su formato rompe la importación sin hacer ruido. La bitácora de ingesta es el primer lugar donde se mira.

Abre gestor/ingesta.log.

El gestor existe para contestar preguntas agregadas: cuántos críticos hay abiertos, en qué repositorio, desde cuándo. Esas cifras acaban en un correo a dirección, así que se calculan con cuidado y con la salvedad de qué herramientas aportaron datos.

Abre gestor/hallazgos-abiertos.txt.

Una herramienta que no importa nada nuevo tampoco produce alertas. En el tablero eso se ve igual que «todo está bien», y es la manera más común de perder visibilidad sin enterarse. La bitácora dice cuál fue la última importación aceptada de cada una.

Abre gestor/tablero-secretos.txt: el panel de secretos expuestos marca cero hallazgos abiertos. Con lo que ya leíste en la bitácora, ese cero no significa lo que parece. Un tablero vacío puede querer decir «limpio», pero también «sin datos»: la diferencia está en si la herramienta que alimenta ese panel llegó o no.