Una dependencia comprometida, leída de los registros

Un aviso sobre versiones concretas se convierte en una pregunta al registro de compilaciones: qué compilaciones resolvieron una de esas versiones y cuándo. La primera compilación afectada marca desde cuándo existe un artefacto que pudo ejecutar el código añadido; las anteriores resolvieron una versión limpia y las posteriores a la corrección también. Se ordena por hora, no por número.

La lista de materiales dice qué versión de la biblioteca corre en cada aplicación y si llegó directa o arrastrada por otra. Para el alcance cuentan solo las aplicaciones de producción cuya lista muestra una versión afectada; las de pruebas se anotan aparte, y una aplicación sin lista no se puede contar como afectada ni como libre: es un punto ciego que se trata aparte.

El sensor de ejecución no sabe qué biblioteca llamó, pero sí a quién se conectó cada pod. Si el aviso nombra el destino al que intenta enviar datos el código añadido, las alertas hacia ese destino acotan qué pods ejecutaron el código. Un mismo pod puede alertar varias veces, y las alertas de otros destinos o de otras reglas no cuentan.

Una mitigación temporal solo vale si hay evidencia de que está puesta. El registro dice «aplicada»; la captura de la configuración dice qué hay realmente. Cuando las dos no coinciden manda la captura: la aplicación sigue sin la protección que el registro afirma, y no se cierra hasta corregirla.

La medida que más dice de un proceso de respuesta es el tiempo entre la publicación del aviso y el momento en que la organización sabe en qué aplicaciones está el componente. No es el tiempo hasta leer el aviso ni hasta aplicar la mitigación: es hasta que el inventario queda completo. Se cuenta en horas, de reloj a reloj.