Falsos positivos propios de cada escaneo

Las distribuciones de Linux suelen corregir un fallo de seguridad en la versión que ya publicaron, copiando solo el arreglo, y dejan el número original con un sufijo propio. Es el retroporte. El paquete está parcheado y, aun así, su número de versión sigue pareciendo viejo.

Un escáner de imágenes que compara contra el número de versión original puede marcar ese paquete como vulnerable. No miente por malicia: lee lo único que ve. La comprobación honesta es el registro de cambios del paquete de la distribución, que dice si el aviso está corregido.

El escáner de repositorio asocia cada paquete con avisos por su nombre y su ecosistema. Si un equipo publica un paquete interno con el mismo nombre que uno público, el escáner puede cruzar el aviso del público con el interno. El hallazgo parece real y no lo es: el código que corre no es el del aviso.

Se confirma mirando de dónde sale el paquete. Si lo resolvió el repositorio interno de la empresa, el aviso del homónimo público no le aplica, aunque la versión coincida por casualidad.

Los procesos de construcción por etapas producen imágenes intermedias que llevan compiladores y herramientas, y una imagen final que solo lleva lo necesario para correr. Si el escáner abre la etiqueta de la etapa de compilación, informa de paquetes que en producción no existen.

Antes de abrir un ticket hay que comprobar contra qué imagen se escaneó: la que se despliega, no la que se usó para construirla. Un hallazgo sobre una etiqueta que nunca llega al clúster es ruido, y le cuesta tiempo a quien lo reciba.

Un paquete puede estar en el repositorio y no en la imagen. Las dependencias de desarrollo —herramientas de prueba, de formato, de compilación— se declaran aparte y no se instalan en la imagen final. Un hallazgo sobre una de ellas es cierto en el repositorio y no tiene alcance en producción.

Cerrarlo como falso positivo sería incorrecto, porque el paquete existe. Se anota como no aplicable a lo desplegado, con la evidencia, y se deja visible para revisarlo si cambia la forma de construir la imagen.

Después de comprobar cada hallazgo, el resultado no es una lista más corta por gusto sino una lista más verdadera. Quedan los que la evidencia confirma en lo que corre. Esos son los que se llevan al dueño con la evidencia pegada, y por eso su ticket se cree.

Aplica lo que viste a los seis hallazgos y cuenta cuántos sobreviven a la comprobación.