Respuesta corta: el registro de hallazgos es el lugar único donde vive cada vulnerabilidad detectada, desde que un escaneo la encuentra hasta que se cierra con evidencia. Puede ser una planilla compartida; lo que cuenta es que cada fila tenga activo, dueño, estado y fecha límite. Sin esos cuatro datos, los resultados de los escaneos quedan en PDFs que nadie vuelve a abrir y no hay forma de saber qué se corrigió.
Un hallazgo sin dueño y sin fecha límite no se corrige.
Qué problema resuelve
Un escaneo produce una lista. Tres semanas después, el técnico recuerda "algo de un OpenSSL viejo", el dueño del servidor no vio el informe y el siguiente escaneo vuelve a mostrar lo mismo. El registro corta ese ciclo: cada hallazgo queda con una persona responsable y un estado visible para todos los que tienen permiso de verlo.
La guía de DHS/CISA (CRR Resource Guide — Vulnerability Management) va más allá del seguimiento diario: sostiene que los datos históricos de vulnerabilidades pueden decidir un cambio de arquitectura. Si una tecnología aparece una y otra vez en el registro, ese historial es el argumento para reemplazarla.
Los campos mínimos
La guía propone registrar fecha de descubrimiento, activos afectados, prioridad, categoría, fuente, responsable, notas de análisis, estado y fecha de cierre. Adaptado a una PyME queda así:
| Campo | Qué guarda | Por qué importa |
|---|---|---|
| ID | Código único (VUL-0001) | Permite citar el hallazgo en tickets y correos |
| Activo | Nombre o IP del equipo, tal como figura en el inventario | Sin esto no se sabe qué hay que tocar |
| CVE | Identificador público, si existe | Cruza con NVD, EPSS y KEV |
| Severidad | Crítica, Alta, Media o Baja | Define el plazo de la política |
| Fecha de detección | Cuándo lo encontró la herramienta por primera vez | Arranca el reloj del plazo |
| Dueño | Persona que corrige, no el área | Una persona con nombre responde; un área no |
| Estado | Uno de los estados definidos más abajo | Muestra dónde está trabado |
| Fecha límite | Detección más el plazo de la política | Permite listar lo vencido |
| Evidencia | Enlace o archivo del reescaneo que prueba el cierre | Sin evidencia no se cierra |
Sumá dos columnas opcionales: fuente (qué herramienta lo encontró) y notas, para dejar escrito por qué se eligió parchear, mitigar o aceptar.
Una fila por activo y vulnerabilidad
La unidad del registro es la pareja activo + CVE. Si el mismo CVE aparece en cuatro servidores, son cuatro filas, cada una con su dueño y su fecha. Si el reescaneo vuelve a detectar un hallazgo que ya está abierto, no se crea una fila nueva: se actualiza la existente. Los duplicados inflan el recuento y esconden lo vencido.
Estados y reglas de cierre
Pocos estados, con una regla clara para pasar de uno a otro:
| Estado | Significa | Pasa al siguiente cuando |
|---|---|---|
| Nuevo | Detectado, sin revisar | Alguien confirma que aplica a tu entorno |
| Asignado | Tiene dueño y fecha límite | El dueño empieza a trabajarlo |
| En remediación | Hay parche, mitigación o ticket de cambio en curso | Se aplica el cambio |
| Pendiente de verificación | Cambio aplicado, sin comprobar | El reescaneo da limpio |
| Cerrado | Verificado, con evidencia | Fin; si reaparece, se reabre la misma fila |
| Excepción | Riesgo aceptado con firma y vencimiento | Vence la excepción o aparece un parche |
| Falso positivo | La herramienta se equivocó, con justificación | Fin |
La regla de oro: nadie cierra su propio hallazgo sin evidencia. El cambio aplicado lleva el estado a "Pendiente de verificación", y el cierre lo hace quien reescanea. Cómo se verifica se explica en Verificar la remediación: cerrar el ciclo con un reescaneo.
Quién puede ver el registro
La guía lo advierte sin vueltas: el repositorio es, en la práctica, un mapa de las exposiciones de la organización. Quien lo lee sabe qué sistemas están sin parchear. Por eso el acceso se limita a quien lo necesita: el equipo de vulnerabilidades, su gerencia y, si existe esa función, quien gestiona riesgos.
En una PyME eso se traduce en cosas concretas:
- La planilla vive en una carpeta con permisos nominales, no con "cualquiera que tenga el enlace".
- No se manda por mail adjunta ni se pega en un chat grupal.
- Los dueños de cada sistema ven sus filas; no hace falta que vean las del resto.
Planilla, tickets o herramienta
| Opción | Sirve cuando | Límite |
|---|---|---|
| Planilla compartida | Pocos equipos y un escaneo por mes | Se desordena si crece el volumen o hay varios editores |
| Sistema de tickets que ya usás | Los dueños ya trabajan ahí | Cuesta ver el panorama global |
| DefectDojo | Importás reportes de varias herramientas y querés historial | Hay que instalarlo y mantenerlo |
Empezá por la planilla. Cambiar de herramienta cuando el volumen lo pida es más barato que montar una plataforma antes de tener el hábito.
Errores típicos
- Hallazgos sin dueño. Se asignan al "equipo de IT" y se evaporan.
- Cerrar por confianza. "Ya lo parcheé" sin reescaneo.
- Borrar lo cerrado. Se pierde el historial que después sirve para detectar reincidencias.
- Registro abierto a toda la empresa. Es información sensible.
- Una fila por escaneo. El mismo problema aparece doce veces y nadie ve que es uno solo.
Preguntas frecuentes
¿Cuántos campos son demasiados?
Si completar una fila lleva más de un par de minutos, sobran columnas. Los nueve de la tabla alcanzan; todo lo demás va en notas.
¿Registro los hallazgos informativos o de severidad baja?
Registralos si el volumen es manejable. Si la herramienta tira cientos de informativos, filtralos en origen y registrá solo lo que tiene acción asociada.
¿Quién carga los hallazgos?
Quien opera el escáner. El dueño del activo no carga: recibe la fila ya armada, con su nombre y su fecha límite.
¿Sirve exportar el CSV del escáner directamente?
Sirve como materia prima. Importalo, quitá duplicados y completá dueño y estado; el CSV crudo no trae ninguno de los dos.
En resumen
El registro convierte una lista de problemas en una cola de trabajo con responsables. Alcanza con una planilla de nueve columnas, siete estados y un permiso de acceso bien puesto. Los patrones que surgen de esa historia alimentan el análisis de causa raíz que cierra la semana: Causa raíz: por qué las mismas vulnerabilidades vuelven.
Esta semana: creá la planilla, cargá los hallazgos de tu último escaneo y asigná un dueño con fecha a cada uno. Para decidir cuáles van primero, seguí con Cómo priorizar vulnerabilidades: CVSS, EPSS, KEV y criticidad del activo.
4 páginas · el procedimiento paso a paso, en PDF. Gratis, por dejar tu email.