Fuentes de vulnerabilidades y sus límites

Una vulnerabilidad pública se identifica con un CVE, un identificador del programa CVE que permite referirse a la misma falla en todas las herramientas. Un escáner de hosts, de imágenes o de funciones hace, en esencia, una comparación: toma lo que encuentra instalado (paquetes, versiones, configuración) y lo cruza con una base de datos de vulnerabilidades ya publicadas.

De ahí salen sus límites. No encuentra una falla que aún nadie publicó, ni un error de lógica en el código propio de la empresa, ni dice si alguien ya entró. Y su resultado vale tanto como la base de datos que consultó ese día y la parte del entorno que realmente recorrió.

Un escaneo solo protege lo que cubre. La primera pregunta de una revisión no es «qué encontró», sino «qué activos existen y cuáles aparecen en algún escaneo». Se responde cruzando dos listas: el inventario de activos (la verdad sobre lo que hay) y la cobertura (la verdad sobre lo que se escaneó). Un activo que está en la primera y no en la segunda tiene cero hallazgos, y ese cero no significa «limpio» sino «sin mirar».

Abre inventario-activos.csv y cobertura-escaneos.csv.

Un escaneo viejo describe un activo que ya cambió. Entre un escaneo y la fecha de hoy se instalan paquetes, se publican vulnerabilidades nuevas y se despliegan versiones. Por eso la cobertura se mide con dos números: cuántos activos se escanean y cuán reciente es el último escaneo de cada uno.

La cobertura trae la fecha del último escaneo de cada activo y el inventario, su fecha de exportación (en la primera línea de cada archivo).

Un escaneo sin credenciales mira la máquina desde la red, como lo haría quien no tiene acceso: ve servicios y lo que responden. Uno autenticado entra con una cuenta de solo lectura y consulta los paquetes instalados y su nivel de parches. Para vulnerabilidades en software local, el segundo es el que da el cuadro completo. La columna modo de la cobertura dice cuál se hizo en cada activo.

Un informe de imagen trae, por paquete, la versión instalada, la versión en la que se corrige y la severidad. La columna de versión corregida cambia lo que se puede hacer: con arreglo publicado, la acción es actualizar; sin arreglo, hay que decidir entre sustituir el componente, aislarlo o aceptar el riesgo con un control compensatorio.

Abre informe-img-tienda-api.txt.