Sala 2 · Priorizar con contexto: política, biblioteca y borde

La política escrita junta tres señales: si la vulnerabilidad figura en el catálogo de explotadas, desde dónde se alcanza el activo y su criticidad. La combinación más exigente es la que reúne las tres. Se lee la política de arriba abajo y se aplica la primera fila cuya condición se cumple.

El CVSS mide la gravedad técnica, no el riesgo para esta organización. Un fallo con el puntaje máximo en un equipo interno, sin explotación observada y con poca probabilidad de uso queda en una prioridad menos urgente que otros de puntaje menor. Eso es correcto si se aplica la misma política a todos y se deja constancia de por qué.

Un aviso que cambia es un aviso con revisiones: las primeras pueden quedar cortas en el rango afectado o en la versión corregida. El ticket cita la versión de la revisión vigente, no la de la primera que alguien copió, y la mitigación es un paso intermedio y no una corrección.

Para contar servidores afectados se usa el rango de la revisión vigente, con los extremos incluidos, y se compara cada parte de la versión como número: 2.10.0 viene después de 2.9.2. Cuando la versión declarada por un equipo y la leída en el archivo difieren, manda el archivo. Si no hay versión leída ni forma de determinarla, el servidor no se cuenta como afectado y se anota como pendiente de determinar.

Un aparato de borde está afectado cuando cumple todo lo que dice la condición del aviso a la vez: modelo incluido, firmware anterior a la versión que corrige y la función vulnerable habilitada. Que tenga una versión vieja no basta, y que sea de otra familia lo deja fuera aunque esté atrasado. Un firmware igual al que corrige ya no está afectado.