Escaneo de imágenes y sus informes

Un escáner de imágenes abre cada capa, lee las bases de datos de paquetes del sistema (lo que instaló el gestor de paquetes) y los archivos de dependencias de los lenguajes (lo que declaró la aplicación), y compara cada nombre y versión contra las vulnerabilidades publicadas. Por eso ve bien lo que está declarado. Lo que no ve: un binario copiado a mano sin gestor, una biblioteca incrustada dentro de un ejecutable, o una vulnerabilidad que todavía no se ha publicado. Un informe vacío no significa «no hay problemas»: significa «no hay problemas conocidos en lo que pude leer».

Eso fija el uso correcto: el escaneo es una capa de la defensa, no el veredicto final. Se completa con la lista de materiales, con la construcción reproducible y con la revisión de lo que se copia a mano.

Una tabla con ocho hallazgos no dice por sí sola cuál para el despliegue: lo dice la política de la cadena. Tagua escribió la suya en un archivo: qué combinación de severidad y estado de arreglo detiene, qué avisa y se registra con un responsable, y qué solo se anota. Leer primero la política y después el informe evita el error de las prisas, que es ordenar por severidad y detener todo lo que diga CRÍTICO, o peor, no detener nada porque «ya se arreglará».

Abre la política y el informe de la corrida del 30 de septiembre y aplica la política a cada fila: solo una cumple la condición que detiene el despliegue.

Cuando un hallazgo no se puede corregir hoy, se registra una excepción: quién la decide, por qué es aceptable y hasta cuándo. Una excepción sin fecha de vencimiento es una vulnerabilidad apagada para siempre, y con el tiempo nadie recuerda por qué se aceptó. Una excepción vencida deja de aplicarse: el hallazgo vuelve al informe y, si la política lo exige, vuelve a detener el despliegue. Revisar el archivo de excepciones contra la fecha de la corrida es parte del trabajo, no un lujo.

El informe de la corrida se generó sin aplicar las excepciones, precisamente para que se puedan cruzar.

Algunos hallazgos aparecen con «sin arreglo»: la vulnerabilidad está publicada, pero el fabricante del paquete aún no ha sacado una versión corregida. Detener el despliegue no cambia nada porque no hay a qué subir, y ocultar el hallazgo es peor, porque el riesgo sigue ahí. El tratamiento honesto es registrar el hallazgo con un responsable, evaluar si el código afectado se alcanza desde la aplicación, aplicar una mitigación cuando exista y revisarlo cada semana hasta que salga la versión corregida. Cuando sale, el hallazgo pasa a ser de los que sí detienen.

Lo que se evita son las dos salidas fáciles: ignorarlo para siempre o bloquear sin salida.

Agrupar los hallazgos por capa de origen dice dónde está el trabajo. Si la mayor parte de lo que tiene arreglo viene de la base, la acción no es corregir ocho cosas sueltas: es actualizar la base y reconstruir, y de un solo movimiento desaparecen. Si viniera de la capa de la aplicación, el trabajo sería de los equipos de desarrollo. Contar con el mismo criterio cada vez —con arreglo, y por capa— permite comparar un informe con el siguiente y saber si la base se está quedando atrás.

Cuenta en el informe cuántos hallazgos tienen versión corregida y vienen de la base.